如何进一步排查CMS Old Gen持续增长的应用内存泄漏问题

咱们一步步拆解来解决你的问题，先从核心可疑点java.lang.invoke.MethodType的大HashMap入手，再覆盖其他可能的原因：

一、针对MethodType HashMap的深度排查步骤 #

• 追踪引用链到底层持有者：在MAT里右键点击那个MethodType实例，选择「Path to GC Roots」→「exclude weak references」，这样能看到哪个对象（大概率是静态集合或者缓存类）在死死持有这个HashMap。系统类加载器加载的Class本身不会被GC，但如果有其他业务代码的静态变量引用了这些MethodType实例，就会导致它们无法被回收。
• 对比多份堆转储的变化：你已经有多个实例的堆转储，把它们导入MAT后用「Compare Basket」功能，看看这个HashMap的元素数量、占用内存是不是随着时间/业务操作持续增长。如果某个特定操作（比如批量处理请求、热部署）后突然暴涨，那就能定位到触发场景。
• 检查MethodType的创建逻辑：MethodType.methodType()默认会缓存实例，但如果你的代码里频繁生成独特签名的MethodType（比如动态生成方法、反射调用时每次都重新创建不复用），或者错误地把这些实例放到了无过期策略的静态缓存里，就会导致缓存无限膨胀。你可以检查代码里的反射、动态代理相关逻辑，有没有复用MethodType的地方。

二、关于循环依赖的判断 #

从你描述的情况来看，单纯的Class实例被系统类加载器持有，并不属于循环依赖导致的泄漏。但如果你的应用存在以下情况，可能间接引发类似问题：

• 自定义类加载器和系统类加载器互相引用（比如自定义加载器的某个静态变量持有系统类加载的对象，反之亦然）；
• 系统类加载的类持有了大量来自自定义类加载器加载的对象，导致自定义加载器无法被GC，进而连带其加载的Class实例也无法回收。
  不过当前重点还是先排查MethodType的HashMap持有问题，循环依赖的概率相对较低。

三、其他可能导致此类症状的原因 #

除了上述情况，还有这些常见因素会引发Old Gen内存持续增长：

• 静态集合滥用：比如某个业务类的静态HashMap/List不小心把MethodType、Class实例存进去，却没有设置清理逻辑，随着请求积累越存越多；
• 第三方框架的隐藏缓存：有些ORM、RPC、动态代理框架会缓存反射相关对象（包括MethodType），如果配置了无限制的缓存（比如没有过期时间、最大容量），就会导致内存膨胀；
• 类加载器泄漏：如果应用频繁创建自定义类加载器（比如热部署、插件化场景），但没有正确释放加载器的引用，会导致加载的所有Class实例（包括关联的MethodType）无法被GC；
• JVM参数配置不合理：比如CMS收集器的-XX:CMSInitiatingOccupancyFraction设置过高，导致Old Gen内存到了很高比例才触发回收，看起来像是内存持续增长；或者元空间（-XX:MetaspaceSize）设置过小，导致Class实例挤到Old Gen里；
• 反射调试参数辅助：你可以开启-verbose:reflect（Java 8及以下）或者-Dsun.reflect.debugModuleAccessChecks=true（Java 9+），观察有没有频繁创建MethodType的调用栈，定位到具体的代码位置。

四、快速验证的小技巧 #

• 用MAT的「Dominator Tree」功能，按内存占用排序，找到那个大HashMap的所属类，看看是不是某个静态属性在持有它；
• 尝试在测试环境模拟高频业务请求，同时监控Old Gen内存和MethodType实例的数量变化，验证是不是请求越多，内存增长越快；
• 检查代码中有没有用MethodType.genericMethodType()这类生成泛型方法签名的逻辑，这类签名更容易产生独特的MethodType实例，导致缓存膨胀。

内容的提问来源于stack exchange，提问作者rigby