深入理解JAVA虚拟机（二）：垃圾收集器与内存分配

一、垃圾收集

1、垃圾收集器在哪里收集？

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

2、垃圾收集器收集什么？

    1>对于Java堆：垃圾收集器回收那些不可能再被任何途径使用的对象（也就是那些已经“死去”的对象）。

    判断对象是否已经“死去”的方法:

    (1)引用计数算法：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

   评价：引用计数算法的实现简单，判定效率也很高，但是它很难解决对象之间相互循环引用的问题

    (2)可达性分析算法：通过一系列的称为“GC Roots”（可作为GC Roots的节点主要在全局性的引用例如常量或者类静态属性与执行上下文例如栈帧中的本地变量表）的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，可被回收。

   可达性分析算法回收对象的流程图如图所示：
                               

    注意：(1)图中筛选的条件是是否有必要执行finalize()方法，当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

             (2)finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会再被执行。

    以上两种算法判断对象是否存活都与“引用”有关，在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用4种，这4种引用强度依次逐渐减弱。

    (1)强引用：指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

    (2)软引用：用来描述一下还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。

    (3)弱引用：被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

    (4)虚引用：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
   

   2>对于方法区：垃圾收集器主要回收两部分内容：废弃常量和无用类。

  （1）回收废弃常量：如果没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，发生回收时，必要的话，“abc”常量就会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用也与此类似。

  （2）回收无用类：满足以下3个条件才能算“无用类”,第一，该类的所有实例都已经被回收；第二，加载该类的ClassLoader已经被回收；第三，该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

3、垃圾收集器如何收集？

   1>标记-清除算法：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。不足之处：一是效率不高；二是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

   2>复制算法：将内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已经使用过的内存空间一次清理掉。不足之处是，将内存缩小为原来的一半，影响使用空间。现代商业虚拟机将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survior中还存活着的对象一次性地复制到另一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1。因为没法确定每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖老年代进行分配担保。当另一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

   3>标记-整理算法：首先标记出需要回收的对象，然后让所有存活的对象都向一端移动，然后直接清理掉端边界以后的内存。

   4>分代收集算法：根据对象存活周期的不同讲内存划分为几块。一般把Java堆分为新生代和老年代，再根据各个年代的特点采用最适当的手机算法。在新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，就用复制算法。而老年代的对象存活率高，没有额外空间对它进行分配担保，就得使用“标记-清理”或者“标记-整理”算法来进行回收。

二、内存分配

   对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还和虚拟机中与内存相关的参数的设置有关。下面是几条最普遍的内存分配规则：

1、对象优先在Eden分配

   大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。将Eden和Survivor中存活的对象转移到另一块Survivor区，如果Survivor空间不够，则把Eden和Survivor中存活的对象转移到老年代区域。

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

   大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。

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

   虚拟机给每个对象定义一个对象年龄计数器，如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设置为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将会被晋升到老年代中。对于晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

4、动态对象年龄判定

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

5、空间分配担保

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

   以下是空间分配担保的流程图：