线上Java内存问题关键在提前干预而非等OOM发生，需通过jstat、jmap、Arthas等命令实时监控GC、老年代使用率及对象分布，结合堆dump与MAT分析泄漏根因，并依据报错类型精准定位堆、元空间、直接内存或线程栈问题。
线上 Java 内存问题不是“会不会发生”，而是“什么时候发生、怎么快速收场”。真正关键的，不是等 OOM 报错才动手，而是在内存使用持续爬升、GC 频次增加、老年代回收后释放极少这些信号出现时，就介入干预。
看懂 JVM 内存状态，比等崩溃更重要
OOM 往往是结果，不是起点。日常巡检或告警触发后，第一反应不该是重启，而是用命令快速摸清内存底细：
- jstat -gcutil <pid> 2000：每两秒刷新一次，重点盯 Old 区使用率是否 >90%、Full GC 是否频繁（比如 5 分钟内超 3 次）、YGC 后 Eden 是否几乎清空（说明对象没晋升，可能只是短生命周期压力大）
- jmap -histo:live <pid>：不 dump 全量堆，也能看到当前存活对象数量TOP 20，快速识别异常增长的类（如 byte[]、HashMap$Node、自定义 DTO）
- Arthas 的 dashboard 和 memstat：可视化更直观，还能实时对比不同时间点的堆分布变化，尤其适合在问题刚冒头时做趋势判断
堆 dump 不是万能钥匙，但必须会用
生成 dump 是必要动作，但关键在“何时”和“怎么读”：
- 别等 OOM 才 dump——配置 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/ 是底线；更进一步，可在监控发现 Old 使用率连续 3 分钟 >85% 时，主动 jmap -dump:live,format=b,file=heap_$(date +%s).hprof <pid>
- 用 MAT 打开后，先看 Leak Suspects Report，它自动标出最可能泄漏的引用链；再手动进 Dominator Tree，按 retained heap 排序，找真正吃内存的大户
- 注意区分“占用多”和“泄漏”：一个缓存类实例多很正常，但如果它的 value 是大量未清理的 byte[] 或未注销的监听器，才是根因
代码里藏着的泄漏陷阱，得靠经验识别
工具只能告诉你“谁占得多”，最终要回归代码逻辑。高频泄漏点有明确模式：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
-
静态集合无限堆积：如
private static List<Object> cache = new ArrayList<>();—— 没清理机制，必爆 -
ThreadLocal 泄漏：线程池场景下，
threadLocal.set(x)后没调remove()，对象随线程存活，越积越多 - 监听器/回调未注销：注册了事件监听、Spring ApplicationRunner、Netty ChannelHandler，但业务结束没解绑
- 资源未关闭：InputStream、Connection、Statement 等未用 try-with-resources，底层句柄不释放，间接拖慢 GC
别只盯着堆，其他区域同样会爆
报错信息就是线索，得对症下药：
- java.lang.OutOfMemoryError: Java heap space → 查堆对象、GC 日志、缓存逻辑
- java.lang.OutOfMemoryError: Metaspace → 检查动态代理（CGLIB）、频繁 ClassLoader 加载、JSP 编译，加 -XX:MaxMetaspaceSize=256m 并监控 loaded class count
- java.lang.OutOfMemoryError: Direct buffer memory → 定位 NIO ByteBuffer.allocateDirect() 调用点，确认是否复用或及时 clean
- unable to create new native thread → 不是堆不够，是系统线程数到上限，查 -Xss 设置和线程池配置
排查不是单点突破，是监控、日志、命令、dump、代码五环联动。一次解决不了，就保留现场、分段验证、建立基线——线上内存问题，拼的是反应速度，更是日常积累的判断直觉。
