垃圾收集器

Posted 2020-09-27 jiumao

垃圾收集器

引用计数器：

从gc日志可以看出是回收了，java虚假没有选用引用计数器算法管理内存

 

可达性分析算法

？线程池中线程是维持一个数量还是，用已经有的线程？

 

回收方法区

 

 

垃圾收集器

垃圾收集器根据应用场景和内存回收范围来选择。根据新生代、老年代，高性能服务器、客户端，计算密集场景、高响应场景。选择不同的收集器。

单线程收集器

单线程收集器，是使用单线程去完成垃圾回收工作。在垃圾收集的同时要暂停其它所有的工作线程，直到收集结束。即"Stop The World"。

多线程收集器

并行收集器：多条垃圾回收线程。工作线程处于等待状态。

并发收集器：多线程垃圾回收。工作线程继续运行。

 

HotSpot垃圾回收器

1、Serial（串行收集器）：用于新生代GC，复制算法，启动时默认为Client模式，GC的线程为单线程。单线程性能很高。对于内存较小的新生代，停顿时间很短。

2、ParNew（并行收集器）：与Serial类似，不同点在于它一般用于新生代的并行回收，而且通常情况下运行在Server模式。只有他能与CMS收集器配合工作。

3、Parallel Scavenge（并行回收）：设计目标达到一个可控制的吞吐量。用于新生代回收，复制算法，并行收集。适用于后台预算不需要太多交互的任务。通过参数课控制吞吐量和停顿时间。自适应调节策略打开之后会根据虚拟机监控信息动态调整新生代。

4、Serial Old（串行收集器）：是Serial收集器的老年代版本，使用标记-整理收集算法，主要用于启动模式为Client的JVM或者用于CMS收集器失败后的后备方案。

5、Parallel Old（并行收集器）：是Parallel Scavenge的老年代版本，使用标记-整理收集算法。设计目标为吞吐量有限。搭配Parallel Scavenge，用于高吞吐量以及CPU敏感场合。目前JDK1.8作为默认的垃圾收集器。

6、Concurrent Mark Sweep，CMS（并发收集器）：目标为希望系统停顿时间最短。使用标记-清除算法，根据参数定期清理内存碎片。会产生大量的内存碎片，根据配置定期做碎片整理。如果因碎片问题导致垃圾回收失败，选择Serial 收集器做Full GC。

• CMS Failure Mode

• 上文提到在正常的情况下CMS整个流程的暂停时间都是很短的，一般也就在10ms～100ms左右。然而这与线上的情况并不相符，线上集群在读写压力很大的情况下，经常会出现长时间的卡顿，有些卡顿甚至长达几分钟，导致很严重的读写阻塞，甚至会造成Region Server和Zookeeper之间Session超时，使得Region Server异常离线。实际上，CMS并不是很完美，它会在两种场景下产生严重的Full GC，接下来分别进行介绍。

• Concurrent Failure

• 这种场景其实比较简单，假如现在系统正在执行CMS回收老生代空间，在回收的过程中新生代来了一批对象进来，不巧的是，老生代已经没有空间再容纳这些对象了。这种场景下，CMS回收器会停止继续工作，系统进入 \'stop-the-world\' 模式，并且回收算法会退化为单线程复制算法，重新分配整个堆内存的存活对象到S0中，释放所有其他空间。很显然，整个过程会非常\'漫长\'。但是这种问题也很容易解决，只需要让CMS回收器更早一点回收就可以避免。JVM提供了参数-XX:CMSInitiatingOccupancyFraction=N来设置CMS回收的时机，其中N表示当前老生代已使用内存占新生代总内存的比例，该值默认为68，可以将该值修改的更小使得回收更早进行。

• Promotion Failure

• 假设此时设置XX:CMSInitiatingOccupancyFraction＝60，但是在已使用内存还没有达到总内存60%的时候，已经没有空间容纳从新生代迁移的对象了。oh，my god！怎么会这样？罪魁祸首就是内存碎片，上文中提到CMS算法会产生大量碎片，当碎片容量积累到一定大小之后就会造成上面的场景。这种场景下，CMS回收器一样会停止工作，进入漫长的 \'stop-the-world\' 模式。JVM也提供了参数 -XX: UseCMSCompactAtFullCollection来减少碎片的产生，这个参数表示会在每次CMS回收垃圾之后执行一次碎片整理，很显然，这个参数会对性能有比较大的影响。

7、Garbage-First，G1（并发与并行）收集器：JDK1.7开始使用。目标为未来可以替换CMS收集器，使用标记-整理收集算法。可预测的停顿。并且可以同时用于新生代和老年代。思想：把内存分块，优先回收价值最大的块。关于G1收集器性能的测试。结果是略逊于CMS。

 

理解GC日志

2017-02-21T14:52:06.941+0800: 343679.497:

//GC 表示年轻代垃圾回收 java虚拟机启动以来经过的秒数

[GC2017-02-21T14:52:06.941+0800: 343679.497:

//使用ParNew作为年轻代的垃圾回收：年轻代垃圾回收前的大小->回收后大小//（总大小），回收时间

[ParNew: 164680K->600K(184320K), 0.0022530 secs]

//堆垃圾回收前的大小->堆回收后大小（总大小），回收时间

426032K->261971K(1028096K), 0.0024010 secs]

//用户态、内核态消耗的cpu时间和实际耗时。

[Times: user=0.04 sys=0.00, real=0.00 secs]

 

Serial收集器中的新生代名为"Default NewGeneration"，所以显示的是"[DefNew"。如果是ParNew收集器，新生代名称就会变为"[ParNew"，意为"Parallel New Generation"。如果采用Parallel Scavenge收集器，那它配套的新生代称为"PSYoungGen"，老年代和永久代同理，名称也是由收集器决定的。

 

 

 

垃圾回收时机

回收点

安全区