DBCP connection pooling produces a large number of objects that are not recycled

There was a time when Full GC took too long on the line, resulting in slow response of the system. Here is a rough record of the relevant information:

JVM parameter configuration:

XMS is the same as XMX: 4096M

Xmn:1576m

The heap: 512

The garbage collector uses a CMS

ConnectionPhantomRefs is a database connection pool developed by the company. After two days, the usage of the old file is basically maintained at 256MB. Here is the contents of the dump file:



Click CurrentHashMap, right-click List Objects > with incoming References to see which objects are referring to the object



You can clearly see it’s ConnectionPhantomRefs

There are a few questions that need to be understood: 1, the connection pool configures the upper and lower limits of the number of connections and the survival time, why so many connection objects are still generated; 2, why so many connection objects are not collected and posted in time: https://blog.csdn.net/yl_hahh… There is an analysis of list objects referenced: with incoming references list which classes are introduced into the class; With outgoing references listed the quotes which classes https://blog.csdn.net/u010657… There is mentioned the mysql connector – Java 5.1.46 enable threads to constantly clean up by GC database connection https://zhuanlan.zhihu.com/p/… DirectByteBuffer collection is mentioned here, which relies on PhantomReference implementation