一、判断对象是否存活的算法
- 引用计数算法:给对象添加一个引用计数器，每当有一个地方引用它时。计数器的值就加1；当引用失效时，计数器的值就减1；任何时刻计数器的值为0的对象就是不可能再被使用的。
Java虚拟机没有采用此方法，原因是它很难解决对象间循环引用的问题。 -
可达性分析算法:通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到达GC Root时没有任何引用链，则说这个对象是不可用的。
在Java中，可作为GC Root的对象包括以下几种:
(1)虚拟机栈(栈帧中的本地变量表)中引用的对象。
(2)方法区中类静态属性引用的对象。
(3)方法区中常量引用的对象。
(4)本地方法栈中JNI(即一般说的Native方法)引用的对象。
可达性算法判定对象是否可回收.png
二、引用
Java将引用分为一下四种:
- 强引用:普遍存在，如Object obj = new Object()这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
- 软引用:软引用描述的是一些还有用但非必须的对象。当系统将要发生内存溢出异常前，将会把这些对象列进回收范围进行二次回收。若这次回收还没有足够的内存，才会抛出内存溢出异常。
- 弱引用:被弱引用关联的对象只能生存到下一次垃圾收集之前，当垃圾收集器工作时，无论内存是否足够，都会回收对象。
- 虚引用:唯一目的就是在该对象被回收时收到一个系统通知。
三、对象的真正死亡
要宣告一个对象真正死亡，至少需要经过两次标记过程：如果对象在进行可达性分析后发现没有与GC Root相连接的引用链，那么它将会被第一次标记，并进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过(finalize()方法只执行一次)，则认为其没有必要执行。当覆盖了finalize()，并且将其与引用链的任何一个对象关联，即可实现自救。
四、垃圾收集算法
-
标记-清除算法:首先标记需要进行回收的对象，在标记完成后统一回收被标记的对象。
不足:一是效率问题，标记和清除效率都不高。二是空间问题，标记清除后会产生大量不连续的内存碎片，当分配较大对象时，由于无法得到连续的内存空间导致提前触发另一次垃圾回收动作。
标记-清除算法.png -
复制算法:将可用内存划分为大小相同的两块，每次只使用其中的一块。当这一块的内存快用完时，就把还存活的对象复制到另一块上面，然后把已使用的内存空间一次清理掉。缺点是浪费内存。
现在的商业机使用这中算法来回收年轻代。由于绝大部分的新生代对象是"朝生夕死"，所以并不需要按1:1的比例划分内存空间。一般是将其分为一块较大的Eden空间和两块较小的Survivor空间(默认是8:1)，每次使用Eden和其中一块Survivor。回收时将他们中存活的对象放到另一块Survivor中。当Survivor空间不够用时，需要依赖其他内存(这里指老年代)进行分配担保。
内存的分配担保机制:如果另一块Survivor空间没有足够的空间存放上一次新生代存活下来的对象，这些对象将通过分配担保机制进入老年代。
复制算法.png -
标记-整理算法:标记过程与标记-清除算法一样，但后续步骤不是直接对可回收的对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
标记-整理算法.png 分代收集算法:根据对象的存活周期将内存分为几块。一般把Java对分为新生代和老年代，根据各个年代的特点选择合适的收集算法。新生代中，每次都有大量的对象死去，只有少量存活，则采用复制算法。老年代中对象存活率高，没有额外的空间对它进行分配担保，就必须采用分配-清除算法，或者分配-整理算法进行回收。
五、发起内存回收
- GC Roots枚举:虚拟机应当有办法直接得知哪些地方存放着对象的引用，在HotSpot实现中，是通过使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成时，它就把对象内什么偏移量上是什么数据类型的数据计算出来，在JIT编译中，也会在特定的位置记录下栈和寄存器中哪些地方是引用。这样GC在扫描时就可以直接得到这些信息了。
- 安全点:HotSpot没有为每条指令都生成OopMap，只是在特定的位置记录了这些信息，这些位置称为安全点，程序只有在到达安全点时才停顿下来进行GC。
有两种方法使所有线程跑到最近的安全点再停顿下来:
(1)抢先式中断(极少用):在GC发生时，首先把所有线程中断，如果有线程不在安全点上，就恢复该线程，使其跑到安全点上。
(2)主动式中断:在GC发生时，不直接对线程进行操作，仅仅通过简单设置一个标志，各个线程主动轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点重合。 - 安全区域:它指在一段代码片段之中，引用关系不会发生变化，在这个区域的任意地方开始GC都是安全的。
它可以看做安全点的扩展，主要是解决线程处于Sleep或者Blocked状态时，线程无法响应JVM中断请求的情况。
在线程执行安全区域的代码时，首先标识自己进入了安全区。当发生GC时，就不用管标识为安全区状态的线程了。当线程离开安全区时，它要检查系统是否完成了根节点的枚举(或整个GC过程)，如果完成了，则线程继续执行，否则要等待到收到可以离开安全区的信号为止。
六、垃圾收集器
-
Serial收集器:单线程收集器，单线程不止说明它只会用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾回收时，必须暂停其他工作线程，直到它收集结束。
它是虚拟机在Client模式下默认的新生代收集器。
优点:比起其他收集器的单线程，简单而高效。
Serial收集器运行示意图.png -
ParNew收集器
它其实就是Serial收集器的多线程版本，是运行在Server模式下虚拟机首选的新生代收集器，除了Serial收集器，只有它能与CMS收集器配合工作。
ParNew收集器运行示意图.png -
Parallel Scavenge收集器
与其他收集器缩短用户线程的停顿时间目的不同，它的目标是达到一个可控的吞吐量(运行用户代码/(运行用户代码+垃圾收集时间))，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器运行示意图.png -
Serial Old收集器
Serial的老年代版本，单线程收集器，使用标记-整理算法，主要是给Client模式下的虚拟机使用。
两大用途:一是与jdk1.5及之前版本与Parallel Scavenge收集器搭配使用；二是作为CMS收集器的后备方案。
Serial Old收集器运行示意图.png -
Parallel Old收集器
与Parallel Scavenge形成吞吐量优先的组合，适用于在注重吞吐量和CPU资源敏感的环境。
Parallel Old收集器运行示意图.png
-
CMS收集器
一种以获取最短停顿时间为目的收集器，基于标记-清除算法实现。响应速度快，停顿时间短。总体上看，CMS内存回收是与用户线程一起并发执行的。
整理过程有如下四个步骤:
(1)初始标记:需“Stop the World”，仅标识GC Root能直接关联的对象，速度很快。
(2)并发标记:进行GC Root的遍历。
(3)重新标记:需“Stop the World”，修正并发标记期间程序继续运作而导致的标记产生变动的那部分对象的标记记录。时间比初始标记稍长，比并发标记短。
(4)并发清除
三个缺点:
(1)对CPU资源非常敏感。因占用一部分线程(或者说CPU资源)，导致应用程序变慢，总吞吐量降低。
(2)无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败导致另一次Full GC产生。
浮动垃圾:由于CMS进行清理时程序还在运行，在这个过程中会产生垃圾，并且这些垃圾只能在下一次收集中才能被清理。CMS需要预留一部分空间提供给并发运行的程序使用，故不能等年老代填满再收集。
(3)可能会产生大量的空间碎片，导致提前触发另一次Full GC。
CMS收集器运行示意图.png -
G1收集器
四个优点:
(1)并行与并发:利用多CPU、多核缩短Stop the World时间，在GC时，可通过并发的方式让Java程序继续执行。
(2)分代收集
(3)空间整合:从整体看是基于标记-整理算法，从局部(两个Region之间)看是基于复制算法实现的。并且在运行期间不产生内存空间碎片，收集后能得到规整的内存。
(4)可预测的停顿:能建立可预测的停顿时间模型。
注意:G1收集器将整个Java对规划成多个大小相等的独立区域(Region)，使用Region划分内存空间以及有优先级的区域回收方式，保证了它在有限时间内获取尽可能高的收集效率。当Region不可能是孤立的，一个对象被分配在一个Region中，不仅能被本Region的其他对象引用，还能被整个Java堆上的任意对象引用。
虚拟机采用Rememberd Set来避免全堆扫描，每个Region对应一个Rememberd Set，虚拟机在对引用类型的数据进行写操作时，产生一个Write Barrier暂时中断写操作，检查阴影的对象是否位于不同的Region之中，若是，则把引用信息记录到Rememberd Set中。当进行内存回收时，在GC根节点枚举范围加入Rememberd Set即可保障不进行堆扫描也不出现遗漏。
四个步骤:
(1)初始标记:仅标识GC Root能直接关联的对象，并且修改TAMS的值，让下一阶段用户程序并发运行时，能在正确的Region创建新对象，这阶段需停顿线程，但时间极短。
(2)并发标记:从GC Root开始对堆中对象进行可达性分析，找出存货的对象，耗时较长，但可与用户程序并发执行。
(3)最终标记:修正并发标记期间程序继续运作而导致的标记产生变动的那部分标记记录。虚拟机将这些变化记录在线程的Rememberd Set Logs中，在最终标记阶段中将其整合到Rememberd Set中，需停顿线程，但可并行执行。
(4)筛选回收:对各个Region的价值回收价值和成本进行排序，根据用户期待的GC停顿时间定制回收计划。
G1收集器运行示意图.png
七、内存分配
- Minor GC和Full GC
新生代GC(Minor GC):指发生在新生代的垃圾收集动作，频繁但回收速度快。
老年代GC(Major GC/Full GC):指发生在老年代的GC，出现了Full GC一般会伴随至少一次Minor GC，它的速度不Minor GC慢10倍不止。 - 对象的内存分配，往大方向讲就是在堆上分配(也可能经过JIT编译拆散为标量类型间接地在栈上分配)，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，则按线程在TLAB上分配。少数情况直接分配在老年代。
- 对象优先在Eden区中分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。如果对象依然存活，并且能被Survivor容纳时，将被移动到Survivor空间，并且年龄设为1。对象在Survivor区每熬过一次Minor GC，年龄加1，当增加到一定程度时(默认是15)，将晋升到老年代中。大对象直接进入老年代。
- 动态年龄判定:为了更好地适应不同程序的内存状况，如果Survivor空间中相同年龄的所有对象大小总和大于Survivor空间一半，年龄大于或等于该年龄的对象直接进入老年代。
- 在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象大小的总和，若是，则可以确保该Minor GC是安全的。
- 有多少对象会存活下来在实际回收前是不知道的，所以只好取之前晋升到老年代对象的平均值作为经验值，与老年代剩余空间大小进行比较，决定是否进行Full GC腾出更多空间。
