問題描述：
jfinal做的api系統中，在正常調用接口一段時間后，突然再調用接口的時候，該請求無響應api系統后台也無錯誤信息
(就是剛開始接口調用是正常的，突然就無響應了)
於是啊，就開始找錯誤。
好在我是個找錯小能手，即使沒有后台報錯信息，一點一點通過不同的參數去調用接口，最后猜測 是卡在了數據庫查詢的地方。
當然就開始重點查這方面了。
但是，看代碼沒有任何問題；而且是使用的c3p0連接池啊，不應該獲取不到連接啊，所以當時就把這個原因排除了。
可是，找啊找。
我寫了個方法專門測試是否只是因為數據庫操作就會引起請求無響應，卡住現象。
結果，肯定是沒有出現的啊。
最后發現是由於使用了事務。
而事務是並不是jfinal的，是通過封裝的。
事務里並沒有close連接。
我轉念一想，不應該啊，既然是連接池，不是應該會自動釋放連接么。 不是有個maxIdleTime么。
可一邊還是加上了close操作進行測試。
咦。真的好了。(可是還是不明白，為什么不會報錯呢)
最后就想深入研究一下close操作。
測試背景：
C3P0連接池
jdbc.maxPoolSize=1
jdbc.minPoolSize=1
jdbc.initialPoolSize=1
Connection conn = dataSource.getConnection()
網上找了下很多人都說使用連接池后，connection的close方法不是真正的關閉，只是放回池里待用。
我從來都喜歡追根究底，其實就是好奇心害死貓。所以也忍不住測試了。
第一次：
com.mchange.v2.c3p0.impl.NewProxyConnection@1a637d2 [wrapping: com.mysql.jdbc.JDBC4Connection@19ad782]
第二次：
com.mchange.v2.c3p0.impl.NewProxyConnection@434916 [wrapping: com.mysql.jdbc.JDBC4Connection@19ad782]
上面說法應該是正確的。
com.mysql.jdbc.JDBC4Connection@19ad782 是同一個對象，即同一個連接。