C3P0 Connection pool Connection leak detection

Add in Profile C3p0-config.xml:
True
1
Debugunreturnedconnectionstacktraces defaults to False, if this parameter is set to True, when all connections are exhausted, what code is displayed with stack information that uses
The connection. Because tracking the connection state can cause additional consumption, if the program is stable, you should revert this parameter to the default value false.
Unreturnedconnectiontimeout set the connection to be checkout, the connection buffer pool is killed directly after the connection pool has not been returned for a long time

After the setup is complete, you can observe the stack information as follows:
Java.lang.Exception:DEBUG only:overdue resource Check-out stack trace.
At Com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource (basicresourcepool.java:506)
At Com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection (c3p0pooledconnectionpool.java:525 )
At Com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection (abstractpoolbackeddatasource.java:128)
At Com.xinge.mms.push.jdbc.C3p0ConnectionProvider.getMms2Connection (c3p0connectionprovider.java:47)
At Com.xinge.mms.push.manager.DBMms2Manager.isDetail (dbmms2manager.java:78)
At Com.xinge.mms.push.handler.IosMessageHandler.getAlert (iosmessagehandler.java:83)
At Com.xinge.mms.push.handler.IosMessageHandler.sendMessage (iosmessagehandler.java:70)
At Com.xinge.mms.push.apnstask.IosMessageProcessor4Test.run (iosmessageprocessor4test.java:59)
At Java.util.concurrent.ThreadPoolExecutor.runWorker (threadpoolexecutor.java:1145)
At Java.util.concurrent.threadpoolexecutor$worker.run (threadpoolexecutor.java:615)
At Java.lang.Thread.run (thread.java:744)

You can see the Dbmms2manager.isdetail (dbmms2manager.java:78), see the code found that the acquisition of the connection is not closed after use, resulting in a connection leak