共计 663 个字符，预计需要花费 2 分钟才能阅读完成。
有段时间线上呈现 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 实现