1. 从一次线上OOM说起为什么Java开发者都该啃透JVM做Java开发这几年我见过太多人在“JVM到底要不要学”这个问题上纠结。有人觉得这是运维和架构师的事业务代码写得好就行有人面试前背一背垃圾回收算法入职后就把这块知识彻底抛到脑后。但真正遇到线上事故的时候比如应用突然CPU飙升、接口响应从50毫秒变成30秒、内存看着看着就被占满绝大多数人第一反应是重启机器或者加内存完全不知道从哪里下手排查。我自己就栽过一次跟头。一个内部报表系统每天凌晨跑批的时候频繁触发Full GC每次停顿好几秒定时任务一个接一个超时。那时候我对JVM的了解基本停留在“堆内存不够就加-Xmx”的水平日志里看到Full GC也不敢动生怕改了参数把问题搞得更糟。后来花了很大力气把《深入理解Java虚拟机JVM高级特性与最佳实践》这本书啃完前前后后重构了报表模块的内存使用方式才真正把这些知识点串起来。所以我想认真写一篇基于这本书的实战向学习笔记不是把目录搬运一遍而是结合我实际排查过的场景聊聊JVM内存模型、垃圾收集器、类加载机制和性能排查工具这些内容到底怎么用。如果你是工作了两三年的Java工程师或者正准备面试高级岗位又或者已经被线上问题折磨过但没找到系统化思路的朋友这篇内容应该能帮你在“读过很多书但用不上”和“真正能上手排障”之间搭一座桥。2. JVM内存区域先搞清楚每个角落放什么2.1 运行时数据区的九个部分JVM的内存区域划分是理解一切运行时行为的基础。书里第一大部分就把运行时数据区拆成九个模块程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区、运行时常量池、直接内存还有JDK 8之后并入堆的字符串常量池等一系列细节。我自己的理解方式是把它们分成两类。一类是线程私有的程序计数器、虚拟机栈、本地方法栈这些区域随线程创建而分配随线程结束而回收一般不用太操心它们的GC问题。另一类是线程共享的堆和方法区才是垃圾收集的主战场。很多初学者会混淆“栈上分配”和“栈帧”这两个概念。我举个生活中能听懂的类比一个方法调用过程就像你点了一杯奶茶。柜台上贴着小票程序计数器记录该执行哪一步店员手里的操作台虚拟机栈一格格放着当前这一步需要的原料和工具用完一格清空一格。而所有做好的奶茶都放在大厅的展示柜堆里谁都能拿。至于方法区更像是挂在墙上的菜单板和配方本记录着类和方法的元数据所有人都参照同一本菜谱做菜。2.2 堆内存的结构与对象的一生堆是JVM管理内存最大的一块区域日常调优基本都围绕它展开。堆内部划分为新生代和老年代新生代里又分为Eden区和两个Survivor区比例默认是8:1:1。这不是随意定的数字而是在大量统计中得出的经验值——根据IBM的研究绝大多数Java对象存活时间很短大约98%的对象在新创建后就会被回收所以Eden区给大Survivor区给小。我实际操作中遇到过不少人对Survivor区比例有误解以为8:1:1代表Eden是8MB两个Survivor各1MB。其实这个比例是相对的Eden : Survivor0 : Survivor1 8 : 1 : 1而具体容量取决于-Xmn设定或者默认计算。当你设置-Xmn 10MB的时候实际Eden大约是8MB每个Survivor约1MB。如果应用创建对象速率非常高Survivor很容易顶不住对象会直接晋升到老年代反而加剧老年代的GC压力。一个对象的完整生命周期大概是这样的新对象基本分配在Eden区Eden满了触发Minor GC存活对象进入Survivor0年龄加1。下次Minor GC时Survivor0的存活对象复制到Survivor1年龄再加1同时扫描Survivor1是否也存活着需要复制的对象。当对象年龄达到阈值默认15可通过-XX:MaxTenuringThreshold调整或者Survivor区放不下时对象晋升到老年代。2.3 对象创建的完整流程创建对象这件事很多人以为就是“new一个对象”。书里把步骤拆得很细类加载检查、分配内存、初始化零值、设置对象头、执行构造方法。其中分配内存有两种方式指针碰撞和空闲列表。选择哪种取决于堆是否规整而堆是否规整又取决于垃圾收集器是否带压缩整理功能。Serial、ParNew这类带Compact过程的收集器适用指针碰撞CMS这种基于标记清除的收集器就只能用空闲列表。分配时的并发安全性也是重点。JVM采用两种方案CAS加失败重试保证更新原子性以及本地线程分配缓冲Thread Local Allocation BufferTLAB。我现在写并发代码的时候会刻意关注对象分配是否频繁。如果业务里大量创建生命周期极短的小对象TLAB能够有效减少线程间的锁竞争但这部分信息光看书不容易感知得配合JFRJava Flight Recorder的线程分配统计才能看出效果。3. 垃圾收集器演进从Serial到ZGC的路线图3.1 迭代脉络里藏着JVM设计者的取舍书中把垃圾收集器按代际梳理出了一条清晰的时间线。从JDK 1.3的单线程Serial收集器到CMS这种第一款并发收集器再到G1成为默认最后ZGC、Shenandoah走向低延迟。每条路线的切换都不是单纯性能升级而是应用场景在倒逼设计变化。早期应用规模小单核CPU时代Serial没什么问题。后来多核普及Parallel Scavenge强调吞吐量适合后台计算任务。CMS为了降低停顿让用户线程和GC线程并发执行但引入了碎片化和浮动垃圾问题。G1则换个思路不再坚持物理分代而是把堆拆成很多大小相等的Region从逻辑上维护分代能做到可预测的停顿时间。我说说自己的切身体会。在JDK 8时代如果没人特别指定默认使用Parallel Scavenge加Parallel Old组合吞吐量优先。但换到JDK 11默认的G1在多数场景下延迟表现更稳定。如果你维护的是响应时间敏感的Web服务强烈建议至少升到JDK 11以上并了解G1的关键参数而不是守着老版本不放。3.2 G1的核心机制与调优参数G1让堆变成了棋盘状的Region集合每个Region大小默认从1MB到32MB可通过-XX:G1HeapRegionSize指定。Region可以属于Eden、Survivor或Old还可以当作Humongous区域存放大对象。G1通过维护一个优先级列表优先回收垃圾最多的Region这也就是Garbage First名字的由来。关键参数方面我觉得值得记住下面几个-XX:MaxGCPauseMillis期望停顿时间默认200毫秒。它不是一个硬性强制值而是G1调优的目标设置过小会导致回收跟不上分配速率触发Full GC。-XX:G1NewSizePercent与-XX:G1MaxNewSizePercent控制新生代占用堆空间的上下限比例默认分别是5%和60%。-XX:G1HeapRegionSize决定Region大小。如果大对象太多日志里频繁出现Humongous Allocation就该考虑调大Region尺寸。-XX:InitiatingHeapOccupancyPercent老年代占用率超过45%JDK 8默认就开始并发标记周期。这个值可以根据业务特征调整调低了标记频繁调高了容易等老年代快满才启动来不及回收。我在一个用户行为日志采集服务里把-XX:MaxGCPauseMillis从200改成150同时把InitiatingHeapOccupancyPercent提到55%Full GC频率从每小时一次降到了几乎为零。这里特别想提个醒不要无脑把停顿目标设成50毫秒甚至10毫秒。G1为了满足预期停顿会压缩每次收集的Region数量导致垃圾积压最终整堆回收变成Full GC反而雪上加霜。3.3 ZGC与低延迟场景的思考ZGC的目标是让GC停顿时间控制在10毫秒以内甚至在TB级堆上也是如此。它的核心是读屏障加染色指针通过指针中的48位来记录对象状态从而在并发阶段完成大部分工作。但这套设计和传统内存模型差异很大需要操作系统支持64位指针的某几位做状态标记。我实际在开发环境试用过ZGC版本是JDK 17。对于一个内存堆设为16GB的网关服务ZGC的GC日志显示GC停顿经常在2毫秒到5毫秒之间对比之前G1的几十毫秒确实改善明显。但也得提醒一句ZGC的吞吐量在某些场景下会比G1差一点如果业务是批处理而不是在线交易这些微小的停顿其实无所谓追求吞吐才是更合理的方向。4. 类加载机制双亲委派模型仅仅是起点4.1 双亲委派模型的前世今生类加载这块最常被面试官考的就是双亲委派。JVM在加载某个类时先委托给父加载器逐级上抛到启动类加载器只有父加载器无法加载时才下沉到子加载器自己尝试。这样设计最核心的目的是避免类被重复加载也保证核心API在Java环境中始终是同一套。但书里真正精彩的部分是打破双亲委派的几个经典场景。JNDI服务通过线程上下文类加载器突破了顶层加载器无法加载底层SPI实现的窘境OSGi和Java模块化系统实现了更灵活甚至网络化的类加载机制Web容器比如Tomcat也实现了自己的ClassLoader结构让不同上下文下的应用互不干扰。我自己维护过一个老旧的Tomcat多应用环境当时一个应用升级了第三方库另一个应用还在用旧版本结果两边都出问题。事后配合上下文类加载器梳理才理解每个Web应用有独立的WebAppClassLoader实例所谓隔离就是靠这条加载链维持的。4.2 类加载的三个阶段与主动引用判定类从加载到使用经历装载、链接、初始化三个阶段。链接又细分为验证、准备、解析。准备阶段会为静态变量分配内存并设置零值而不是赋值。真正执行静态变量赋值和静态代码块是在初始化阶段而且JVM规范明确规定有六种情况会触发初始化比如new对象、访问静态字段、调用静态方法、反射调用、初始化子类触发父类初始化等。这里有个我实际写代码时经常遇到的坑通过子类访问父类的静态字段时只会触发父类的初始化不会触发子类的初始化。这个细节在接口和类混用静态变量时尤其容易踩坑排查类是否初始化可以用-XX:TraceClassLoading观察加载时间线。4.3 自定义类加载器的实践价值自定义类加载器没有想象中那么神秘。继承ClassLoader重写findClass方法读取字节码后调用defineClass即可。一个最简单的Demo只需要十几行代码但生产环境的用途非常明确热部署、模块隔离、字节码加密解密。我在一个数据接入平台里用自定义类加载器动态加载不同数据源的驱动包。每个数据源一个独立ClassLoader驱动版本互不影响。配合一个定时检查文件变更的后台线程就能做到在不重启应用的情况下加载新版驱动。这个方案比OSGi轻量太多而且代码量并不大。5. 编译优化与调优实战把知识变成排障能力5.1 即时编译与分层编译JVM里的编译优化内容极其深但学习的时候抓住两个核心就能应付大多数场景解释器与C1/C2编译器之间的协作以及方法内联、逃逸分析这些经典优化手段。分层编译从JDK 7开始引入用C1编译让代码快速获得优化版本用C2编译在运行统计数据充分后生成更极致的机器码。但C2编译对CPU和内存有额外占用如果应用频繁加载大量方法C2可能成为瓶颈。生产环境中我一般保持默认分层编译只有在极少数秒级启动场景才考虑调整CompileThreshold。逃逸分析是JVM判断对象是否逃逸出方法作用域的手段。如果对象不逃逸且可以标量替换JVM就能直接在栈上或寄存器中分配对象减少堆内存压力。注意HotSpot做得最成熟的是标量替换并非真正意义上的栈上分配但这不影响理解。我在读代码时发现同事写了不少“返回List再遍历”的代码每次调用都创建新集合虽然现代JVM会优化一部分但对比之后发现改为复用容器GC负担明显降低。5.2 一个线上CPU飙升问题的复盘有个真实案例想分享给你。某个支付回调服务某个时间点开始CPU从20%暴涨到90%接口延迟飙升。我当时的排查路径是用top -Hp pid找到CPU最高的线程。用printf %x线程ID 转换成十六进制。用jstack pid | grep -A 20 十六进制线程ID找到线程栈。发现大量线程阻塞在自定义的JSON序列化工具类里正在调用一个无参构造的反射方法。进一步看JFR采样结果发现程序里某个对象在循环中被反复创建每个对象创建时都会触发类加载检查和安全点安全点日志里能看到大量线程反复进入安全点。最终修复方式非常简单把序列化工具改为ThreadLocal复用一个实例同时用静态内部类持有预编译好的反射访问器。这个案例我写出来并不是说技术多高深而是想说明一个道理如果不懂JIT、安全点和类加载排查纯业务代码很难联想到根源。读书的时候觉得这些概念抽象排障时才发现每一条都能对上号。5.3 常用排查命令与工具清单jps查看Java进程。jstat -gcutil pid 1000每秒输出GC统计。jmap -heap pid堆信息。jmap -dump:live,formatb,fileheap.hprof pid堆转储。jstack pid线程栈。jcmd pid JFR.start namemyrecording开启JFR。jhsdb jmap --heap --pid pidJDK 9以上替代部分jmap功能。我日常排障的第一选择是JFR加jcmd因为jmap在高压力应用上做Full GC Dump会引发额外停顿而JFR对业务影响极小。JDK 11以后VisualVM的功能基本被JMC取代但JMC需要单独下载很多团队不一定装了。我一般至少会确保在每台服务器上配置好JDK自带工具的环境变量包括jcmd、jstack和jstat以防万一。4.4 类加载排障的一线经验类加载期间的异常排查最常见的是NoClassDefFoundError和ClassNotFoundException。两者有区别前者是类在编译期存在但运行期加载失败常见原因是静态初始化抛异常后者是根本找不到类定义。我在Tomcat环境遇到过典型的NoClassDefFoundError应用升级了某个依赖但WebAppClassLoader里加载了新旧两个版本的类旧类先被某个静态代码块引用初始化失败后后续再访问就报NoClassDefFoundError。这里排查的关键是打印类加载日志我用-XX:TraceClassLoading配合jstack定位最终发现是依赖冲突。提示遇到类相关异常第一步是搞清楚“谁在加载”和“是否加载过”。JDK 9以后模块化对类加载日志的配置有变化用-Xlog:classloadinfo可以替代老版本参数。6. 常见问题与避坑指南6.1 典型JVM异常速查表异常现象可能原因排查方向Java heap space堆内存不足检查-Xmx设置导出堆Dump分析大对象GC overhead limit exceededGC回收效果差98%时间在GC但回收不到2%堆检查堆大小与存活对象结构OutOfMemoryError: Metaspace元空间不足检查类加载器泄漏增强动态类生成StackOverflowError栈深度超限检查递归调用与无限循环引用调整-Xss需谨慎Direct buffer memory直接内存不足排查ByteBuffer.allocateDirect未释放场景Unable to create new native thread线程数超出操作系统限制检查线程池参数与OS ulimit这张表是我从多个线上事故里总结出来的高频清单。每个异常背后对应的处置方式差别很大比如Metaspace泄漏多半是框架动态生成大量类盲目调大-XX:MaxMetaspaceSize只是治标。6.2 压测调优时的参数落地顺序调优最忌讳一股脑堆参数。我给团队定了一个落地顺序先明确业务场景是延迟敏感还是吞吐优先确定选G1还是Parallel。设好堆大小基数一般建议-Xms与-Xmx相等避免堆扩容和收缩带来的额外开销。观察GC日志先解决Full GC频繁的问题。再结合压测数据调整期望停顿、新生代比例等次级参数。每改一个参数压测一轮对比调优前后指标变化。这个顺序看起来简单但很多人第一步就跳过了。其实选择收集器本身才是调优中影响最大的决策后续参数都是在这个框架内做微调。在JDK 8上如果业务是短小请求、底延迟要求高从默认Parallel换到G1往往立竿见影如果还在用CMS建议尽早规划升级路径。6.3 调优示例一个抢购活动的内存优化过程做一个模拟案例来演示完整过程。假设一个抢购活动服务堆设置-Xmx4g活动开始后GC日志显示新生代频繁Minor GC老年代每三分钟一次Full GC接口超时率上升。我用jmap导出堆Dump用MAT打开后看到两个占据大量内存的类。一个是库存预扣记录的ArrayList另一个是用户请求日志的字符串数组。前者本该在活动结束后清理但因为保存在一个静态Map里作为流水账导致对象一直存活。后者每次请求都完整记录HTTP头信息信息量大且没有必要长期保留。修复方案是调整业务代码将库存记录改为分批持久化并移除静态引用请求日志只保留关键字段并设置过期时间。调整之后GC频率从每分钟数次降到每半小时一次接口超时率归零。这个案例说明大部分内存问题不是JVM配置不对而是业务对象生命周期管理不合理。7. 我的阅读方法与实用建议老实说周志明老师这本书第三版有五百多页信息密度极大读一两遍根本记不住。我推荐采用“三层阅读法”。第一层是通读了解框架。第一遍不用死磕每个参数把内存区域、收集器演进、类加载机制、编译优化的主干理清楚。第二层是带着问题精读。比如你在做低延迟服务就把G1和ZGC的章节反复看配合官方文档去理解参数语义。第三层是实战后回炉。每处理完一个线上问题就回到书里找到对应章节重新读一遍此时的理解深度完全不一样。书中的工具篇对各个JDK自带命令行工具做了详尽说明这部分不妨直接当工具手册用。进阶部分关于JIT编译和字节码执行对于想要做中间件或者编译器相关工作的朋友尤其重要但对大部分业务工程师而言理解其存在意义和应用场景即可。我个人最大的收获不是记住了多少个参数而是建立了一种系统性的排查思维。以前遇到故障满脑子都是各种搜索片段现在拿到一个问题会先画出一个运行时的地图问题出在线程栈上、堆里、还是类加载阶段然后逐层排查。这种思路的形成确实靠的是把整本书啃完之后建立的体系感。8. 最后分享一个小技巧回到文章开头的那个报表系统。我后来把排查过程记录下来整理成了一份团队的JVM故障演练文档每隔几个月就换一个模拟故障做一次演练。比如人为写一个内存泄漏点、把一个线程池核心线程数调到异常值让新人按照jstack、jstat、JFR、MAT这套流程去定位问题。实践下来团队整体排障速度提升非常明显。如果你也想做类似的事我建议从最简单的“模拟Full GC”开始写一个不断向ArrayList里添加64KB以上大对象的程序设置好堆大小后运行然后观察GC日志用jmap拉取堆Dump再用MAT找到泄漏的根。整个过程只要一两个小时但对理解对象分配与收集器行为特别有帮助。这本书给了我一个很重要的启发JVM不是一门“读了就会”的静态知识它更像一套需要不断与实际运行数据对话的动态系统。每台机器的CPU核心数、内存带宽、操作系统版本、业务并发模型都不一样照搬别人的参数几乎不可行只有亲手试验、观察、调整才能把书里的原理内化成自己的判断力。希望这份学习笔记能帮你少走一些弯路在排查问题时更有底气。