深夜两点，告警群突然炸了：某核心服务的堆内存使用率连续 30 分钟超过 95%，Full GC 频率从平时的每 40 分钟一次飙升到每分钟数次，接口 P99 从 120ms 恶化到 3s，紧接着节点开始轮番 OOM 重启。这类场景对每一个后端工程师来说都不陌生。本文以一次真实的生产内存泄漏事故为蓝本，完整复盘从「发现异常」到「定位根因」再到「止血与根治」的全链路排查过程，重点讲清楚 jstat、jmap、jstack、MAT 这些工具各自该在什么时机用、能拿到什么证据、如何互相印证。
拿到告警后的第一件事不是急着 dump 堆，而是先回答三个问题：这是内存泄漏，还是内存本来就不够？是 Full GC 频发导致的暂停，还是年轻代晋升压力过大？是单点问题还是全集群问题？
很多人对 JVM 的理解停留在"解释执行 + 垃圾回收"的层面，却忽略了真正决定吞吐上限的那一层——即时编译器（JIT Compiler）。HotSpot 之所以能在长时间运行后逼近甚至反超静态编译语言，靠的不是把字节码逐条翻译成机器码这么简单，而是一整套基于运行时反馈的激进优化：分层编译、内联、逃逸分析、标量替换、同步消除。这些优化彼此咬合，任何一环失效都可能让后续优化整条链断裂。
本文不打算把 JIT 讲成教科书，而是从生产排障的视角出发，讲清楚三个问题：这些优化在什么条件下才会发生、如何验证它真的发生了、以及它失效时的典型症状是什么。
类加载机制是 JVM 中最容易被"背八股文"却最难真正吃透的一块。很多人能脱口而出"双亲委派模型"六个字，却说不清 ClassLoader.loadClass 和 Class.forName 的初始化时机差异，也解释不了 SPI 为什么要打破双亲委派、以及 Tomcat 为什么每个 Web 应用都要有独立的 ClassLoader。本文从字节码加载的完整生命周期出发，结合生产环境的真实踩坑，把这一机制讲透。
一个 .class 文件从磁盘到真正可用，要经历加载（Loading）→ 验证（Verification）→ 准备（Preparation）→ 解析（Resolution）→ 初始化（Initialization）五个阶段。前三个阶段通常被笼统称为"加载"，但实际上语义完全不同，很多线上问题的根源就是混淆了这些阶段。
很多工程师对 GC 的认知停留在「STW 越小越好、吞吐量越大越好」的口号层面，一到生产环境就凭感觉堆参数。实际上，不同垃圾收集器的核心差异在于内存布局、对象标记/复制算法、并发阶段与暂停模型的组合方式。同样一份负载，在 CMS 上表现良好的配置原封不动搬到 ZGC 上反而会拖慢吞吐量；反过来，一个「大堆、低延迟」的诉求如果硬套 Parallel Scavenge，几乎注定要经历周期性长暂停。
理解演进，本质上是理解一个约束条件的逐步解除过程：CMS 试图在分代假设下并发做掉大部分标记与清除，但受限于「标记-清除」的内存碎片与「并发标记-再标记」的漏标补偿；G1 用 Region 化布局 + 可预测停顿的增量回收 + 复制式整理，把停顿从「堆大小相关」拉回到「回收集大小相关」；ZGC 则用染色指针与读屏障，把「并发整理」推向极致，让停顿收敛到与堆大小基本无关。 这一路走来，每一代都在解决上一代最痛的短板，也都引入了新的运维复杂度。