Update README.md

README.md

@@ -13,55 +13,59 @@
 
 ### 勘误列表：
 
-- **Page 46**：到了JDK 7的HotSpot，已经把原本放在永久代的字符串常量池、静态变量等【移出】
+
+#### 以下勘误内容已在第6次重印版（2020-11-5日）修正
+------
+
+- **#6-1 Page 46**：到了JDK 7的HotSpot，已经把原本放在永久代的字符串常量池、静态变量等【移出】
 <br>更正：到了JDK 7的HotSpot，已经把原本放在永久代的字符串常量池、静态变量等【移至Java堆中，在4.3.1节会通过实验验证这一点】
 
-- **Page 70**：在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如【各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等】
+- **#6-2 Page 70**：在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如【各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等】
 <br>有同学反应太过拗口，修改为：在虚拟机栈（栈帧中的本地变量表）中的引用的对象，譬如【当前正在运行的方法所使用到的参数、局部变量、临时变量等】
 
-- **Page 94**：-XX:GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，这个参数设定为N的话，表示用户代码执行时间与总执行时间之比为N：N+1。譬如把此参数设置为19，那允许的最大垃圾收集时间就占总时间的5%（即1 /(1+19)），默认值为99，就是允许最大1%（即1 /(1+99)）的垃圾收集时间。
+- **#6-3 Page 94**：-XX:GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，这个参数设定为N的话，表示用户代码执行时间与总执行时间之比为N：N+1。譬如把此参数设置为19，那允许的最大垃圾收集时间就占总时间的5%（即1 /(1+19)），默认值为99，就是允许最大1%（即1 /(1+99)）的垃圾收集时间。
 <br>整一段修正为：-XX:GCTimeRatio参数的值应为设置为一个正整数，表示用户期望虚拟机消耗在GC上的时间不超过程序运行时间的1/(1+N）。默认值为99，含义是尽可能保证应用程序执行的时间为收集器执行时间的99倍，也即是收集器的时间消耗不超过总运行时间的1%。
 
-- **Page 243**：表6-26，第6行：ACC_INTERFACE 【0x0020】
+- **#6-4 Page 243**：表6-26，第6行：ACC_INTERFACE 【0x0020】
 <br>更正：ACC_INTERFACE 【0x0200】
 
-- **Page 256**：如果v在目标类型T（int或long）的表示范围之【类】
+- **#6-5 Page 256**：如果v在目标类型T（int或long）的表示范围之【类】
 <br>更正：如果v在目标类型T（int或long）的表示范围之【内】
 
-- **Page 274**：接着由虚拟机生成一个代表该数组维度和元素的【数组对象】。
+- **#6-6 Page 274**：接着由虚拟机生成一个代表该数组维度和元素的【数组对象】。
 <br>更正：接着由虚拟机生成一个代表该数组维度和元素的【数组类型】。
 
-- **Page 317**：本例中为一项【CONSTANT_InterfaceMethodref_info】常量
+- **#6-7 Page 317**：本例中为一项【CONSTANT_InterfaceMethodref_info】常量
 <br>更正：本例中为一项【CONSTANT_Methodref_info】常量
 
-- **Page 331**：图8-6 执行偏移地址为【1】的指令的情况
+- **#6-8 Page 331**：图8-6 执行偏移地址为【1】的指令的情况
 <br>更正：图8-6 执行偏移地址为【2】的指令的情况
 
-- **Page 385**：代码清单10-18 第13行需修改方法名称，以符合输出结果：
+- **#6-9 Page 385**：代码清单10-18 第13行需修改方法名称，以符合输出结果：
 <br>`protected void BADLY_NAMED_CODE()` { 修改为 `protected void Test() {`
 
-- **Page 392**：脚注：还有一个不太上台面但其实是Java虚拟机必须支持循环体触发编译的【理由，是】诸多跑分软件的测试用例通常都属于第二种，如果不去支持跑分会显得成绩很不好看。
+- **#6-10 Page 392**：脚注：还有一个不太上台面但其实是Java虚拟机必须支持循环体触发编译的【理由，是】诸多跑分软件的测试用例通常都属于第二种，如果不去支持跑分会显得成绩很不好看。
 <br>更正为：还有一个不太上台面但其实是Java虚拟机必须支持循环体触发编译的【理由是：】诸多跑分软件的测试用例通常都属于第二种，如果不去支持跑分会显得成绩很不好看。
 
-- **Page 419**：p.y = 42
+- **#6-11 Page 419**：p.y = 42
 <br>更正：p.y = 42【;】
 
-- **Page 420**：int py = 42
+- **#6-12 Page 420**：int py = 42
 <br>更正：int py = 42【;】
 
-- **Page 431**：与【图11-11】和【图11-12】所示相比，虽然没有了箭头
+- **#6-13 Page 431**：与【图11-11】和【图11-12】所示相比，虽然没有了箭头
 <br>更正：与【图11-13】和【图11-14】所示相比，虽然没有了箭头
 
-- **Page 443**：Java内存模型的基础设计并未改变，即使是【这四操作种】对普通用户阅读使用起来仍然是并不方便。
+- **#6-14 Page 443**：Java内存模型的基础设计并未改变，即使是【这四操作种】对普通用户阅读使用起来仍然是并不方便。
 <br>更正：Java内存模型的基础设计并未改变，即使是【这四种操作】对普通用户阅读使用起来仍然是并不方便。
 
-- **Page 467**：在【第10章】里我们讲解“final关键字带来的可见性”时曾经提到过这一点
+- **#6-15 Page 467**：在【第10章】里我们讲解“final关键字带来的可见性”时曾经提到过这一点
 <br>更正：在【第12章】里我们讲解“final关键字带来的可见性”时曾经提到过这一点
 
-- **Page 472**：在【第10章】中我们知道了主流Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的
+- **#6-16 Page 472**：在【第10章】中我们知道了主流Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的
 <br>更正：在【第12章】中我们知道了主流Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的
 
-- **Page 480**：锁削除是指虚拟机即时编译器在运行时，对一些代码中要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。
+- **#6-17 Page 480**：锁削除是指虚拟机即时编译器在运行时，对一些代码中要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。
 <br>这句话有读者反应不通顺，整句修改为：锁消除是指虚拟机即时编译器在运行时检测到某段需要同步的代码根本不可能存在共享数据竞争而实施的一种对锁进行消除的优化策略。
 
 #### 以下勘误内容已在第5次重印版（2020-9-11日）修正