简介《深入理解Java虚拟机JVM高级特性与最佳实践第3版》PDF电子书面向希望系统掌握JVM原理、排查内存与性能问题的Java开发者及进阶学习者。全书围绕Java技术体系、虚拟机家族、运行时数据区域与内存溢出实战展开并深入讲解垃圾收集算法与Serial、CMS、G1、Shenandoah、ZGC等收集器辅以jps、jstat、jmap、jstack、JHSDB、JConsole、VisualVM、Java Mission Control等监控调优工具和真实案例。资源包共1个PDF文件大小28.65MB单册完整呈现便于离线阅读与按章节查阅。已有747人学习下载。读者可据此建立从类文件结构、类加载机制、字节码执行引擎到内存分配、故障诊断与性能调优的知识链路也可结合书中的OOM异常、收集器参数和调优案例对照实践提升定位JVM问题与优化Java应用的能力。1. JVM 底层为什么“会写 Java”和“懂 JVM”之间隔着一道性能鸿沟同一个接口两个人写出来的代码都能跑通上线后一台机器 CPU 使用率稳定在 30%另一台机器每两小时就一次长停顿、抖动到 800ms——差异往往不在业务逻辑而在写代码的人脑子里有没有那张 JVM 的内存地图。很多人以为虚拟机是“黑匣子”其实它做的每一件事都有代价与取舍对象分配在 Eden、晋升到老年代、瞬时停顿、方法内联、逃逸分析、锁消除全都可以被预判和验证。这门被称为“八股文重灾区”的知识真正值钱的地方不是背出收集器名字而是让你在看到一次 GC 日志、一段卡顿曲线的瞬间知道该翻哪一页。下面这套 JVM 底层机制拆解从内存区域一路走到执行引擎与并发模型把“为什么这么设计”讲透。2. 内存区域划分为什么 OOM 有四种而不是一种对象创建、对象布局、对象访问定位这三件事串起来其实是一条极其精炼的流水线类加载检查 → 分配内存 → 零值初始化 → 设置对象头 → 执行构造方法。真正决定你排查效率的是分配发生在哪块区域以及那块区域满了之后会抛哪种错。2.1 七块运行时数据区与各自的溢出边界HotSpot 把运行时内存切成程序计数器、虚拟机栈、本地方法栈、Java 堆、方法区、运行时常量池、直接内存。前三个是线程私有的后三个是线程共享的加上一块不受堆管理约束的直接内存。这个划分不是为了好看而是为了回答两个问题谁需要被 GC 管谁不需要。程序计数器是唯一不会抛 OOM 的区域它只记录当前线程执行的字节码行号字节码解释器靠它跳转虚拟机栈以栈帧为单位服务方法调用每个栈帧装着局部变量表、操作数栈、动态连接和返回地址方法区在 JDK 8 之后由永久代换成元空间搬到了本地内存。这个搬家的动机很直接永久代受-XX:MaxPermSize硬上限约束字符串常量池和动态生成类一旦膨胀就容易撞死在一堵写死的墙上。区域线程归属主要溢出类型典型诱因程序计数器私有无——虚拟机栈私有StackOverflowError / OOM递归过深、栈帧过大本地方法栈私有StackOverflowError / OOM本地方法递归Java 堆共享OutOfMemoryError: Java heap space对象持续增长、泄漏方法区/元空间共享OOM: Metaspace动态生成类、CGLib 代理运行时常量池共享OOM: Metaspaceintern 滥用、动态常量直接内存共享堆外OOM: Direct buffer memoryNIO ByteBuffer 未释放这张表的实用价值在于看到java.lang.OutOfMemoryError后面的冒号内容你就已经定位了一半。Java heap space去找对象引用链Metaspace去查类加载器是否泄漏Direct buffer memory去看ByteBuffer.allocateDirect是否只分配不释放unable to create new native thread则往往是线程数打满而非内存不足——这四种错误的排查路径完全不同混为一谈就会浪费掉一整晚。2.2 对象在堆里的三段式创建与指针碰撞对象分配的关键在于“堆是否规整”。如果收集器采用标记-整理或复制算法空闲内存是连续的分配只需要把指针挪一下这就是指针碰撞如果采用标记-清除内存碎片化就得靠空闲列表维护可用块。选哪种分配方式早在选择收集器的那一刻就被决定了这也是为什么 G1、ZGC 的分配路径和 Serial 完全不同。并发场景下还有一层多个线程同时分配指针会打架。HotSpot 给每个线程预分一块 TLAB本地线程分配缓冲线程在自己的 TLAB 里碰撞用完再换新的。// 伪代码TLAB 分配的核心判断源自 HotSpot 的 fast path 思路 // 1. 先尝试在 TLAB 内分配无锁、无 CAS最快路径 if (tlab.top size tlab.end) { obj tlab.top; tlab.top size; // 指针碰撞仅改本线程私有指针 return obj; } // 2. TLAB 不够走慢路径重新申请 TLAB 或直接在 Eden 加锁分配 return allocate_slow_path(size);这段逻辑的重点不是代码本身而是为什么快TLAB 把共享的分配指针私有化把 CAS 竞争从每次分配降低到每次 TLAB 用完。参数-XX:UseTLAB默认开启、-XX:TLABSize控制初始大小-XX:TLABRefillWasteFraction决定浪费容忍度。知道这层你就能解释一个现象小对象密集分配的程序即便堆不大也不容易撞锁因为绝大部分分配从未离开过线程私有区。对象的内存布局也值得记住对象头Mark Word 类型指针→ 实例数据 → 对齐填充。Mark Word 里塞的是哈希码、GC 分代年龄、锁状态标志后面讲偏向锁的时候会再回到这几个 bit 上。3. 垃圾收集为什么引用计数被淘汰可达性分析赢在哪“对象什么时候死”这个问题直接决定了整个内存回收体系的形状。引用计数看起来最符合直觉有个计数器加一减一归零就回收。它在 Python、Swift 里活得好好的Java 却弃之不用原因不是实现难而是无法处理循环引用——两个对象互相持有计数永远不为零内存就永久漏了。对一门主打自动内存管理的语言这是致命缺陷。3.1 可达性分析与三色标记的并发难题Java 采用的是可达性分析从一组称为 GC Roots 的对象出发沿引用链遍历走不到的对象判死。GC Roots 包括虚拟机栈中引用的对象、方法区静态属性引用的对象、常量引用的对象、本地方法栈 JNI 引用的对象等。问题在于用户线程不停标记过程就会“看花眼”。经典的漏标场景有两个都源于并发期间引用关系变化黑色对象新增了对白色对象的引用灰色对象删除了到白色对象的引用。解决办法是两种屏障增量更新记录黑色对象新增的引用标记结束后以这些黑色对象为根重新扫描CMS 用这套原始快照SATB记录灰色对象删除的引用按标记开始时的快照为准G1、Shenandoah 用这套这背后的取舍是真实存在的增量更新会带来重新扫描的开销SATB 则可能保留一些本该回收的“浮动垃圾”。理解这一点你才能读懂 G1 的-XX:G1MixedGCLiveThresholdPercent为什么调大能减少混合回收。3.2 记忆集、卡表与写屏障跨代引用怎么不拖垮性能分代收集有一个天然的麻烦老年代对象可能引用新生代对象而新生代 GCMinor GC如果每次都要扫描整个老年代那就白分代了。HotSpot 的答案是记忆集具体实现是卡表——把老年代按 512 字节切成一张张卡片只要某张卡里的对象引用了新生代就把这张卡标记为“脏”。谁来负责标脏写屏障。在引用字段赋值的那一刻由 JIT 编译进一段额外逻辑// 伪代码卡表写屏障store barrier的核心动作 void oop_field_store(oop* field, oop new_value) { *field new_value; // 1. 正常赋值 if (is_in_young(new_value)) { // 2. 仅当引用指向新生代 card_table.mark_dirty(field); // 3. 把所在卡片标脏 } }关键在第二步的条件判断只有当新值指向新生代时才标脏。这一步判断省掉了大量无意义的卡表写入代价是每次引用赋值多几个指令。为什么值得因为 Minor GC 的根枚举范围从“整个老年代”缩到了“脏卡集合”扫描量可能从几个 G 降到几 MB。参数上-XX:UseCondCardMark就是把这个条件判断显式打开在卡表竞争激烈的大堆上能省下可观开销。提示卡表标脏存在“伪共享”问题——相邻卡同处一个缓存行多线程标脏会互相让缓存行失效。这也是为什么大堆场景下卡表大小-XX:G1CardSize一类值得关注。3.3 收集器演进从串行到并发标记清除的代价转移Serial 单线程停顿ParNew 是它的多核版Parallel Scavenge 追求吞吐量-XX:MaxGCPauseMillis与-XX:GCTimeRatio互相拉扯CMS 首次把停顿拆成多个阶段初始标记、并发标记、重新标记、并发清除。CMS 的意义在于把“长停顿”换成“并发开销 浮动垃圾 碎片”但碎片最终会逼出 Full GC这是它最尴尬的地方。G1 换了个思路把堆切成 Region允许设置期望停顿时间-XX:MaxGCPauseMillis按“回收价值”排序挑 Region 回收这才有了-XX:MaxGCPauseMillis200这种软目标。ZGC 和 Shenandoah 更进一步靠着色指针和读屏障把停顿压到毫秒级代价是更多的内存开销与屏障指令。收集器关注目标是否并发碎片适用堆规模Serial / ParNew简单、停顿短否复制/整理无碎片小堆、客户端Parallel Scavenge吞吐量否无碎片批处理、后台计算CMS低停顿标记并发有碎片中等堆已废弃G1可预测停顿部分并发整理为主大堆、主流选择ZGC / Shenandoah极低停顿全并发无碎片超大堆、低延迟服务4. 类加载与执行引擎为什么同一个类可以被加载两次Java 的“一次编写到处运行”依赖的是一张契约Class 文件。它用固定的魔数0xCAFEBABE开头紧跟版本号、常量池、访问标志、字段表、方法表、属性表。这层格式的稳定性有多狠从 JDK 1.0 到现在Class 文件结构主体几乎没变只在属性表里不断加新成员——模块化加了 Module、ModulePackages嵌套类访问控制加了 NestHost、NestMembers。它是真正意义上的“向后兼容典范”。4.1 类加载五阶段与双亲委派模型加载 → 验证 → 准备 → 解析 → 初始化。这个顺序里有几个容易被忽略的点准备阶段只给静态变量分配内存并赋零值static int a 1在准备阶段 a 是 0到clinit才变 1解析阶段把符号引用换成直接引用可能发生在初始化之后动态绑定初始化有且仅有一次触发条件比如 new、访问静态字段、反射、main方法所在类双亲委派模型的价值在于安全性一个类先交给父加载器找找不到才轮到子加载器。这挡住了伪造java.lang.String的攻击——你写的 String 类会被启动类加载器抢先加载。protected synchronized Class? loadClass(String name, boolean resolve) { Class? c findLoadedClass(name); // 1. 先看自己加载过没 if (c null) { try { if (parent ! null) c parent.loadClass(name, false); // 2. 交给父加载器 else c findBootstrapClassOrNull(name); // 3. 顶层就是启动类加载器 } catch (ClassNotFoundException e) { } if (c null) c findClass(name); // 4. 父加载器搞不定才自己找 } if (resolve) resolveClass(c); return c; }这段代码的先后顺序就是双亲委派的全部。关键在第 4 步findClass才是子类加载器真正干活的入口前面的递归只是继承链的传导。那“同一个类被加载两次”是怎么回事因为 JVM 判定两个类相等的条件是同一个类加载器 同一个全限定名。两个不同的自定义加载器各加载一份在 JVM 眼里就是两个类强转必然ClassCastException。这就是 Tomcat 每个 webapp 独立加载器、OSGi 靠加载器堆叠实现热部署的理论基础。JDK 9 之后有了模块化加载器结构从三层变成“启动 平台 应用 自定义”但委派的本质没变。4.2 栈帧、分派与 invokedynamic执行引擎的心脏是栈帧。用javap -v看任何一个方法你会看到iload_0、iadd、ireturn这类指令它们操作的就是操作数栈——基于栈的指令集不需要寄存器分配指令短、可移植性强代价是指令条数多。方法调用的核心是分派。静态分派看编译期类型重载就是典型例子动态分派看运行期实际类型重写靠的就是它。真正的“玄学”在invokedynamic它把“怎么找方法”这件事交给了CallSiteMethodHandle第一次执行时由BootstrapMethod决定绑定策略之后直接走链接后的调用路径。Lambda 表达式在字节码层就靠它所以它的首次调用开销比普通方法大得多但稳定后与直接调用无异。5. 线上排查这些 JVM 踩坑为什么总是在大促前夜爆发理论讲完落地全靠日志和工具。jps 看进程、jstat -gc 看各区容量与 GC 次数、jmap -histo 看对象 histogram、jstack 看线程栈、jcmd 现在基本能覆盖它们全部JHSDB 则能直接读堆快照做离线分析。下面几条是排查路上摔得最惨的坑。5.1 踩坑一GC 日志里 Full GC 频繁但堆内存只用了一半现象jstat -gc显示老年代使用率正常但 Full GC 每隔几分钟触发一次-XX:PrintGCDetails里有Metadata GC Threshold字样。原因元空间默认没有上限但它的 GC 触发点与堆不是一回事——类被卸载或元空间达到MetaspaceSize阈值时触发 Full GC。如果项目大量使用 CGLib 动态代理、反射生成类每次重启或热更新都留下新的类加载器元空间缓慢增长。解决jcmd pid VM.metaspace看各部分占比设-XX:MetaspaceSize和-XX:MaxMetaspaceSize显式约束排查自定义类加载器是否把加载过的 Class 忘在静态容器里——类加载器泄漏是元空间炸掉的头号原因。5.2 踩坑二堆外内存持续上涨jmap 却看不出问题现象进程 RSS 一路涨到容器 limit 被 OOMKilled但jmap -histo堆内对象分布毫无异常。原因ByteBuffer.allocateDirect分配的是直接内存不受堆大小管辖只受-XX:MaxDirectMemorySize限制默认约等于堆大小。Netty、NIO 框架、压缩/序列化库都是重灾区尤其是忘记ByteBuf.release()的代码路径。解决加-XX:MaxDirectMemorySize与容器 limit 留出余量用 Netty 的ResourceLeakDetector调到 PARANOID 定位泄漏点jcmd pid VM.native_memory开启 NMT 看内存分类。5.3 踩坑三应用无故长时间停顿GC 日志显示 STW 并不长现象请求耗时偶尔尖刺到秒级但 GC 停顿只有几十毫秒。原因极有可能是安全点造成的。虚拟机在很多位置插入安全点线程主动“走到安全点”才能被停住。如果某段代码是长循环且无法被优化成带安全点的形式比如可数循环的边界变量类型不匹配线程就要等很久才能响应 GC 的停顿请求。解决-XX:PrintSafepointStatistics加-XX:PrintSafepointStatisticsCount1观察vmop的sync time把长循环的可数边界改成long或显式插入安全点逻辑避免线程“卡”在循环里不出来。5.4 踩坑四调大堆反而更慢现象把-Xmx从 4G 提到 16G 后单次 GC 停顿与延迟反而上升。原因堆越大标记与整理的工作量越大同时年轻代绝对值变大后新生代回收的存活对象变多。更常见的失误是大对象直接进老年代-XX:PretenureSizeThreshold没配好导致短命大对象污染老年代。解决别盲目扩堆先看对象存活率把-Xmn调到合理比例常见 1/31/4用 G1 代替 CMS让停顿可控开启-XX:PrintAdaptiveSizePolicy观察自适应调整是不是在“帮倒忙”。5.5 踩坑五日志工具开太多自身成了瓶颈现象打开了 JFR、GC 日志、NMT 后吞吐量下降。原因JFR 采样和 NMT 本身有开销长时间开启在高并发服务上是真实负担。解决JFR 按需开启、限定duration与事件类别NMT 只在定位问题时开GC 日志用滚动文件而非 stdout避免 I/O 阻塞业务线程。6. 内存模型与锁优化为什么 synchronized 早就不是性能瓶颈并发这块最反直觉的结论是现代 JVM 里的synchronized已经非常快了偏向锁、轻量级锁、锁消除、锁粗化一整套优化把绝大多数场景的竞争成本压到接近零。真正的坑不在锁上而在你以为自己没加锁的地方。6.1 Java 内存模型的三性与先行发生原则主内存与工作内存的抽象本质上是为屏蔽硬件差异而设计的通信模型线程把变量从主内存拷贝到工作内存读写后再写回。由此引出三个性质原子性long和double的非原子性在 64 位机上已基本不是问题但复合操作仍需synchronized或原子类可见性volatile写后立即可见靠内存屏障实现有序性编译器与 CPU 都可能重排happens-before是判定依据先行发生原则的几条规则值得背程序次序规则、监视器锁规则、volatile 变量规则、线程启动/终止规则、传递性。排查并发 bug 时先问一句“这里有没有 happens-before 关系”比瞎猜靠谱得多。volatile的语义常被误解成“轻量级 synchronized”实际上它不保证原子性只保证可见性与禁止重排。i套上 volatile 依然是错的。6.2 从偏向锁到锁粗化HotSpot 的几层锁优化对象头 Mark Word 里那几位锁标志承载了整个锁优化体系偏向锁只有一个线程访问时把线程 ID 记在 Mark Word 里后续进入不需要任何同步操作。撤销偏向锁的代价较高所以要在“确实存在竞争”时才撤销——高并发场景下-XX:-UseBiasedLocking关掉反而更快轻量级锁用 CAS 把 Mark Word 指向栈帧中的锁记录失败就膨胀成重量级锁锁消除JIT 通过逃逸分析发现锁对象不会逃逸出方法直接把锁抹掉锁粗化把循环内连续的加锁合并成一次大锁减少进出开销// 锁粗化示意JIT 可能把循环内的加锁提到循环外 for (int i 0; i 1000; i) { synchronized (lock) { // 每次迭代都加解锁开销大 counter; } } // 优化后等价于 synchronized (lock) { for (int i 0; i 1000; i) { counter; } }注意这不是源码级的改写而是 JIT 在编译期做的变换。你看到的源码不变行为却变了——这也是分析锁问题必须以字节码和 JIT 日志为准的原因。6.3 协程为什么是下一站内核线程的局限在于上下文切换成本与栈空间占用一个 Java 线程默认 1M 栈几千个线程就够喝一壶。Java 的虚拟线程Project Loom把线程调度从内核搬到用户态一个平台线程可以承载成千上万个虚拟线程。这带来的变化是深远的之前靠线程池 回调写的高并发代码可以用同步写法直接表达。本次第 3 版还没写到虚拟线程的落地但书里对协程这一方向的前瞻是很多人忽略的隐藏彩蛋。7. 从“背结论”到“能验证”我判断一个人是否真懂 JVM 的方式我一直觉得JVM 这门知识最有效的检验方式不是能不能背出 CMS 的四个阶段而是给你一段卡顿日志你能否说出下一步该敲哪条命令。这件事没有捷径只能靠一套“假设 → 验证 → 反证”的习惯。我的做法是给每一次怀疑都配上一条可证伪的命令怀疑堆泄漏就在压测前后各做一次jmap -histo:live对比对象数量增幅看哪个类的实例占比涨得最凶怀疑元空间就看jcmd VM.metaspace里各加载器的类数量是否只增不减怀疑安全点停顿就开-XX:PrintSafepointStatistics看sync time是否远大于vmop本身耗时怀疑锁竞争就用 JFR 的 Java Monitor Blocked 事件看阻塞栈。每一条都指向具体参数和具体输出而不是“再调调看”。这背后其实是三种能力的叠加第一层是结构认知——知道内存怎么分、类怎么加载、字节码怎么执行第二层是取舍判断——明白 CMS 的低停顿是拿碎片换的G1 的可预测停顿是拿 Region 管理成本换的ZGC 的极低停顿是拿着色指针和读屏障换的没有任何一个收集器免费第三层是证据意识——任何调优结论都必须能被日志、命令输出或压测数据复现。三层缺一层就很容易陷入“参数玄学”。有个不太体面但很真实的教训早期排查一次线上抖动我凭直觉把新生代调大结果停顿反而恶化因为存活对象跟着变多复制成本上升。后来养成的习惯是任何与内存、GC 相关的改动先在预发用相同流量跑一次对照拿到jstat前后对比和 GC 日志再动生产。从那以后我每次遇到“调参数就能变快”的直觉都强制走一遍这个验证流程。这份第 3 版的资源在结构上正好贴合这种验证式读法内存区域、收集器、工具、调优案例挤出在第二部分的四章里形成闭环类文件结构、类加载、执行引擎连成执行子系统的主线前端编译、后端编译、内存模型、锁优化覆盖了性能的另外两半。它没有把 JVM 讲成一套待背的结论集而是每讲一个机制都尽量给出可观察的痕迹——GC 日志该看哪一行、JHSDB 该从哪进、实战章节该复现什么现象。想把上面这套排查习惯真正固化下来最省事的路径是照着书里的实战章节自己跑一遍把每条命令的输出和自己的预期对一次再决定要不要深挖源码。资源的获取入口就在手边拿到之后建议先从第二部分读起那是投入产出比最高的一段。希望帮到你。本文还有配套的精品资源点击获取