先确认是堆内还是堆外内存暴涨：用top查res，jstat看old区是否持续上涨且full gc回收少；若res涨而堆内稳定，则重点查堆外——启用nmt或pmap定位，再结合jmap+mat分析堆内泄漏对象及引用链。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Java服务在生产环境长时间运行后内存持续暴涨，五六天就逼近100%，导致GC频繁、响应延迟甚至OOM崩溃，必须立即定位真实内存增长区域并切断泄漏源头。
确认是堆内还是堆外内存暴涨
先别急着调参数或重启，用系统命令快速划清责任区：执行 top -c 找到Java进程PID，记下它的 RES 值（实际物理内存占用）；再用 jstat -gc <pid> 1000 3</pid> 看三次GC数据——如果 Old 区使用量缓慢但坚定地上升，且每次Full GC后回收极少，说明是堆内泄漏；如果 RES 持续涨而堆内（-Xmx）始终稳定在70%以下，那大概率是堆外内存（Native Memory、Direct Buffer、Metaspace、线程栈等）在失控增长。
这一步漏掉会直接跑偏方向。很多团队花三天调-Xmx，最后发现是Netty的PooledByteBufAllocator没关闭，堆外内存占了6GB。
堆内泄漏：用jmap+MAT精准定位对象源头
只在确认Old区持续上涨后才执行此操作，否则浪费时间：
第一步：触发一次可控的堆转储 → 执行 jmap -dump:live,format=b,file=heap_$(date +%s).hprof <pid></pid>。注意加 【live】 参数，它会先强制执行一次Full GC再dump，确保拿到的是真正无法回收的对象快照，避免把本该被回收的临时对象也抓进来干扰判断。
第二步：用Eclipse MAT打开两个间隔6小时以上的dump文件 → 在MAT中依次打开「Histogram」→ 右键「Merge Shortest Paths to GC Roots」→ 勾选「exclude weak/soft references」→ 查看类实例数增幅最大的前三名。重点关注你自己写的类、缓存容器（如ConcurrentHashMap）、监听器（Listener）、静态内部类持有的Activity/Context（Android场景）等。
第三步：锁定泄漏路径 → 点击可疑类名 → 点「List objects」→ 再点「with incoming references」→ 查看谁在强引用它。如果看到某个Service实例持有一个静态Map，而Map里存着上千个未清理的回调对象，这就是根因。
堆外内存暴涨：启用NMT直击原生分配
方法一：重启JVM时加入NMT开关 → 启动参数追加 -XX:NativeMemoryTracking=detail，运行几小时后执行 jcmd <pid> VM.native_memory summary scale=MB</pid>。重点看 【Malloc】 和 【Arena】 两栏是否异常膨胀，若Malloc从200MB涨到1.8GB，基本可断定是C层代码或JNI调用泄漏。
方法二：不重启也能查（Linux）→ 执行 pmap -x <pid> | grep -E "(anon|total)" | tail -n 20</pid>，观察是否有大量大小接近的 [anon] 段（如每个64MB），这往往是DirectByteBuffer或Netty池化内存未释放的典型痕迹。
注意：NMT本身有5%～10%性能开销，线上慎用；pmap无需重启但只能看总量，无法定位具体Java代码行。
高频泄漏点与对应修复动作
方法一：静态集合无节制增长 → 检查所有 static Map/Map/List，确认是否设置了容量上限、过期策略或手动清理逻辑。没有就加，例如把 static Map<string object> cache = new HashMap()</string> 改为 static Cache<string object> cache = Caffeine.newBuilder().maximumSize(10000).expireAfterAccess(30, TimeUnit.MINUTES).build()</string>。
方法二：线程局部变量（ThreadLocal）未清理 → 特别检查Filter、Interceptor、AOP环绕通知中是否new了ThreadLocal并set了大对象。必须在finally块中调用 tl.remove()，否则线程复用时旧值一直挂着。
方法三：未关闭的资源型对象 → 检查所有 FileChannel、SocketChannel、ZipInputStream、Inflater 实例，确认是否在try-with-resources中声明，或手动调用了 close()。一个未关闭的Inflater可能让堆外内存每天涨20MB。
