论GC

2018-11-13 本文已影响0人小吉快跑呀

几个名词

Minor GC——年轻代中的GC操作
Full GC——老年代中的GC操作

几种引用

强引用（Strong Reference）——只要存在，就不会被安排
软引用（Soft Reference）——只有实在没空间准备要凉的时候才会被安排
弱引用（Weak Reference）——下一轮GC到来，就会被安排，不管实际上还够不够空间
虚引用（Phantom Reference）—— 想怎么安排就怎么安排，只是用来告诉持有引用的用户，你的东西被安排了

几个分代

为什么会有分代
我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。
对象能活多久
数据证明，我们应用中的对象在80%以上都是秒死亡的，也就是活不过一个GC轮回。

年轻代——放刚出生的对象
老年代——放老对象，就是那些在年轻代中生存了几个GC轮回的对象
持久代——存放类信息、常量池、静态字段、方法等，一般不会回收了（但是现在被一个叫元空间的东西给替代了，持久代还是归JVM管的一块内存，但元空间就不是了，它直接就是计算机的一块内存）

给引用赋空值，但是他却就是不空

A.HELP = new A();
A.HELP = null;
print((A.HELP == null) + "");

这段代码居然可以运行如下：

false

原来，A中进行了这样的操作：

class A {
    static A HELP= null;
    @Override
    void finalize() throws Throwable {
        super.finalize();
        HELP = this;
    }
}

为啥子重写了finalize方法就可以使赋空值无效呢？其实关键是他方法里面的赋值操作，他把自己赋值给了静态变量HELP，下面来说说GC是如何给对象判死刑的

给对象判死刑

当做完第一次可达性分析之后发现目标对象和GC Root并不相连，那么就会去看看需不需要执行对象的finalize方法（finalize没有被执行过或者没有被重写，这两种情况都认为需要执行），认为需要执行finalize的对象都会被加入队列中，否则直接杀死。加入了队列的对象都会排队被系统调用finalize方法，调用过后GC将再标记一次队列中的对象，加入此时对象与GC Root有链接，那么放生，否则GG

被安排的过程
所以说对象可以在finalize方法中自救，不过只有一次机会，因为上面说了，finalize被执行过一次的对象是不会进入队列的，是直接GG的

垃圾收集算法

标记-清除

就是将要回收的块标记出来，然后清掉，这样的问题是会产生很多碎片区域

复制

复制算法就是以一块完整的区域为GC目标，GC它时，将区域中还存活着的对象都复制到另一个空闲区域，然后直接清空整个目标区域，这样就不会产生碎片，但是复制消耗大，并且需要空间大

标记-整理

他和标记清除的不同就是，标记要删除的块之后，它会把存活的对象推向一侧（玩过2048的同学可以感受一下这是什么操作），然后删掉剩余区域

Stop The World

当发生GC时，正在执行Java code的线程必须全部停下来，才可以进行垃圾回收，这就是熟悉的STW（stop the world），但是并不是说停就停的，线程需要跑到最近的安全点才能够挂起，所以说GC操作耗时，开销大。考虑这样一种情况，某个线程跑不到安全点，也就是说，他本来就挂起了，那么这时候GC操作就很难受，因为它必须要等所有线程都在安全点了才能开始。为了尽量避免这样的情况，又引出了另外一个玩意叫安全区，就是把点扩展为面，在一段区域内，引用关系不会发生变化，这就叫安全区。

各种收集器

Serial

单线程啊，不行啊，而且不支持和用户线程并发，在GC的时候会停掉用户线程

ParNew

多线程了，但是还是不支持和用户线程并发

Parallel Scavenge

很像前者ParNew，区别就是后者适合后台工作的应用，就是那种不需要交互的东西，因为这个收集器优化的点不在如何缩短停止掉用户线程的时间长短，而是在于吞吐量（用户代码运行时间/（用户代码运行时间+GC时间））

Serial Old

和第一个收集器只有收集算法上的区别

Parallel Old

多线程，采用“标记——整理”算法

CMS

使用较多的收集器吧，多线程，它的并发标记和并发清理阶段都可以和用户线程并发执行

G1

除了初始标记阶段，其他阶段都可以并发执行，并发标记阶段、回收阶段可以与用户线程并发，好像很棒棒？但是还不成熟，很水。

一般如何分配

优先放在Eden

科普一哈，年轻代中有两种区，Eden区和Survivor区，通常是8:1的大小关系

当对象不是超级大的情况下，都优先塞进Eden区，要是塞不下了就来一个Minor GC，然后一般就有足够空间放下它。

大对象直接放老年代

在优先分配到Eden区的时候，如果对象大于Eden那就直接放进老年代

在年轻代中活久了的对象放进老年代

这个一看就懂啦，老了就换区啊，一般有一个触发换区的岁数。对象经历一次GC，岁数就加一

动态年龄判断

感觉这个其实有点像平均年龄的概念，但是又有所区别。在Survivor中相同年龄的对象综合达到Survivor区的一半大小时，超过这个年龄的对象也会转移到老年代

担保机制

考虑这样一种情况，在Minor GC中，年轻代中想要存活下来的对象太多，Survivor区放不下，那这时候咋子办咯。这时候就需要老年代分一部分来存放对象了。但是，这里要知道一个事实，年轻代中到底会有多少对象存活下来在Minor GC完成前系统是无法知道的，因此根本不知道老年代中的可用空间够不够存放多出来的对象。这时候就需要冒险了：担保机制中，老年代每次都会记录有多少对象过来了，这样系统就可以算出一个平均值，当要担保的时候就以这个平均值为参考，认为它就是这次要担保的空间大小，若老年代中的可用空间小于它的话就触发Full GC来清理一波老年代，再来Minor GC

论GC