JVM垃圾回收机制

要弄清JVM的垃圾回收就要弄清这三个问题：
1，回收哪里对象（who，where）
2，什么时候回收，如何判断(when)
3，怎么样回收（how）

1，回收对象

分为两个地方，主要在Jvm的堆内存（存放实例对象的内存），方法区（存放类加载信息和常量池）

方法区回收的：废弃的常量和无用的类，

废弃的常量：

拿举例说，有“abc”字段在常量池中，在系统中并没有任何一个String对象对其进行引用，如果发生垃圾回收并且如果内存要满，必要的时候，就会将“abc”移出常量池。常量池中的接口，方法，字符的符号亦是如此。

无用的类：

1，该类的所有实例化对象都回收，没有该类的实例化对象。
2，加载该类的ClassLoader对象被回收
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

满足以上三个条件的类可以进行垃圾回收，但是并不是无用就被回收，虚拟机提供了一些参数供我们配置

2，什么时候回收，如何判断

垃圾回收器在做回收的时候，主要判段哪些内存时需要回收的？哪些对象时死亡的，可以回收，哪些是没有死亡的，是不能回收的？
判断回收的方法主要有两种：

2.1 引用计数法

就是对每一个对象都加一个计算器，被引用时+1，被释放时-1，然后为0的就不会在使用的，但这种算法很难解决两种对象相互引用的情况，还有也不能解决循环引用的情况，

2.2可达性分析法

这种方法根据从根结点叫GCroot，从GCroot对象开始向下搜索，搜索的路径称为引用链，若对象存在引用链的则认为它是存活的，而没找到的就认为它是死亡的，需要回收，那么问题来了，哪些是GCroot？
Java中有以下四种：
1，虚拟栈内存中引用的对象；
2，方法区中的类静态属性引用对象；
3，方法区中引用的常量对象；
4，本地方法栈中引用的对象

对于可达性分析算法而言，未到达的对象并非是“非死不可”的，若要宣判一个对象死亡，至少需要经历两次标记阶段。

1. 如果对象在进行可达性分析后发现没有与GCRoots相连的引用链，则该对象被第一次标记并进行一次筛选，筛选条件为是否有必要执行该对象的finalize方法，若对象没有覆盖finalize方法或者该finalize方法是否已经被虚拟机执行过了，则均视作不必要执行该对象的finalize方法，即该对象将会被回收。反之，若对象覆盖了finalize方法并且该finalize方法并没有被执行过，那么，这个对象会被放置在一个叫F-Queue的队列中，之后会由虚拟机自动建立的、优先级低的Finalizer线程去执行，而虚拟机不必要等待该线程执行结束，即虚拟机只负责建立线程，其他的事情交给此线程去处理。

2.对F-Queue中对象进行第二次标记，如果对象在finalize方法中拯救了自己，即关联上了GCRoots引用链，如把this关键字赋值给其他变量，那么在第二次标记的时候该对象将从“即将回收”的集合中移除，如果对象还是没有拯救自己，那就会被回收。如下代码演示了一个对象如何在finalize方法中拯救了自己，然而，它只能拯救自己一次，第二次就被回收了

3.怎么样回收

3.1，标记-清除回收

分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，标记完成后统一回收所有被标记的对象
缺点：效率低，后续对于大对象的存储标记清除后会产生大量不连续的内存碎片， 内存碎片太多可能会导致以后程序运行过程中在需要分配较大对象时，无法找到足够的连续内存而不得不提前触发一次垃圾收集动作

3.2，复制法

将内存分为两块，第一块用来存放对象，第二块则不用，当第一块用完了时，将判断为不需要回收的复制到第二块，然后整体将第一块使用的内存清理掉，这样就不用考虑产生碎片化内存，但这样大大降低了内存，缩小了一半，一般在回收新生代时就用这种回收方法。

3.3，标记-整理方法

如果内存中的对象都存活，用复制的算法回收会大大影响性能
此方法：标记存活的对象，向内存一端移动，将边界外的清除

3.4，分代回收

根据对象存活周期，将对象分为两种，新生代，老年代，
新生代用基本采用复制算法，还有使用标记-清除的方法回收；
老年代用标记-整理的算法回收

3.4分代垃圾回收器的工作机制？

https://zhuanlan.zhihu.com/p/159200599

举个栗子：

Java对象的一生：
我是一个java对象，我出生在Eden区，在Eden区有一些跟我一样的兄弟们，我们在Eden区中一起玩，每天都有新的兄弟进来。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，在这里生活非常不稳定。有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我15岁的时候（默认15岁），就被分配到年老代那边，在这里人很多，并且年龄都挺大的。在年老代里，我生活了很久，每次GC年龄就+1，然后被回收。

分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3。

新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1，它的执行流程如下：

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To Survivor区”，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中。

清空 Eden 和 From Survivor 分区；

这时From Survivor 和 To Survivor 分区会互换角色，分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor。

每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。

老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。

对象优先在 Eden 区分配：

多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存。

Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频繁，一般回收速度也非常快；
Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。
大对象直接进入老年代：

新生代使用的是标记-清除算法来处理垃圾回收的，如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。

所谓大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配来说就是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来 “安置” 它们。
虚拟机提供了一个XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制（新生代采用的是复制算法）。

长期存活对象将进入老年代：

虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每过一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15） 就会被晋升到老年代。