HotSpot虚拟机提供了多种垃圾收集器,每种收集器都有各自的特点,没有最好的垃圾收集器,只有最适合的垃圾收集器.我们可以根据自己实际的应用需求选择最适合的垃圾收集器.
根据新生代和老年代各自的特点,我们应该分别为它们选择不同的收集器,以提升垃圾回收效率.
STW:工作线程全部停止。
只会使用一个CPU或一条GC线程进行垃圾回收,并且在垃圾回收过程中暂停其他所有的工作线程,从而用户的请求或图形化界面会出现卡顿.
一般客户端应用所需内存较小,不会创建太多的对象,而且堆内存不大,因此垃圾回收时间比较短,即使在这段时间停止一切用户线程,也不会感到明显停顿.
由于Serial收集器只有一条GC线程,避免了线程切换的开销.
ParNew是Serial的多线程版本.
ParNew由多条GC线程并行地进行垃圾清理.但清理过程仍然需要暂停一切其他用户线程.但由于有多条GC线程同时清理,清理速度比Serial有一定的提升.
由于使用了多线程,因此适合CPU较多的服务器环境.
和Serial相比,ParNew使用多线程的目的就是缩短垃圾收集时间,从而减少用户线程被停顿的时间.
Parallel Scavenge和ParNew一样都是并行的多线程、新生代收集器,都使用"复制"算法进行垃圾回收.但它们有个巨大不同点:
吞吐量是指用户线程运行时间占CPU总时间的比例. CPU总时间包括 : 用户线程运行时间 和 GC线程运行的时间. 因此,吞吐量越高表示用户线程运行时间越长,从而用户线程能够被快速处理完.
Serial Old收集器是Serial的老年代版本,它们都是单线程收集器,也就是垃圾收集时只启动一条GC线程,因此都适合客户端应用.
它们唯一的区别就是Serial Old工作在老年代,使用"标记-整理"算法;而Serial工作在新生代,使用"复制"算法.
Parallel Old收集器是Parallel Scavenge的老年代版本,一般它们搭配使用,追求CPU吞吐量. 它们在垃圾收集时都是由多条GC线程并行执行,并暂停一切用户线程,使用"标记-整理"算法.因此,由于在GC过程中没有使垃圾收集和用户线程并行执行,因此它们是追求吞吐量的垃圾收集器.
一种追求最短停顿时间的收集器,它在垃圾收集时使得用户线程和GC线程并发执行,因此在GC过程中用户也不会感受到明显卡顿.但用户线程和GC线程之间不停地切换会有额外的开销,因此垃圾回收总时间就会被延长.
垃圾回收过程 前两步需要"Stop The World"
CMS的缺点
Java9 开始全面废除 CMS
没有遍历到的 - 白色 自己标了,孩子也标了 - 黑色 自己标了,孩子还没标 - 灰色
把 A 再标成灰色,看起来解决了?其实依然漏标!
CMS方案: Incremental Update的非常隐蔽的问题: 并发标记,依旧产生漏标!
于是产生了 G1!
当今最前沿的垃圾收集器成果之一.
没有分代概念,而是将Java堆划分为一块块独立的大小相等的Region.当要进行垃圾收集时,首先估计每个Region中的垃圾数量,每次都从垃圾回收价值最大的Region开始回收,因此可以获得最大的回收效率.
一个对象和它内部所引用的对象可能不在同一个Region中,那么当垃圾回收时,是否需要扫描整个堆内存才能完整地进行一次可达性分析? 当然不是,每个Region都有一个Remembered Set,用于记录本区域中所有对象引用的对象所在的区域,从而在进行可达性分析时,只要在GC Roots中再加上Remembered Set即可防止对所有堆内存的遍历.
依旧前面例子:
因此,还是能追踪到 D,如果不维护 rset,需要扫描其他所有对象!因此只需要扫描该 region 即可~
针对新生代的垃圾回收器共有三个:Serial,Parallel Scavenge和Parallel New。这三个采用的都是标记-复制算法。其中,Serial是一个单线程的,Parallel New可以看成Serial的多线程版本。Parallel Scavenge和Parallel New类似,但更加注重吞吐率。此外,Parallel Scavenge不能与CMS一起使用。
针对老年代的垃圾回收器也有三个:刚刚提到的Serial Old和Parallel Old,以及CMS。Serial Old和Parallel Old都是标记-压缩算法。同样,前者是单线程的,而后者可以看成前者的多线程版本。
CMS采用的是标记-清除算法,并且是并发的。除了少数几个操作需要Stop-the-world之外,它可以在应用程序运行过程中进行垃圾回收。在并发收集失败的情况下,Java虚拟机会使用其他两个压缩型垃圾回收器进行一次垃圾回收。由于G1的出现,CMS在Java 9中已被废弃[3]。
G1(Garbage First)是一个横跨新生代和老年代的垃圾回收器。实际上,它已经打乱了前面所说的堆结构,直接将堆分成极其多个区域。每个区域都可以充当Eden区、Survivor区或者老年代中的一个。它采用的是标记-压缩算法,而且和CMS一样都能够在应用程序运行过程中并发地进行垃圾回收。
G1能够针对每个细分的区域来进行垃圾回收。在选择进行垃圾回收的区域时,它会优先回收死亡对象较多的区域。这也是G1名字的由来。
100g内存时,到头性能. 且G1 浪费空间,fullgc 特别慢!很多阶段都是 STW 的,所以有了 ZGC!
听说你是 zerpo paused GC? Java 11引入了ZGC,宣称暂停时间不超过10ms,支持 4TB,JDK13 到了 16TB!
和内存无关,TB 级也只停顿 1-10ms
原来的GC信息记录在哪里呢?对象头部 ZGC记录在指针,跟对象无关,因此可以immediate memory reuse 低42位指向对象,2^42=4T JDK13 2^44=16T, 目前最大就 16T,还能再大吗??? 后面四位伐表对象不同状态m0 m1 remapped finalizable 18为unused
内存中有个地址 地址中装了01001000 , mov 72,到底是一个立即数,还是一条指令? CPU->内存,通过总线连接,-> 数据总线地址总线控制总线,所以看是从啥总线来的即可 主板地址总线最宽 48bit 48-4 颜色位,就只剩 44 位了,所以最大 16T.
1.pause mark start 2.concurrent mark 3.relocate
4.remap
对象的位置改变了,将其引用也改变过去 - 写屏障(与 JMM 的屏障不同,勿等同!)
而 ZGC 使用的读屏障!