导出 50 万行报表，堆直接原地去世：一次 OOM 的 dump 分析与流式改造
运营点了一下“导出全部订单”，服务就抛出 Java heap space 并重启。靠 HeapDumpOnOutOfMemoryError 留住现场，用 MAT 的 Dominator Tree 揪出一个 List，最后改成分页 + EasyExcel 流式写出。
# 内存
从一个关键词，发现新的思路。
堆明明没满，容器却被 OOMKilled：一个 ByteBuf 忘了 release 的堆外内存漏洞
消息推送网关的堆使用率一直只有 40%，容器 RSS 却每天涨一截，最后被 OOMKilled，日志里还偶发 Direct buffer memory。用 NMT、Netty 泄漏检测 PARANOID 找到忘记 release 的 ByteBuf，并给堆外内存加上限。
容器每 40 秒“重生”一次：Restarting、exit 137 与一场 restart always 引发的重启风暴
docker ps 里一个容器永远显示 Restarting，日志什么都没有。docker inspect 看 OOMKilled 与 ExitCode 137，配合 docker events、stats、dmesg 定位内存超限，讲清 restart policy 如何放大故障、-m 与 swap 的关系，附 exit code 速查表。
Java 进程“人间蒸发”：没有 hs_err、没有 OOM 异常，凶手是 Linux 的 OOM Killer
服务凌晨无声消失，没有 hs_err 文件也没有 OutOfMemoryError。dmesg 里一行 Out of memory: Killed process 揭开真相：JVM 堆加堆外内存把机器吃光，被内核枪毙。附排查命令、oom_score 原理和堆参数预留算法。
Too many open files：一个没关的 HttpClient，攒出了三万个 CLOSE_WAIT
接口突然大面积报 Too many open files。先分清 ulimit、limits.conf、systemd LimitNOFILE 与容器的差异，再用 lsof、ss 统计连接状态，定位到 CLOSE_WAIT 堆积，根因是 HttpClient 响应没关闭导致连接泄漏。