IcyFenix

attribute_name_index是00 09，查常量池const #9 = Asciz Code;，代表Code属性。 00 00 00 2F就是attribute_length，Code属性的长度，u4正好啊。

总体都是新增和优化功能，现有的理解原理上没有什么改变。但是一些细节会肯定无可避免有变化。 譬如，`Maximum heap size increased from 4TB to 16TB`，这是将ZGC单个视图的地址范围从42bit扩展到44bit，原来系统保留的18bit缩小到了16bt。所以图3-20就应该更新一下。 又譬如，书中写到： > 它与Shenandoah一样做到了几乎整个收集过程都全程可并发，**短暂停顿也只与GC Roots大小相关而与堆内存大小无关**，因而同样实现了任何堆上停顿都小于十毫秒的目标。 这样的话在JDK 15中也还算正确，但在JDK 16合并了[JEP 376](https://openjdk.java.net/jeps/376)之后，停顿时间不仅与堆大小无关，与GC Roots也没有必然联系了，更有底气地保证了low-pause的目标。

你的理解是正确的。勘误中是已经有了，依然感谢你的指正。

感谢指正。 由于栈帧的概念在第二章中详解介绍过，这里从语义上看应该不会有歧义。不过从语言上看确实是拗口，这段描述可改为： > 譬如当前正在运行的方法所使用到的参数、局部变量、临时变量等

感谢指正。这个错误在第467页也有一处，一并更新至勘误。

感谢指正。已经更新至勘误。

感谢指正，把bit写成byte确实是很低级的错误。这个在第5次重印版已经修正。

Full GC就是面向全堆的GC，在论文或者专业GC的书籍中是“Full Heap Garbage Collection"的缩写，可见就是针对“Full Heap”的。在Major GC被[部分资料](https://plumbr.io/handbook/garbage-collection-in-java#minor-gc-major-gc-full-gc)混淆为“只针对老年代的GC”以前，它跟术语“Major Garbage Collection”是等价的。 > Full GC = Minor GC + Major GC 以上提法并不准确。 - 从因果关系看，在没有分代收集之前的GC就是FullGC，有分代之后才出现的Minor GC等概念。所以用等号右边来解释等号左边不符合因果率。 - 从实现角度看，单独实现FullGC无疑会比通过不同收集器针对不同区域分别收集要简单得多，假如只考虑FullGC的话，像记忆集这些结构都没什么存在的必要。所以从等号右边所做的工作比等号左边要更多。 要硬说它们的关系，就是同为垃圾收集，目标范围不同，有的针对全堆，有的针对新生代。用集合或者包含来理解并不恰当，即Appel经典分代中“Full Heap=Young Gen + Old Gen”，并不能推导出“Full...

感谢，好细心，这段测试代码在GitHub仓库中没有上传，需要手工敲，真的有人专门测试了。 已更新至勘误。GitHub仓库中也补充了测试代码。

你好。感谢指正。 Parallel收集器组合意思是“Parallel Scavenge + Parallel Old”的组合。 目前由于HotSpot去掉了一些很奇怪的GC搭配，现在只有Serial GC（Serial + Serial Old）、Parallel GC（Parallel Scavenge + Parallel Old）、CMS（ParNew + CMS）、G1、ZGC、Shenandoah这几种。尤其是Parallel GC的说法，在各种资料中都很常见，应该不会引起歧义。 对于问题二，刚才请教了汉语言文学专业的编辑MM，现在已修改成： 对一些代码要求同步，但是【虚拟机又检测】到不可能存在共享数据竞争的锁进行消除