OOM 排查与堆转储分析

关键词对比：
  heap space      → 堆内对象太多
  native thread   → 线程太多（每线程 1MB 栈）
  direct buffer   → 堆外内存泄漏
  metaspace       → 类/元数据泄漏（动态代理、反射）

// 内存泄漏：对象不再使用，却被强引用链挂住，GC 收不走
public class LeakHolder {
    static final List<byte[]> CACHE = new ArrayList<>();
    void store(byte[] data) { CACHE.add(data); }  // 只进不出 → 泄漏
}

// 内存不足：对象被正常使用，但总量超过堆上限（一次性大请求）
// 与泄漏的本质区别：内存不足清掉请求就恢复，泄漏清不掉

排查第一步：看监控指标
  1. 堆使用率曲线：持续上涨不回落 → 泄漏
  2. GC 频率与停顿：Full GC 越来越频繁 → 内存将尽
  3. 线程数曲线：持续上涨 → native thread OOM
  4. 容器内存/堆外：进程 RSS 远超堆大小 → 堆外泄漏

第二步：确认报错堆栈
  报错信息里的"谁在分配、分配多少"往往直接指向泄漏点

Java heap space / GC overhead
  → 收集堆转储 → MAT 找泄漏根因
Unable to create native thread
  → 看线程数 + 系统 ulimit → 线程泄漏或栈设置
Direct buffer memory
  → 查 Netty/自管理 DirectBuffer 的释放路径
Metaspace
  → 查动态代理/反射/类加载器泄漏

# 方式一：jmap 直接 dump（会触发 Full GC，慎用于大堆）
jmap -dump:live,format=b,file=/tmp/heap.bin <pid>

# 方式二：HSDB / jcmd（推荐，命令一致）
jcmd <pid> GC.heap_dump /tmp/heap.bin

注意事项：
  jmap 默认会执行一次 Full GC，生产大堆慎用
  优先用 jcmd GC.heap_dump，行为更可控
  转储文件可能很大（等于堆大小），留足磁盘

缓慢泄漏的采样技巧：
  堆上涨初期 dump 一份（baseline）
  上涨明显后再 dump 一份（current）
  两次对比 → 新增存活对象 = 泄漏主体

# 启动参数：OOM 时自动 dump + 自动退出，便于监控重启
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/data/dumps/ \
     -XX:OnOutOfMemoryError="kill -9 %p" \
     -Xmx4g MyApp

// 代码级兜底：捕获 OOM 记录上下文，便于分析
try {
    // 大对象分配
} catch (OutOfMemoryError e) {
    log.error("OOM 上下文: requestId={}, userId={}", reqId, userId, e);
    throw e;   // 让 JVM 的 HeapDumpOnOutOfMemoryError 继续生效
}

Leak Suspects 报告结构：
  Suspect 1：某个对象占了多少堆，被谁全局持有
  详情：Dominator Tree 中的路径 → 引用链 → 泄漏根因

解读要点：
  报告给出的是"最大的堆占用者"，不一定是业务泄漏
  结合业务代码判断：这个大对象本该释放吗？

Dominator Tree（支配树）：
  每个节点的"支配者"是持有它、且其被释放则它必然被释放的对象
  顺着支配树看：谁独占了大头 → 谁持有不释放

常用视图：
  Histogram：按类统计实例数与占用
  Path to GC Roots：某个对象的完整引用链
  Retained Heap：对象及其支配子树占用的内存

// 经典泄漏根因示例：静态集合 + 业务对象
public class CacheManager {
    // static 引用 → GC Roots 可达 → 永不释放
    private static final Map<String, Session> SESSIONS = new HashMap<>();
}
// MAT 中：SESSIONS → Path to GC Roots 显示 "static final"
// 说明缓存只进不出是泄漏源

OQL 示例：找所有超过 1MB 的 byte[] 实例
  SELECT * FROM byte[] b WHERE b.length > 1048576

对比两个 dump（间隔一段时间）：
  MAT → Compare → 找出"新增且存活"的对象
  往往就是正在泄漏的那批

现象：堆曲线持续上涨，Full GC 越来越频
Leak Suspects：一个 ConcurrentHashMap 占用 60% 堆

分析路径：
  1. Histogram 找最大类 → ConcurrentHashMap
  2. Path to GC Roots → 静态字段引用的本地缓存
  3. 查代码 → 缓存 key 永不失效，value 越积越多
修复：
  加 TTL 淘汰 / 改用带过期策略的缓存框架

现象：thread 数不多，但堆上涨

根因：ThreadLocal 值被线程持有，线程长期存活不销毁
  → value 一直可达，GC 收不掉

识别：
  Histogram 中 ThreadLocal 相关类实例数与线程数对得上
  Thread 的 threadLocals 指向一个巨大 value

修复：用完 remove()，或用作用域内清理的封装

// 正确姿势：ThreadLocal 用完必须 remove
ThreadLocal<BigObject> tl = new ThreadLocal<>();
try {
    tl.set(bigObject);
    doWork();
} finally {
    tl.remove();   // 关键：清掉，防止线程池复用串值
}

预防思路（前置）：
  1. 设置合理的堆上限，配合 GC 日志
  2. 对缓存类对象做容量/过期约束
  3. 统一资源关闭（连接、流）规范
  4. 压测阶段引入泄漏检查（如 JFR + MAT 定期体检）

崩溃恢复兜底：
  1. 进程自动重启（systemd / k8s 重启策略）
  2. 重试机制：上游调用方重试，规避一次性大请求
  3. 限流降级：OOM 前先熔断，保护后续请求
  4. 分片分页：大结果集分批处理，避免一次堆满

预防兜底：
  1. 配 HeapDumpOnOutOfMemoryError，自动留证
  2. 监控堆使用率与 GC，设阈值告警
  3. 定期用 JFR/MAT 做内存健康检查

# 一个兼顾"兜底 + 留证"的启动配置示例
java \
  -Xmx4g -Xms4g \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/dumps/ \
  -XX:+ExitOnOutOfMemoryError \
  -Xlog:gc*:file=/data/logs/gc.log \
  MyApp