java oom需先定位“谁占的、为什么不放、能不能改”，核心思路是：看错误类型定区域→捕获现场快照→用工具找根因→改代码或调参数。
Java 应用发生 OOM，不是配小了就加内存，而是要先定位“谁占的、为什么不放、能不能改”。核心思路是：看错误类型定区域 → 捕获现场快照 → 用工具找根因 → 改代码或调参数。
一、根据错误日志快速锁定溢出区域
日志里的报错信息直接决定排查方向：
- java.lang.OutOfMemoryError: Java heap space → 堆内存被撑满，重点查对象数量、大小、GC 效果
- java.lang.OutOfMemoryError: Metaspace → 类加载过多，关注动态代理、Spring Boot DevTools、热部署、频繁重部署
- java.lang.OutOfMemoryError: Direct buffer memory → NIO 的 ByteBuffer.allocateDirect() 未释放，或 netty 等框架堆外内存使用失控
- java.lang.OutOfMemoryError: unable to create new native thread → 线程数超限，检查线程池配置、是否漏关 ThreadLocal 或未限制线程创建
- java.lang.StackOverflowError → 不是 OOM，但属内存相关崩溃，查递归深度、lambda 表达式嵌套、AOP 代理链过长
拿到错误后，立刻执行 jps -l 找 PID，再用 jinfo -flags {pid} 确认实际生效的 -Xmx、-XX:MaxMetaspaceSize 等参数，避免配置写了没生效。
二、自动捕获 Heap Dump 并用 MAT 分析
别等重启后再回忆，启动时就加上参数让 JVM 自动保存现场：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/
拿到 .hprof 文件后，用 Memory Analyzer Tool（MAT）打开，重点关注三个视图：
- Histogram：看哪些类实例最多、总占用最大（比如 byte[]、HashMap、自定义缓存类），快速圈出“高嫌疑对象”
- Dominator Tree：按“谁真正持有不可回收内存”排序，比 Histogram 更接近泄漏主线（例如一个静态 Map 占据 70% Retained Heap）
- Path to GC Roots：右键可疑对象 → “Merge Shortest Paths to GC Roots”，确认强引用链——常见如 static 字段持有、ThreadLocal 未 remove、监听器未注销、内部类隐式持外部类引用
三、高频泄漏场景与对应修复方式
多数 OOM 不是内存不够，而是代码逻辑埋雷：
- 无界本地缓存：static Map 或 List 持续 put 不清理 → 改用 Caffeine（带容量限制+过期策略），或 ConcurrentHashMap + 定时清理线程
-
大表/大文件一次性加载：JdbcTemplate.queryForList("SELECT * FROM huge_table") 或 FileUtils.readFileToByteArray() → 改成分页查询、Stream
流式处理、RowCallbackHandler 或 Files.lines() 配合 try-with-resources - 资源未释放：InputStream/Connection/Channel 忘 close → 统一用 try-with-resources；NIO 的 DirectByteBuffer 要显式 clean() 或依赖 Cleaner（注意 JDK 版本差异）
- ThreadLocal 泄漏：在线程池中使用后未调用 remove() → 每次使用完必须 remove()，尤其在 Filter、Interceptor 中
- 动态类生成过多：CGLIB 代理、JSON 序列化（如 Jackson 的 ObjectMapper 动态生成类）、Groovy 脚本 → 限制代理数量、复用 ObjectMapper、避免运行时编译脚本
四、调优不是只调 -Xmx，还要看 GC 和区域配比
盲目加大堆可能掩盖问题，甚至恶化 GC 压力：
- 堆大小建议设为物理内存的 50%~75%，-Xms 和 -Xmx 设相同值，避免扩容抖动
- 元空间默认无上限，生产环境务必加 -XX:MaxMetaspaceSize=256m（根据应用类数量调整）
- 直接内存可通过 -XX:MaxDirectMemorySize 限制，配合 netty 的 PooledByteBufAllocator 使用
- 开启 GC 日志：-Xlog:gc*:file=/data/logs/gc.log:time,tags,level，观察 Full GC 频率、耗时、前后内存变化
- 对响应敏感服务，可选 G1 GC 并设置预期停顿时间：-XX:+UseG1GC -XX:MaxGCPauseMillis=200
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
