Java垃圾回收(2)

一、Java垃圾回收概况

  在Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不稳得执行着出栈和入栈操作。每个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，并且在方法结束或线程结束时，内存自然就跟着回收了，所以这几个区域内不需要过多考虑回收问题。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建那些对象，这部分内存的分配和回收都是动态的，垃圾回收器所关注的是这部分内存。

二、查找需要回收的对象

1. 引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。但是，应用计数法很难解决对象之间的相互引用循环应用的问题（例如：如果两个对象相互引用这对方，除此之外这两个对象再无任何引用，实际上这两个对象不可能再被访问，但是由于他们相互引用这对方，导致他们的引用计数都不为0，于是引用计数器无法通知GC回收器回收他们），所以Java语言并没有采用。
2. 根搜索算法：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所有走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用的。在Java中可作为GC Roots的对象包括下面几种：①虚拟机（栈帧中的本地变量表）中的引用对象；②方法区中的类静态属性引用对象；③方法区中的常量引用对象；④本地方法栈中JNI（即一般说的Native方法）的引用对象；
3. 回收方法区：很多人认为方法区是没有垃圾回收的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾回收，而且在方法区进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾回收一般可以回收70%~95%的空间，而永久代的垃圾回收效率远低于此。
4. 永久代的垃圾回收主要回收两部分内容：废弃常量和无用的类。判断常量值是否在其他地方存在引用，如果其他地方没有对这个常量引用，则垃圾回收的时候，将这个常量清除；无用类只有满足下面三个条件才成立，①该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；②加载该类的ClassLoader已经被回收；③该类对应的java.lang.class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。虚拟机可以对满足上述3个条件的无用类进行回收，这里也仅仅是可以。是否要回收还需要通过-Xnoclassgc参数控制。在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，保证永久代不会溢出。

三、垃圾收集算法

• 标记---清除算法：算法分为标记和清除两个阶段，首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程可参照根搜索算法。但它存在两个缺点：①效率问题，标记和清除过程的效率都不高；②空间问题，标记清楚后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
• 复制算法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上面，然后再把使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。当前Java虚拟机将内存划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性的拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例为8：1，也就是每次新生代中可使用的内存空间为整个新生代容量的90%（80%+10%），只有10%的内存是被浪费的。（IBM的专门研究表明，新生代的对象98%是朝生夕死的）当然98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存进行分配担保。这些对象将直接通过分配担保机制进入老年代。
• 标记---整理算法：复制搜集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。标记---整理算法与标记--清除算法一样，单后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
• 分代收集算法：当前虚拟机的垃圾收集都是采用“分代收集”算法，根据对象的存活周期的不同将内存划分为几块。一般是把Java堆划分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记--清理”或“标记--整理”算法进行回收。

四、垃圾收集器

    收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大的差别，并且一般都会提供参数供用户根据自己的需求组合使用各个年代的收集器。

     上图展示了7种不同分代的收集器，如果两个收集器之间存在连线，则他们可以搭配使用。

• Serial收集器：是一个单线程收集器，并且它不仅仅是一个线程去收集，而且在它通过“复制算法”收集时，必须暂停其他所有的工作线程，直到它收集结束。这种方式带来很恶劣的用户体验，但是到目前为止，它是虚拟机在运行在client模式下的默认新生代收集器，因为它简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
• ParNew收集器：是Serial收集器的多线程版本，也是采用“复制算法”收集，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、停止其他工作线程、对象分配规则、回收策略等和Serial收集器完全一样。它是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关单很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。
• Parallel Scavenge收集器：它也是使用复制算法的收集器，又是并行的多线程收集器。它的主要目的是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU消耗时间的比例，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，虚拟机总共运行了100分钟，其中垃圾收集花费1分钟，那吞吐量就是99%。停顿时间越短就越符合需要与用户交互的程序，良好的响应速度能提升用户的体验；吞吐量则可以最高效率的利用cpu时间，尽量的完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数和直接设置吞吐量大小的-XX:GCTimeRatio参数。大家在使用中不要异想天开的认为如果把MaxGCPauseMillis设置的稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。
• Serial Old收集器：是Serial收集器的老年版本，他同样是一个单线程收集器。使用“标记--整理”算法。这个收集器也主要是在Client模式下的虚拟机使用。
• Parallel Old收集器：是Parallel Scavenge收集器的老年代版本，使用多线程和“标记--整理”算法。在注重吞吐量以及CPU资源敏感场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
• CMS收集器：是一种以获取最短回收停顿为目标的收集器。目前很大一部分Java应用都集中在互联网或B/S系统服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常适合这类应用需求。CMS收集器基于“标记--清除”算法实现的，它的运作过程相对于前面收集器来说更复杂，分为4个步骤：①初始标记②并发标记③重新标记④并发清除。其中初始标记、重新标记这两个步骤仍然需要停止用户进程。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记差生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记稍长一些，但远比并发标记的时间短。CMS是一款优秀的收集器，并发收集、低停顿。
• G1收集器：他与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记--整理”算法实现的收集器，也就是说它不会差生空间碎片；二是它可以非常精确的控制停顿，即能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎是实时Java的垃圾收集器的特征了。G1收集器可以实现不牺牲吞吐量的前提下完成地停顿，这是由于它能极力避免全区域的垃圾收集，之前的收集器的范围是整个新生代和老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域，并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域。

五、内存分配与回收策略

  对象的内存分配，通常指在堆上分配，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则不是百分之百固定的，其细节取决于当前使用的是那一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

1、对象优先在Eden分配

  大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进行退出的时候输出当前内存各区的分配情况。

• 新生代GC(Minor GC)：指发生在新生代的垃圾收集动作，因为Java对象大多数具备朝生熄灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
• 老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC。Major GC的速度一般会比Minor GC慢10倍以上。

2、大对象直接进入老年代

  所谓大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配来说就是一个坏消息，经常出现大对象容易导致内存还有不少空间的时候提前触发垃圾回收以获取足够的连续空间来“安置”他们。

  虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置的对象直接在老年代中分配。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝。

3、长期存活的对象将进入老年代

  虚拟机既然采用分代收集管理内存，那内存回收就必须能认识那些对象应该存在新生代，那些对象应该放入老年代。为了做到这点，虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设置为1.对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当他的年龄增加到一定程度时（默认为15），就会晋升到老年代中。对象晋升老年代的阀值，可以通过参数-XX:MaxTenuringThreshold来设置。

4、动态对象年龄判定

    为了能更好适应不同程度的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

5、空间分配担保

  在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行MinorGC；如果不允许，则也要改为进行一次FULLGC。

  前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况时，就需要老年代进行分配担保，让Survivor无法容纳的对象直接进入老年代。老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋级到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行full GC来让老年代腾出更多空间。

  取平均值进行比较仍然是一种动态概率的手段，也就是说某次MinorGC存活后的对象突增，远远高于平均值的话，依然会导致担保失败。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次FullGC。虽然担保失败时绕的圈子是最大的，但大部分情况下还是会将HandlePromotionFailure开关打开，避免FullGC过于频繁。