开篇：凌晨的 OOM 告警是怎么排查的

内存问题是 Java 线上排查中最让人头疼的一类——它不像 CPU 飙高那样能快速用 top + jstack 定位，也不像接口超时那样能通过链路追踪找到瓶颈。内存问题往往是缓慢积累、突然爆发，等你收到告警的时候，进程可能已经在 OOM 的边缘疯狂 FullGC 了。

这篇文章记录了几个真实的内存问题排查案例，从发现到定位到解决，完整还原排查过程。每个案例的排查思路都是可以复用的。

---

一、OOM 排查实战：LinkedList 内存泄漏

开篇：线上故障了，你会怎么排查？

凌晨3点，手机突然响了。值班群里弹出一条消息："生产环境告警，服务A频繁FullGC，接口响应超时！"

你揉了揉眼睛，打开电脑，ssh连上机器。接下来你会做什么？是先看日志？还是先看GC？又或者直接dump堆内存？

如果你对这个场景感到心里没底，那这篇文章就是为你准备的。我们会从JVM核心参数讲起，逐步深入到排查工具、OOM实战、FullGC排查流程，最后聊聊JIT编译优化。学完之后，下次再被叫醒，你至少知道该打出哪几行命令。

一、JVM 核心参数

调JVM就像调一台发动机——参数设错了，轻则性能低下，重则直接宕机。我们先把最常用的几组参数理清楚。