新一代垃圾回收器ZGC设计与实现

1、G1的三大缺点：垃圾回收时间长，几百毫秒；内存利用率低，有1-20%的空间浪费；最多支持100G内存，不够用。 ZGC的第一个优化就是优化回收时间，G1的回收时间有80%浪费在复制算法上，这个算法需要STW，ZGC要打破这个停顿，变成并行的。 2、支持的内存大小 （1）G1其实指针的长度是够的，但是G1用空间换时间，对现有内存维护一个RSet来记录，这部分占了20%的内存；而且G1需要STW，这部分性能会有问题；所以大内存撑不了，主要还是性能。 （2）ZGC只能支持4T的原因：目前用到的虚拟指针位只有46位，理论上最大能用48位。这是由于X86_64处理器硬件的限制，目前X86_64处理器地址线只有48条，软件的处理集上可以支持64位，但实际上硬件只有48位能用。 3、GC触发的时机 （1）固定频率触发 （2）按照已经发生的垃圾回收时间，预测下一次垃圾回收的时间 4、垃圾回收的过程： 大的思路是先标记、后复制、在下一个流程里面把持有引用的对象引用地址更新掉； （1）初始标记阶段，这时候Remapped里面是上一次回收结束之后的存活对象，类似于S2区域。 选定M0当做本次的S1，标记期间的新对象都标记成存活对象；这个阶段结束之后，存活对象都在M0标记里了 （2）剩下的M1和Remapped就是垃圾，进入并发转移阶段 按照每个页面的垃圾排序，把M0里的存活对象标记成Remapped，并且把对象换个物理页面；如果遍历到的页面上某个对象是Remapped，那就是垃圾了，不会是自己刚改写的 物理页面里的存活对象转移完了之后，页面就能回收了，如果不回收，也把里面的对象标记成Remapped 并发转移结束之后，存活对象都在Remapped里面，有些是垃圾但是不回收的，也在Remapped里面。 （3）转移之后引用的改写： 转移之前，把引用映射Map置成null 转移的时候，每移动一个对象，就把这个对象转移前后的地址都放在映射Map里面，转移结束之后实际上新对象里的持有引用可能还是旧的 存活对象转移之前，指针标记是M0，这时候有用户线程过来访问，会触发读屏障，先帮忙进行转移 转移之后，指针标记是Remapped，这时候用户线程过来访问，会去引用映射Map里面更新自己的持有引用地址；如果一直没有用户线程访问，拖到标记阶段，标记线程也会做这件事

2024.No41： 24年第18本技术书。2019年出版，很可能是关于ZGC的第一本中文书。讲述关于ZGC的方方面面：内存管理、线程、垃圾回收算法、日志解析、参数设置、基准测试、编译调试，以及Shenandoah GC。值得反复翻阅。 5年过去，JDK22已然发布，相信有更多关于ZGC的优化和改进。 希望看到第二版。

介绍zgc全面，并且对于算法具体实现的原因给予解释。

对ZGC的介绍很详实。 令人耳目一新的是，作者为了更好地描述ZGC整个流程，先从设计思路上为读者理清了一些基本概念，这样让读者不光知其然更知其所以然。 需要好好消化。

内容详实 讲解了zgc算法的细节 内存管理  以及linux内存分配的背景

回收部分讲的挺细致的，源码和调试那块基本都带过，看不太懂…

这本书短小精悍，把ZGC讲得很详细，值得一看

深入了解了ZGC垃圾回收处理器和G1的不同，为以后升级做准备

讲的比较清楚，是研究ZGC非常好的资料

这类书的通病，设计讲的不咋地，反正就是怼源码。。