c3p0连接池获得的Connection执行close方法后是否真的销毁Connection对象？

问题描述：

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 是同一个对象，即同一个连接。