深入分析后发现内存增长源头在于大量SSLSocketImpl对象，这些对象被mysql-connector-java的NetworkResources引用，进而被存于AbandonedConnectionCleanupThread的connectionFinalizerPhantomRefs集合中。通过arthas命令发现集合中保存的References数量超过12000个，确认内存增长原因。初步检查包括使用jstack检查线程状态及内存分布...
MySQL Connector内存增长问题排查
近日发现多服务内存持续增长，增长速度稳定，85%后仍呈增长态势。深入分析后发现内存增长源头在于大量SSLSocketImpl对象，这些对象被mysql-connector-java的NetworkResources引用，进而被存于AbandonedConnectionCleanupThread的connectionFinalizerPhantomRefs集合中。通过arthas命令发现集合中保存的References数量超过12000个，确认内存增长原因。
初步检查包括使用jstack检查线程状态及内存分布分析，确认无堆栈异常情况。使用命令查看内存分布，发现大量SSLSocketImpl对象为问题关键。经过进一步排查及arthas命令执行，确认代码中try-with-resources写法确保了连接的释放，连接建立速度与释放速度平衡，队列中无等待释放连接。深入阅读源码后发现，ConnectionImpl在创建时即注册至AbandonedConnectionCleanupThread，该线程通过PhantomReference虚引用使JVM判定连接处于等待回收状态，但实际在GC时才关闭NetworkResources。通过arthas命令及VisualVM分析发现，多数ConnectionImpl已关闭，但多数只在ConnectionFinalizerPhantomReference中有引用，揭示问题根源。
通过分析，明确问题为JVM未及时触发不再活跃的ConnectionImpl回收，导致内存占用增加。但这些ConnectionImpl实际上已不活跃，具备回收条件。解决方案包括禁用AbandonedConnectionCleanupThread及减少连接建立次数，使用连接池复用技术降低新建连接需求。这些措施将有效解决内存增长问题，优化服务运行效率。2024-11-20
