4.垃圾回收

一、垃圾回收
1.垃圾回收概述
如何判定对象为垃圾对象
　　引用计数法
　　可达性分析法
如何回收
　　回收策略
　　　　标记－清除算法
　　　　复制算法
　　　　标记－整理算法
　　　　分代手机算法
　　垃圾回收器
　　　　Serial
　　　　Parnew
　　　　Cms
　　　　G1
何时回收

2.判断对象是否存活算法
1.引用计数法
简述：在对象中添加一个引用计数器，每当引用该对象时，引用计数器的值+1，当引用失效时（比如某一引用置为null），引用计数器的值-1。
举例：

public class test {	
	private Object obj;
	public test() {
		byte [] m = new byte[20*1024*1024];
	}
	public static void main(String[] args){
        test t1 = new test();
        test t2 = new test();
        
        t1.obj = t2;
        t2.obj = t1;
        System.gc();
	}	
}

运行结果：

分析：这里创建引用类型对象t1和t2，分别指向堆内存中的test类型的两个实例对象，所以堆内存中两个实例对象的引用计数器分别加1，然后t1中的Object类型的成员变量引用t2，所以堆内存中t2的引用计数器加1，同理，堆内存中t2的引用计数器加1，这时两个引用计数器的值都为2，这时，将t1和t2的引用失效，即让其指向null，这时堆内存中的原来的t1对象和t2对象的引用计数器的值都减1，在执行System.out语句时，两个计数器的值都为1，如果Java虚拟机回收垃圾采用“引用计数法”，则垃圾回收不了（因为引用计数器值不为0），但这里结果显示回收了（因为对象中的定义的20M的内存变成648k，说明垃圾回收了），说明采用的是可达性分析法。

2.可达性分析法
能够作为GCRoots的对象有：
　　虚拟机栈
　　方法区的类属性所引用的对象
　　方法区中常量所引用的对象
　　本地方法栈中引用的对象
分析：被虚拟机栈等（包括上述能够作为GCRoots的对象）直接或者间接引用的堆内存中的对象实例（会构成一个引用链）不会被垃圾回收区清理，若不在引用链中的对象实例会被回收。

3.引用
传统引用定义：如果参数类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。
Java对引用进行了扩充：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。
强引用：指在程序代码之中普遍存在的，类似“Object obj=new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
软引用：用来描述一些还有用但并非必需的对象，对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果第二次回收还没有足够的内存，才会抛出内存溢出异常。
弱引用：用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
虚引用：是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

4.对象的自我救赎（趣味）
概述：即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法。当对象没有覆盖finalize（）方法，或 finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，则直接回收。
　　如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行finalize（）方法，finalize（）方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize（）中成功拯救自己——只要重新与引用链
上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；

public class test{
    public static test SAVE_HOOK = null;
    public void isAlive(){
        System.out.println("yes,i am still alive：");
    }
    
    @Override
    protected void finalize()throws Throwable{
        super.finalize();
        System.out.println("finalize mehtod executed！");
        test.SAVE_HOOK=this;
    }
    public static void main(String[]args) throws Throwable{
    	SAVE_HOOK=new test();
    	
    	//对象第一次成功拯救自己
    	SAVE_HOOK=null;
    	System.gc();
    	
    	//因为finalize方法优先级很低，所以暂停0.5秒以等待它
    	Thread.sleep(500);
    	if(SAVE_HOOK != null){
    		SAVE_HOOK.isAlive();
    	}
    	else{
    		System.out.println("no,i am dead：");
    	}
    	
    	//下面这段代码与上面的完全相同，但是这次自救却失败了
    	SAVE_HOOK=null;
    	System.gc();
    	
    	//因为finalize方法优先级很低，所以暂停0.5秒以等待它
    	Thread.sleep(500);
    	if(SAVE_HOOK != null){
    		SAVE_HOOK.isAlive();
    	}
    	else{
    		System.out.println("no,i am dead：");
    	}
    }
}

运行结果：

分析：首先在堆内存创建test对象，并让方法区中的SAVE_HOOK 指向其，然后让SAVE_HOOK = null ，执行垃圾回收机制，发现有finalize（）可以执行，则进行自我救赎，执行finalize（）方法，把自己的this赋值给test类中的静态引用变SAVE_HOOK，使得SAVE_HOOK指向该将被回收的test对象，从而重新与引用链建立关系，自救一把，但是finalize（）救命符只能用一次。

5.回收方法区
概述：Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%～95%的空间，而永久代的垃圾收集效率远低于此。
永久代的垃圾收集：主要回收两部分内容：废弃常量和无用的类。
判定为废弃常量：假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
判定为无用的类：判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；加载该类的ClassLoader已经被回收；该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。此外虚拟机对于“无用的类”是可以回收，但并不代表一定会回收。

二、垃圾收集算法
1.标记-清除算法
概述：算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记（这里的标记参考：一、4.对象的自我救赎，两次标记法）完成后统一回收所有被标记的对象。
缺点：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片（如下图所示），空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2.复制算法
概述：将内存区域分为两块，如图1所示，左边一块包含存活对象、可回收、未使用，右边区域为保留区域，使用复制算法，先将存活对象按序复制到保留区域，再将左半部分的所有区域（包括存活对象和可回收区域）全部回收，并将其看成新的保留区域，得到回收后的图2，之后可以使用图2中的可使用内存区域。如果再一次进行垃圾回收，重复上述步骤即可。

优点：解决了内存不连续的问题；实现简单，运行高效；
缺点：只使用了一半的内存，使得内存利用率不高。

内存利用率解决办法：
堆内存分为：
　　新生代（包含：Eden、Survivor、Tenured Gen）
　　　　Eden：伊甸园，垃圾回收器最喜欢光顾的区域，只要是新创建的对象，就放入Eden中；
　　　　Survivor：存活区，垃圾回收器光顾之后，没有被回收的对象放入存活区；
　　　　Tenured Gen：在存活区中还没有被回收，级别比较高，放入Tenured Gen区域。
　　老年代

分析：这里两个Survivor区域之间使用垃圾回收复制算法，这两片区域只各占10%的内存，所以使用复制算法最多也就闲置10%的内存，极大地节约了内存。

3.标记-整理算法
概述：复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如下：

4.分代收集算法
概述：当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

三、垃圾收集器
概述：如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。下图为HotSpot虚拟机的垃圾收集器，展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

注意：对于垃圾收集器，没有最好，只有最适合。

1.Serial收集器（新生代收集器）
概述：Serial收集器是最基本、发展历史最悠久的收集器；Serial收集器是一个单线程的收集器，进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。到现在为止，它依然是虚拟机运行在Client模式（客户端）下的默认新生代收集器。

优点：简单高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最
高的单线程收集效率。适用于Client模式下内存开销较小（一般在几十兆到一两百兆）的桌面应用，停顿时间再几十毫秒的级别。
缺点：执行垃圾回收时，产生停顿。

2.ParNew收集器（新生代收集器）
概述：ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。
设计目标：减少垃圾收集的停顿时间。

优点：ParNew收集器使用多线程收集，提高了收集效率；ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial之外，目前只有ParNew能够配合CMS收集器（老年代收集器）工作。
缺点：由于多线程执行，会引入线程交互的开销，ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，随着可以使用的CPU的数量的增加，其性能可能会慢慢优于Serial。

注：CSM适用于高并发的环境中，比如我一边扔垃圾，清洁工一边捡垃圾。
并行与并发的概念：
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。举例：扔垃圾与打扫卫生不能同时进行，但扔垃圾可以有多个人（多个线程）同时进行，打扫卫生也可以有多个人同时进行。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。举例：扔垃圾与打扫卫生可以同时进行。

3.Parallel Scavenge收集器（新生代收集器）
概述：Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器……看上去和ParNew都一样，区别是Parallel Scavenge收集器对于吞吐量是可控制的。
设计目标：达到一个可控制的吞吐量（Throughput）
吞吐量：CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
两个参数：Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量：
　　参数-XX：MaxGCPauseMillis：控制最大垃圾收集停顿时间，MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值；
　　参数-XX：GCTimeRatio：设置吞吐量大小，GCTimeRatio参数的值应当是一个大于0且小于100的整数，相当于代码运行时间与最大垃圾回收时间的比值。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值为99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
　　分析：吞吐量和停顿时间是相互掣肘的关系，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，比如：系统把停顿时间调小一点，要实现较小的停顿时间，需要将新生代调小一点（比如从500M调整到300M），此时停顿时间是变小了，但是垃圾回收更加频繁了，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒，停顿时间的确在下降，但吞吐量也降下来了。

GC自适应的调节策略（GC Ergonomics）：除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、
Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

4.CMS收集器（老年代收集器）
CMS：Concurrent Mark Sweep，并发标记清除；
概述：一种以获取最短回收停顿时间为目标的收集器，以给用户带来较好的体验。CMS收集器是基于“标记—清除”算法实现
的。

垃圾收集过程：
　　初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，但需要停顿；
　　并发标记（CMS concurrent mark）：进行GC RootsTracing的过程；
　　重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。标记期间需要停顿。
　　并发清除（CMS concurrent sweep）：并发清除会将标记的对象清理掉。
注：初始标记、重新标记这两个步骤仍然需要停顿，由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点：
　　并发收集；
　　低停顿；
缺点：
　　占用大量的CPU资源：只要是并行执行的垃圾收集器，对CPU的资源占用率都是比较高的；
　　无法处理浮动垃圾：比如说边扔垃圾边打扫，只打扫一遍，同时扔的垃圾打扫不了；
　　出现Concurrent Mode Failure：在对标记的对象进行清理时，同时也会创建新的对象，这时需要开辟一段内存空间存放这些新的对象，这个新开辟的空间如果大了，会浪费内存，如果小了，则会出现Concurrent Mode Failure错误；
　　空间碎片：因为是标记清除算法，所以会产生空间碎片，即空间不连续。

5.G1收集器　　
概述：G1是一款面向服务端应用的垃圾收集器。

优势：
并行与并发：1）.并行：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间；2）并发：部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

分代收集：与其他收集器一样，分代概念在G1中依然得以保留；虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
注：在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现。意味着G1运作期间不会产生内存空间碎片，垃圾收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次垃圾收集。

可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

Remembered Set列表（不太懂，回头再看看！）：在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象）G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象）。

G1收集器的运作流程：
初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。且这一阶段不能并发执行。
并发标记（Concurrent Marking）：是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
最终标记（Final Marking）：是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
筛选回收（Live Data Counting and Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，从Sun公司透露出来的信息来看，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

6.理解GC日志
举例：

　　最前面的数字“33.125：”和“100.667：”代表了GC发生的时间，这个数字的含义是从Java
虚拟机启动以来经过的秒数。　
　　GC日志开头的“[GC”和“[Full GC”说明了这次垃圾收集的停顿类型，而不是用来区分新生代GC还是老年代GC的。如果有“Full”，说明这次GC是发生了Stop-The-World的，例如：下面这段新生代收集器ParNew的日志也会出现“[Full GC”（这一般是因为出现了分配担保失败之类的问题，所以才导致STW）。如果是调用System.gc（）方法所触发的收集，那么在这里将显示“[Full GC（System）”。　

　　接下来的“[DefNew”、“[Tenured”、“[Perm”表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例所使用的Serial收集器中的新生代名为“DefaultNew Generation”，所以显示的是“[DefNew”。如果是ParNew收集器，新生代名称就会变为“[ParNew”，意为“Parallel New Generation”。如果采用Parallel Scavenge收集器，那它配套的新生代称为“PSYoungGen”，老年代和永久代同理，名称也是由收集器决定的。
　　后面方括号内部的“3324K-＞152K（3712K）”含义是“GC前该内存区域已使用容量-＞GC后该内存区域已使用容量（该内存区域总容量）”。而在方括号之外的“3324K-＞152K（11904K）”表示“GC前Java堆已使用容量-＞GC后Java堆已使用容量（Java堆总容量）”。
　　再往后，“0.0025925 secs”表示该内存区域GC所占用的时间，单位是秒。有的收集器会给出更具体的时间数据，如“[Times：user=0.01 sys=0.00，real=0.02 secs]”，这里面的user、sys和real与Linux的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态消耗的CPU事件和操作从开始到结束所经过的墙钟时间（Wall Clock Time）。CPU时间与墙钟时间的区别是，墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间，所以读者看到user或sys时间超过real时间是完全正常的。

注：书中包含垃圾收集器参数总结，整理了这些参数供读者实践时参考。