Java垃圾回收

回收堆

  Java堆中存放着几乎所有的对象实例，垃圾回收器在堆进行垃圾回收前，首先要判断对象存活与否。判断对象是否存活有如下算法：

引用计数法

  引用计数法算法：给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已“死”。
  引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个比较好的算法。但是，在主流的JVM中没有选用引用计数法来管理内存，最主要的原因是引用计数法无法解决对象的循环引用问题。

可达性分析算法

  Java采用“可达性分析”来判断对象是否存活。此算法的核心思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何的引用链相连时时，证明此对象不可用。以下图为例：

对象Object5 —Object7之间虽然彼此还有联系，但是它们到 GC Roots 是不可达的，因此它们会被判定为可回收对象。
  在Java语言中，可作为GC Roots的对象包含以下几种：

1. 虚拟机栈(栈帧中的本地变量表)中引用的对象
2. 方法区中静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中(Native方法)引用的对象

  在JDK1.2以前，Java中引用的定义很传统：如果引用类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。在JDK1.2之后，将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)四种，这四种引用的强度依次递减。

• 强引用：在程序代码之中普遍存在的，类似于"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象实例。显式地设置对象为 null或者超出对象的生命周期，此时就可以回收这个对象
• 软引用：如果一个对象只具有软引用，在内存足够时，垃圾回收器不会回收它；如果内存不足，就会回收这个对象的内存。使用场景：
    【1】图片缓存。图片缓存框架中，“内存缓存”中的图片是以这种引用保存，使得 JVM 在发生 OOM 之前，可以回收这部分缓存
    【2】网页缓存
• 弱引用：当垃圾回收器扫描到只具有弱引用的对象，不管当前内存空间是否足够，都会回收内存。使用场景：在静态内部类中，经常会使用虚引用。例如：一个类发送网络请求，承担 callback 的静态内部类，则常以虚引用的方式来保存外部类的引用，当外部类需要被 JVM 回收时，不会因为网络请求没有及时回应，引起内存泄漏
• 虚引用：虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

  即使在可达性分析算法中不可达的对象，也并非"非死不可"的，这些对象暂时处在"缓刑"阶段。要宣告一个对象的真正死亡，至少要经历两次标记过程：如果对象在进行可达性分析之后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者finalize()方法已经被JVM调用过，虚拟机会将这两种情况都视为"没有必要执行"，此时的对象才是真正"死"的对象。
  如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个叫做F-Queue的队列之中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它（执行指虚拟机会触发finalize()方法）。finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象在finalize()中成功拯救自己(只需要重新与引用链上的任何一个对象建立起关联关系即可)，那在第二次标记时它将会被移除出"即将回收"的集合；如果对象这时候还是没有逃脱，那基本上它就是真的被回收了。例子：对象自我拯救

public class Test {
	public static Test test;
	public void isAlive() {
		System.out.println("I am alive :)");
	}
	@Override
	protected void finalize() throws Throwable {
		super.finalize();
		System.out.println("finalize method executed!");
		test = this;
	}
	public static void main(String[] args)throws Exception {
		test = new Test();
		test = null;
		System.gc();
		Thread.sleep(500);
		if (test != null) {
			test.isAlive();
		}else {
			System.out.println("no,I am dead :(");
		}
		// 下面代码与上面完全一致，但是此次自救失败
		test = null;
		System.gc();
		Thread.sleep(500);
		if (test != null) {
			test.isAlive();
		}else {
			System.out.println("no,I am dead :(");
		}
	}
}

从上面代码示例我们发现，finalize方法确实被JVM触发，并且对象在被收集前成功逃脱。但是从结果上看，两个完全一样的代码片段，结果是一次逃脱成功，一次失败。这是因为，任何一个对象的finalize()方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又面临一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败。

回收方法区

  方法区(永久代)的垃圾回收主要收集两部分内容：废弃常量和无用类。回收废弃常量和回收Java堆中的对象十分类似。以常量池中字面量(直接量)的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个String对象引用常量池中的"abc"常量，也没有其他地方引用这个字面量，如果此时发生GC并且有必要的话，这个"abc"常量会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
判定一个类是否是"无用类"则相对复杂很多。类需要同时满足下面三个条件才会被算是"无用的类"：

1. 该类的所有实例都已经被回收(即在Java堆中不存在任何该类的实例)
2. 加载该类的ClassLoader已被回收
3. 该类对应的Class对象没有任何其他地方被引用，无法在任何地方通过反射访问该类的方法

JVM可以对同时满足上述3个条件的无用类进行回收，也仅仅是“可以”而不是必然。在大量使用反射、动态代理等场景都需要JVM具备类卸载的功能来防止永久代的溢出。

垃圾回收算法

标记-清除算法

  “标记-清除”算法是最基础的收集算法。算法分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。“标记-清除”算法的不足主要有两个：

1. 效率问题：标记和清除这两个过程的效率都不高
2. 空间问题：标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集。
   

复制算法(新生代回收算法)

  “复制”算法是为了解决“标记-清除”的效率问题。它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另一块上面，然后再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配时也就不需要考虑内存碎片等的复杂情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运行高效。算法的执行流程如下图：

现在的商用虚拟机(包括HotSpot)都是采用这种收集算法来回收新生代
  新生代中98%的对象都是"朝生夕死"的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存(新生代内存)分为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
  当Survivor空间不够用时，需要依赖其他内存(老年代)进行分配担保。HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用内存空间为整个新生代容量的90%,而剩下的10%用来存放回收后存活的对象。HotSpot实现的复制算法流程如下：
3. 当Eden区满的时候，会触发第一次Minor gc，把还活着的对象拷贝到Survivor From区；当Eden区再次出发Minor gc的时候，会扫描Eden区和From区，对两个区域进行垃圾回收，经过这次回收后还存活的对象，则直接复制到To区域，并将Eden区和From区清空
4. 当后续Eden区又发生Minor gc的时候，会对Eden区和To区进行垃圾回收，存活的对象复制到From区，并将Eden区和To区清空
5. 部分对象会在From区域和To区域中复制来复制去，如此交换15次(由JVM参数MaxTenuringThreshold决定，这个参数默认是15)，最终如果还存活，就存入老年代

为什么要分Survivor0、Survivor1区
  新生代使用复制回收算法，如果只有一个Survivor区会发生什么情况：当Eden区填满后，Minor GC进行垃圾回收，幸存的对象会移动到Survivor区，这样循环往复。此时，Survivor区被装满了，也会进行Minor GC，将一些对象kill掉，幸存的对象只能保存在原来的位置，这样就会出现大量的内存碎片 。
  划分为两块Survivor区，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到Survivor0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和Survivor0中的存活对象又会被复制送入Survivor1（ 这个过程可以保证了Survivor1中来自Survivor0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生 ）。Survivor0和Eden被清空，然后下一轮Survivor0与Survivor1交换角色，如此循环往复。

标记整理算法(老年代回收算法)

  复制收集算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用复制算法。针对老年代的特点，提出了一种称之为“标记-整理算法”。标记过程仍与“标记-清除”过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象向一端移动，然后直接清理掉端边界以外的内存。流程图如下：

java中什么样的对象能够进入老年代

1. 大对象：所谓的大对象是指需要大量连续内存空间的java对象，最典型的大对象就是那种很长的字符串以及数组
2. 长期存活的对象：虚拟机给每个对象定义了一个对象年龄(Age)计数器，如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每熬过一次Minor GC，年龄就增加1，当年龄增加到一定程度(默认是15岁)， 就将会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置
3. 动态对象年龄判定：为了能更好地适应不同程度的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄

分代收集算法

  当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算法。

Minor GC和Full GC触发条件

Minor GC触发条件：当Eden区满时，触发Minor GC。

Full GC触发条件：

1. System.gc()方法的调用
     此方法建议JVM进行Full GC，虽然只是建议而非一定，但很多情况下它会触发 Full GC，建议不使用此方法。
2. 老年代代空间不足
     老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象。应尽量让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间以及不要创建过大的对象及数组。
3. 永久代空间不足
     JVM规范中运行时数据区域中的方法区，又称为永久代，永久代中存放的为一些class的信息、常量、静态变量等数据。为避免永久代占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。
4. CMS GC时出现promotion failed和concurrent mode failure
     对于采用CMS进行老年代GC的程序而言，当这两种状况出现时可能会触发Full GC。promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrent mode failure是在执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。措施为增大survivor space、老年代空间或调低触发并发GC的比率。
5. 统计得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间
     在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间，那么就直接触发Full GC。可通过在启动时通过- java -Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止调用System.gc。
6. 堆中分配很大的对象
     大对象是指需要大量连续内存空间的java对象，例如大数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在Full GC之后进行内存整理。

Minor GC和Full GC不同点？

  从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，因为Java对象大多都具备朝生夕灭的特性，因此Minor GC(采用复制算法)非常频繁，一般回收速度也比较快。对老年代GC称为Major GC。而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生代即方法区的回收（JDK8中无永久代了），出现Full GC的时候经常伴随至少一次的Minor GC(并非绝对，在Parallel Scavenge收集器中就有直接进行Full GC的策略选择过程)。Major GC的速度一般会比Minor GC慢10倍以上。

什么时候GC

1. 系统空闲的时候
2. 系统自身决定，不可预测的时间/调用System.gc()的时候
3. 新生代、老年代结构，能提出minor gc/full gc
4. minor gc/full gc的触发条件、OOM的触发条件，降低GC的调优的策略
     当eden满了minor gc，升到老年代的对象大于老年代剩余空间full gc，或者小于时被HandlePromotionFailure参数强制full gc；gc与非gc时间耗时超过了GCTimeRatio的限制引发OOM，调优诸如通过NewRatio控制新生代老年代比例，通过 MaxTenuringThreshold控制进入老年前生存次数等

总结：程序员不能具体控制时间，系统在不可预测的时间调用System.gc()函数的时候；当然可以通过调优，用NewRatio控制newObject和oldObject的比例，用MaxTenuringThreshold 控制进入oldObject的次数，使得oldObject 存储空间延迟达到full gc,从而使得计时器引发gc时间延迟OOM的时间延迟，以延长对象生存期

GC日志打印

  GC日志记录了每一次的GC的执行时间和执行结果，通过分析GC日志可以优化堆设置和GC设置或者改进应用程序的对象分配模式。对应的参数列表：

-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径

会在根目录生成 gc.log 文件，里面记录了gc的详细信息。