答案是内存泄漏或堆外内存失控。重启后内存持续上升且gc后不回落，尤其老年代（ou）缓慢爬升，表明资源未释放或对象未回收；需用jstat查ou/fgc、ps查rss、nmt定位堆外增长，并结合堆转储分析强引用链。
重启后内存持续上升，说明问题不是偶发或初始化残留，而是运行过程中逐步积累的资源未释放或对象未回收。关键不是“有没有内存增长”，而是“增长是否可逆”——如果每次 GC 后内存不能回落，尤其老年代（OU）缓慢爬升，大概率是内存泄漏或堆外内存失控。
先确认是不是真泄漏：看 GC 行为和老年代趋势
别急着导堆转储，先用最轻量的方式验证现象：
-
jstat -gcutil
2s ：每2秒输出一次 GC 统计，重点关注 OU（Old Utilization） 和 FGC/FGCT。如果 OU 每次 Full GC 后只下降一点点（比如从 95% → 92%），且 FGC 频次越来越高，基本锁定堆内泄漏。 -
对比 RSS 和堆内存：用 ps -o pid,rss,command -p
查看进程实际物理内存（RSS）。如果 RSS 持续上涨，但 jstat 显示堆内存（O）没怎么涨，问题很可能在堆外——比如 DirectByteBuffer、Metaspace 或线程栈。
区分堆内还是堆外：用 NMT 快速定位增长源头
很多“重启后上涨”其实是堆外内存没释放，尤其是 Netty、Kafka、gRPC 等框架大量使用 DirectBuffer：
- 启动时加参数：-XX:NativeMemoryTracking=detail
- 内存明显上涨后执行：jcmd
VM.native_memory summary.diff - 重点看这几项变化量：Direct memory（NIO 直接缓冲区）、Metaspace（动态类加载）、Thread（线程数暴增）——哪项涨得最多，就优先查哪块。
堆内问题：抓快照 + 看大对象和强引用链
确认是堆内上涨后，立刻生成堆转储，避免等 OOM 才触发（可能已截断）：
-
jmap -dump:live,format=b,file=heap.hprof
（推荐加 live，排除待回收对象干扰） - 用 MAT 打开后直奔三个视图：Histogram（找实例数多、总大小高的类，如 byte[]、HashMap、ArrayList）；Dominator Tree（看谁占内存最多，顺藤摸瓜）；Leak Suspects（MAT 自动生成的疑似泄漏报告，常准）
- 特别留意：static 字段持有集合、未清理的 ThreadLocal、注册后没反注册的监听器、缓存没设上限或过期策略——这些是重启后越跑越大的典型根因。
堆外问题：盯紧 DirectBuffer 和线程生命周期
如果 NMT 显示 Direct memory 涨得猛，不要只查 ByteBuffer.allocateDirect() 调用点：
- Netty 默认用 PooledByteBufAllocator，但若配置了 unpooled 或禁用了池化，每个 channelRead 都会 new DirectBuffer；
- 检查是否漏调 buffer.release()（尤其在异常分支里）；
- 观察线程数：ps -T -p
| wc -l ，线程数随时间增长？可能是线程池没 shutdown，或异步任务不断创建新线程； - Metaspace 涨？查是否频繁加载/卸载类（如热更新、脚本引擎、CGLIB 动态代理过多）。
不复杂但容易忽略：重启只是清掉了当前状态，没改代码逻辑。只要泄漏路径还在，每次启动都是重蹈覆辙。定位到具体类或资源后，补上释放动作或限制机制，比调大堆内存管用得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
