有段时间线上呈现Full GC工夫过长导致系统响应慢,这里先粗略的记录下相干信息:
jvm参数配置:
Xms与Xmx雷同:4096m
Xmn:1576m
非堆:512
垃圾回收器应用的是CMS
基本上两天老年代会增长近2G未回收的对象,dump进去的文件里存在大量的数据库连贯对象:connectionPhantomRefs,起初换成公司自研的数据库连接池察看两天后老年代使用量基本上维持在256M,上面是dump文件无关内容:

点击CurrentHashMap,右键后List objects > with incoming references查看是哪些对象援用了该对象

能够显著看到是connectionPhantomRefs

这里有几个疑难还须要搞明确:
1,连接池配置了连贯数量的上上限和存活工夫,为什么还会产生这么多的连贯对象
2,这么多的连贯对象为什么没被及时回收
贴几个相干的连贯:
https://blog.csdn.net/yl_hahh...
外面有剖析援用list objects :
with incoming references 将列出哪些类引入该类;
with outgoing references 列出该类援用了哪些类
https://blog.csdn.net/u010657...
这里有提到mysql-connector-java 5.1.46启用线程去一直地清理被 GC 的数据库连贯
https://zhuanlan.zhihu.com/p/...
这里有提到DirectByteBuffer的堆外内存的回收,就是依赖PhantomReference实现