JVM垃圾回收篇-垃圾回收器

news2024/11/22 16:30:55

Serial串行：为单线程环境设计且只使用一个线程进行垃圾回收，会暂停所有用户的线程，所以不适合服务器环境，适用于堆内存小，适合于个人电脑

开启串行垃圾回收

-XX:+UseSerialGC = Serial + SerialOld

在这里插入图片描述

单位时间内，stw的时间最短

0.2 0.2=0.4 一小时内总的stw时间最短，单次较长

在这里插入图片描述

开启吞吐量优先的垃圾回收器

-XX:+UseParallelGC ~ -XX:+UseParallelOldGC //开启一个，另一个也会自动开启（jdk1.8默认开启）

+UseParallelGC:开启新生代吞吐量优先垃圾回收,采用复制算法
+UseParallelOldGC:开启老年代吞吐量优先垃圾回收，采用标记整理算法
-XX:ParallelGCThreads=n 设置垃圾回收线程数，如果不设置，默认垃圾回收线程数与CPU核心数保持一致
-XX:+UseAdaptiveSizePolicy 根据GC的情况自动计算计算 Eden、From 和 To 区的大小,晋升阈值也会受到影响，jdk1.8默认开启
-XX:GCTimeRatio=ratio GC时间占比，ratio默认为99,计算公式:gc时间占比=1/(1+ratio),即默认占比为1/100，相当于100分种垃圾回收时间不大于1分钟，如果大于1分钟，会自动调整堆内存大小，加大堆内存
```
heap size++ -> gc count--
```
-XX:MaxGCPauseMillis=ms 垃圾回收最大暂停时间
- 默认200ms,当堆内存增大时，每次gc所需时间也会增大（需要扫描堆中的垃圾，扫描和回收时间都会增大），所以需要保障最大暂停时间意味着heap减小，显然，这与GCTimeRatio相冲突

尽可能让单次stw的时间最短

0.1 0.1 0.1 0.1 0.1 =0.5  单次时间最短 总时间较长

在这里插入图片描述

CMS垃圾回收器采用的是标记清除算法，所以会产生内存碎片
CMS的GC耗时80%都在remark阶段，remark阶段停顿时间会很长
concurrent mode failure:这个异常发生在cms正在回收的时候。执行CMS GC的过程中，同时业务线程也在运行，当年轻代空间满了，执行ygc时，需要将存活的对象放入到老年代，而此时老年代空间不足，这时CMS还没有机会回收老年代产生的，或者在做Minor GC的时候，新生代救助空间放不下，需要放入老年代，而老年代也放不下而产生的
promotion failed:在进行Minor GC时，Survivor空间不足，对象只能放入老年代，而此时老年代也放不下造成的，多数是由于老年代有足够的空闲空间，但是由于碎片较多，新生代要转移到老年带的对象比较大,找不到一段连续区域存放这个对象导致的,发生promotion failed的下一步就会产生concurrent mode fialure，将垃圾回收器退化为SerialOld,此时吞吐量下降严重

阶段一（初始标记）:标记老年代中所有的根对象，包括根对象直接引用的对象，以及被年轻代中所有存活的对象所引用的老年代对象（只是标记一下GC Roots能直接关联到的对象，速度很快），会触发stw
阶段二（并发标记）:从初始标记阶段标记的对象开始找出所有存活的对象

因为是并发运行的，在运行期间会发生新生代的对象晋升到老年代、或者是直接在老年代分配对象、或者更新老年代对象的引用关系等等，对于这些对象，都是需要进行重新标记的，否则有些对象就会被遗漏，发生漏标的情况。为了提高重新标记的效率，该阶段会把上述对象所在的Card标识为Dirty，后续只需扫描这些Dirty Card的对象，避免扫描整个老年代；并发标记阶段只负责将引用发生改变的Card标记为Dirty状态，不负责处理
阶段三（重新标记）:为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要stw
阶段四（并发清除）:这个阶段主要是清除那些没有标记的对象并且回收空间）