3.1 概述
垃圾收集器要解决哪些问题？
-
哪些内存需要回收
-
什么时候回收
-
如何回收
引用计数算法：当有一个地方引用，+1，引用失效，-1。 缺点：对象之间相互循环引用的问题。
可达性分析算法：
思路：通过一系列的成为“Gc Roots"的对象作为起始点，从这些节点开始向下探索，搜索所走过的路径成为引用链（Reference Chain)，当一个对象到Gc Roots没有任何引用链相连，则则很难革命此对象是不可用的。
Java
语言中
GC Roots
的对象包括下面几种：
1.
虚拟机栈（栈帧中的本地变量表）中引用的对象
2.方法区中类静态属性引用的对象
3.方法区中常量引用的对象
4.
本地方法栈
JNI
（
Native
方法）引用的对象
2.
引用
强引用
就是在程序代码之中普遍存在的，类似
Object obj = new Object()
这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
软引用
用来描述一些还有用但并非必须的元素。对于它在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存才会抛出内存溢出异常
弱引用
用来描述非必须对象的，但是它的强度比软引用更弱一些，被引用关联的对象只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够都会回收掉只被弱引用关联的对象
虚引用
的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
Finalize方法
任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败了。
fInalize()是Object的protected方法，子类可覆盖该方法以实现资源清理工作。
回收方法区
废弃常量和无用类，如String "abc"。
类要回收满足的条件： 1.该类所有的实例都已经被回收，Java堆中不存在任何实例。 2.加载该类的Class Loader已经被回收。 3.
该类对用的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法
3.3垃圾回收算法
1.
标记-清除算法
：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
不足：效率问题，空间问题（产生大量碎片）。
2.复制算法
将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。
不足：将内存缩小为原来的一半。
实际上，将内存分为一块较大的Eden空间和Survivor空间，每次使用Eden和另一块Survivor。
HotSpot虚拟机默认Eden：Survivor=8：1. 新生代中可用内存空间为整个新生代容量的90%。
3.标记-整理算法
标记之后，让所有存活的对象都向一段移动，然后直接清理掉端边界外的内存。
4.分代收集算法
把Java堆分为新生代和老年代，可以根据各个年代的特点采用适当的算法。
3.4HotSpot算法的实现
Gc进行时必须停顿所有的执行线程，
Stop the world
安全点 程序执行时并非在所有地方都能停顿下来执行GC，只有到达安全点才能暂停。 （存档点） 。
主动式中断：设置一个标志，各个线程执行时主动轮询这个标志，发现中断标志为真就自己中断挂起。
安全区域：
3.5垃圾收集器
1.Serial收集器：
单线程收集器，采用
复制算法： 在进行垃圾收集，必须暂停所有其他工作线程，直到它收集结束。简单而高效，
2.ParNew收集器： Serial收集器的
多线程版本，可以和CMS收集器配合工作。 使用： -XX:+UseParNewGc强制指定。
3.Parallel Scavenge（清楚污物，打扫）是一个
吞吐量优先的处理器 特点：CMS收集器的关注点时尽可能缩短垃圾手机时用户停顿的线程，而他的目标：
达到一个可控制的吞吐量。 控制吞吐时间—XX:MaxGCPauseMillis 设置吞吐量大小：-XX:GCTimeRatio参数。
吞吐量：运行用户代码时间/（运行用户代码时间+垃圾手机时间）
GC停顿时间的缩短时以牺牲吞吐量和新生代空间来换取的。
4.Serial Old收集器，单线程收集器，使用
标记-整理算法。
5.Parallel Old收集器
多线程、标记-整理算法。
6.CMS收集器（Concurrent Mark Sweep) 获取最短回收停顿时间为目标的收集器，
步骤： 初始标记 （单线程）——
并发标记——重新标记（单线程）——
并发清除
重新标记是为了修正并发标记期间因用户程序继续运行运作而导致标记产生变动的那一部分对象的标记记录。
缺点
- CMS收集器对CPU资源非常敏感。 默认启动的回收线程数是（CPU数量+3）/4，CPU不足的情况下，对用户程序的影响就可能变得很大。
- 无法处理浮动垃圾，可能出现失败而导致另一次Full GC的产生。 由于CMS并发清理阶段用户线程还在运行，伴随程序运行自然就还会有新的垃圾产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉他们，只好等待下一次GC时再清理掉。
因此需要预留一部分空间提供并发收集的程序运作使用。
- 基于标记-清除实现，产生大量内存碎片，给大对象分配带来麻烦。
7.G1收集器
特点：
- 并发与并行
- 分代收集
- 空间整合：整体上基于标记-整理算法。局部基于复制算法
- 可预测的停顿
G1可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的回收时间来优先回收价值最大的Region（Gabarage First ——
G1的由来）。
不计算维护Remembered Set的操作，G1收集器的运作大致划分为几个步骤：
1.初始标记
2.并发标记
3.最终标记
4.筛选回收
垃圾收集器参数： SurvivorRatio:新生代中Eden与survivor区域容量比值，默认8。即两者8：1.
3.6内存分配策略与回收策略
对象的内存分配，就是在堆上分配，对象主要分配在新生代的Eden区中，如果启动了TLAB，将按线程优先在TLAB上分配。也可能直接分配在老年代中。
- 对象优先在Eden分配 当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC
- 大对象直接进入老年代 ：如字符串和数组
- 长期存活的对象将进入老年代 虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，且能被survivor容纳的话，将移动到survivor空间。对象在survivor每经历一次Minor GC，年龄就增加一岁，年龄增长到一定之后将进入老年代。
- 动态对象年龄判断 如果在survivor空间中相同年龄的对象大小的总和>survivor空间的大小的一半，则这些对象直接进入老年代中，需要等待年龄判定进入。
- 空间分配担保 在发生Minor GC 之前，虚拟机会检查老年代最大可 用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许那么会继续检查老年代最大可用的连续空间是否大于晋级到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次MinorGC 是有风险的：如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC