Java虚拟机学习——垃圾收集器与内存分配策略

一：Java中是如何管理对象的

垃圾收集（Garbage Collection，GC），要设计一个GC，需要考虑解决下面三件事情：
（1）哪些内存需要回收？
（2）什么时候回收？
（3）如何回收？

1.1 哪些内存需要回收？

根据《Java虚拟机学习——Java内存区域与内存溢出异常》中介绍的java内存模型，其中，程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，故这几个区域就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了。
对于java堆和方法区则不一样，java堆是存放实例对象的地方，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收是动态的，因此，垃圾收集器所关注的就是这一部分。
对于方法区（或者说HotSpot虚拟机中的永久代），垃圾回收主要是回收这两部分内容：废弃常量和无用的类。对于废弃常量，主要是判断当前系统中有没有对象引用这个常量；对于无用类则比较严格，需要满足下面三个条件：
（1）该类的所有实例都已经被回收，即堆中不存在该类任何势力；
（2）加载该类的ClassLoader已经被回收；
（3）对类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法；
满足了上面三个条件也仅仅是“可以”进行回收了，还要根据HotSpot的一些配置参数综合考虑。

1.2 什么时候回收？

垃圾收集器在对堆进行回收前，第一件事就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”，对于这些已经“死去”的对象我们需要进行回收。判断对象是否存活的算法：

1.2.1 引用计数算法

算法过程如下：【给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的】。
引用计数算法实现简单，判定效率也很高，大部分情况下是一个不错的算法。但有一个比较重要的缺点：很难解决对象之间相互循环引用的问题。比如：j假设变量objA、objB为某个类的对象实例，objA中持有一个指向objB的成员，此时objB的引用计数为1；在objB中持有一个指向objA的成员，此时objA的引用计数值也为1；此时，即使把objA、objB都置为null，此时两个对象都不能被回收，因为这两个对象虽然为null了，但是它们的引用计数值都还为1。

public class ReferenceCountingGC {

    public Object instance = null;
    private static final int_1MB=1024*1024；
    private byte[]bigSize=new byte[2*_1MB]；//这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();

        objA.instance = objB;
        objB.instance = objA;

        objA = null;
        objB = null;
        //假设在这行发生GC,objA和objB是否能被回收？
        System.gc();
    }
}

运行结果：

[F u l l G C（S y s t e m）[T e n u r e d：0 K-＞2 1 0 K（1 0 2 4 0 K），0.0 1 4 9 1 4 2 s e c s]4603K-＞210K（19456K），[Perm：2999K-＞2999K（21248K）]，0.0150007 secs][Times：user=0.01 sys=0.00，real=0.02 secs]
Heap
def new generation total 9216K,used 82K[0x00000000055e0000，0x0000000005fe0000，0x0000000005fe0000）
Eden space 8192K，1%used[0x00000000055e00000x00000000055f4850，0x0000000005de0000）
from space 1024K，0%used[0x0000000005de0000，0x0000000005de0000，0x0000000005ee0000）
to space 1024K，0%used[0x0000000005ee0000，0x0000000005ee0000，0x0000000005fe0000）
tenured generation total 10240K,used 210K[0x0000000005fe0000，0x00000000069e0000，0x00000000069e0000）
the space 10240K，2%used[0x0000000005fe0000，0x0000000006014a18，0x0000000006014c00，0x00000000069e0000）
compacting perm gen total 21248K,used 3016K[0x00000000069e0000，0x0000000007ea0000，0x000000000bde0000）
the space 21248K，14%used[0x00000000069e0000，0x0000000006cd2398，0x0000000006cd2400，0x0000000007ea0000）
No shared spaces configured.

从运行结果中可以清楚看到，GC日志中包含“4603K-＞210K”，意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的

1.2.2 可达性分析算法

目前主流的虚拟机，如java默认虚拟机HotSpot就是用的这种方式。算法基本思路为：【通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时（或者说从GC Roots到这个对象不可达），则证明此对象是不可用的】。如下图所示：

对象Object5、Object6、Object7相互虽然有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。在Java语言中，可作为GC Roots的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象；
- 方法区中类静态static属性引用的对象；
- 方法区中常量final引用的对象；
- 本地方法栈中JNI（即一般说的Native方法）引用的对象；

1.3 再谈引用

无论是引用计数法还是可达性分析算法，都用到了引用的概念，从JDK1.2开始，Java对引用的概念进行了扩充，讲引用分为强引用（Strong Reference）、软引用（Softe Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，增强引用的适用性。

• 强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只有强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用也是用来描述一些有用但并非必要的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用也是用来描述非必要对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。但垃圾收集工作时，无论当前内存是否足够，都会回收掉只内弱引用关联的对象。
• 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。因为finalize函数（后续会讲）被调用的不确定性，所以无法预知对象是否被回收，所在这里虚引用就起作用了。

1.4 生存还是死亡

需要注意的是，即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过（也就是说对象的finalize()方法只能被调用一次），虚拟机将这两种情况都视为“没有必要执行”。
如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。从以下代码中我们可以看到一个对象的finalize()被
执行，但是它仍然可以存活。

        /**
        *此代码演示了两点：
        *1.对象可以在被GC时自我拯救。
        *2.这种自救的机会只有一次，因为一个对象的finalize（）方法最多只会被系统自动调用一次
        */
        public class FinalizeEscapeGC{

            public static FinalizeEscapeGC 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！")；
                FinalizeEscapeGC.SAVE_HOOK=this；
            }

            public static void main(String[]args)throws Throwable{

                SAVE_HOOK=new FinalizeEscapeGC()；

                //对象第一次成功拯救自己
                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：(")；
                }
            }
        }

运行结果：

finalize mehtod executed！
yes,i am still alive：)
no,i am dead：(

因此对于不可达对象判定真正死亡的过程小结如下：
（1）GC进行第一次标记并进行一次筛选（筛选那些覆盖了finalize方法并且finalize方法是第一次调用的对象）；
（2）另一个低优先级的线程去调用那些被筛选出来的对象的finalize方法；
（3）GC进行第二次标记，如果在前一步中那些筛选出来的对象没有在finalize拯救自己，此时，那些未被筛选到的和这些这些筛选到的但是没有拯救自己的对象都将会回收。

1.5 方法区收回

很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%～95%的空间，而永久代的垃圾收集效率远低于此。

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose：class以及-XX：+TraceClassLoading、-XX：+TraceClassUnLoading查看类加载和卸载信息，其中-verbose：class和-XX：+TraceClassLoading可以在Product版的虚拟机中使用，-XX：+TraceClassUnLoading参数需要FastDebug版的虚拟机支持。可能永久代的效果不理想，在JDK8中，已经没有永久代的概念了，原先这块区域被放置到本地内存了。

二：垃圾收集算法

2.1 标记-清除算法

最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，标记过程就是上面可达性分析算法中所讲的二次标记过程。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。
标记-清除算法的执行过程如下图所示：

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

2.2 复制算法

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。复制算法的执行过程如图

复制算法的优点：
（1）每次都是对整个半区进行内存回收，实现简单、运行也高效；
（2）在那块使用内存上进行内存分配时，不用考虑内存碎片的问题，只要移动堆顶指针，按顺序分配内存即可；
缺点：使用内存比原来缩小了一半。

按照新生代的特点，新生代中的对象98%是“朝生夕死”的，因此，可以改进上面的复制算法，目前商业虚拟机正是用这种改进的收集算法来回收新生代。
改进的收集算法：
根据新生代的特点，我们并不需要按照1:1的比例来划分内存空间，而是将内存划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活的对象一次性地复制到另外一块Survivor空间。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是
8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

这种改进的收集算法也有一个问题，就是在回收时，那块空的Survivor空间能否放得下Eden和使用的Survivor空间中还存活的对象，如果Survivor空间不够存放上一次新生代收集下来的存活对象，此时就需要向老年代“借”内存，那些剩余未放下的对象就通过分配担保机制进入老年代。

2.4 标记-整理算法

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

2.5 分代收集算法

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

三：垃圾收集器

如果说上面介绍的收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，按照上面的介绍，目前垃圾收集器基本都采用分代收集，因此一个垃圾收集器中一般都存在多种垃圾回收算法。不同的虚拟机提供的垃圾收集器也有很大差异，如下是HotSpot虚拟机基于JDK1.7版本所包含的所有垃圾收集器：

HotSpot中共有7中不同的垃圾收集器，如果两个收集器之间存在连线，说明它们之间可以搭配使用，其中，Serial、ParNew、Parallel Scavenge属于新生代收集器，CMS、Serial Old、Parallel Old属于老年代收集器，G1是最新的一种收集器，在新生代和老年代中都可使用。

3.1 Serial（串行）收集器

最基本、发展历史最悠久的一种收集器。看名字就知道，这个收集器是一个单线程的收集器，只使用一个CPU或一条收集线程去完成垃圾收集工作，最重要的是，在它进行垃圾收集的时候，必须暂停其他所有的工作线程，知道它收集结束。虽然有这个缺点，但是依然是虚拟机运行在Client模式下的默认新生代收集器。优点是：简单而高效，没有线程交互的开销。运行过程如图：

新生代采用的是“复制算法”，老年代采用的是“标记-整理”算法。

3.2 ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其他行为和Serial收集器一样。ParNew是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关的重要原因，除了Serial收集器外，目前只有ParNew能与老年代的CMS收集器配合使用。ParNew是一种并行的收集器。在垃圾回收中，并行是指：多条垃圾收集线程并行工作，用户线程处于等待状态；并发是指：用户线程和垃圾收集线程同时执行（不一定并行，可能交替执行）。

3.3 Parallel Scavenge收集器

Parallel Scavenge收集器使用的是复制算法，也是一个并行的多线程收集器。和ParNew相似，但是Parallel Scavenge的关注点不同，CMS收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量，吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。

上面三种都是新生代收集器，下面介绍老年代收集器。

3.4 Serial Old收集器

Serial Old收集器是新生代Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法，Serial Old的主要意义也是在于给Client模式下的虚拟机使用。

3.5 Parallel Old收集器

Parallel Old是新生代收集器Prarllel Scavenge的老年代版本，使用多线程和“标记-整理”算法。运行流程如下：

3.6 CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。对于互联网站或者B/S系统的这种注重响应速度的服务端来说，CMS是很好的选择。从名字Mark Sweep可以看出，CMS是基于“标记-清除”算法实现的，分为四个步骤：
（1）初始标记（CMS initial mark）：仅仅标记一GC Roots能直接关联到的对象，这个步骤需要“stop the world”；
（2）并发标记（CMS concurrent mark）：就是GC Roots进行可达性分析阶段，可并发执行；
（3）重新标记（CMS remark）：修正并发标记期间发生变动的那一部分对象，这个步骤需要“stop the world”；
（4）并发清除（CMS concurrent sweep）：执行清除阶段。
执行过程如下：

可以看到，初始标记和重新标记阶段都是并行的，需要暂停用户线程（过程比较短）；在并发标记和并发清除阶段是并发的，可以和用户线程一起工作。

CMS的优点：并发收集、低停顿。
CMS的缺点：
（1）对CPU资源非常敏感，面向并发设计程序的通病，虽然不至于导致用户线程停顿，但是会降低吞吐率；
（2）无法清理“浮动垃圾”，由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断出现，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次的GC；
（3）会产生大量空间碎片，因为CMS是基于“标记-清除”算法，这种算法的最大缺点就是会产生大量空间碎片，给分配大对象带来麻烦，不得不提前触发Full GC。为了解决这个问题，CMS提供了一个“-XX:+UseCMSCompaceAtFullCollection”的开关参数（默认开启），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程。

3.7 G1收集器

G1收集器是最新的一款收集器，JDK1.7才发布，是一种面向服务端应用的垃圾收集器，有如下特点：
（1）并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间；
（2）分代收集：分代概念在G1中依然得以保留。虽然G1可以不需其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果；
（3）空间整合：与CMS的“标记-清理”算法不同，G1从整体看来是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上看是基于“复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存；
（4）可预测的停顿时间；

使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

G1的收集过程分为以下几个步骤：
（1）初始标记（Initial Marking）
（2）并发标记（Concurrent Marking）
（3）最终标记（Final Marking）
（4）筛选回收（Live Data Counting and Evacuation）
前几个步骤和CMS有很多相似之处。运行示意图如下：

四：总结

JVM内存模型中分两大块，一块是New Generation, 另一块是Old Generation. 在New Generation中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to）, 它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中，主要存放应用程序中生命周期长的内存对象，还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。
1) 在New Generation块中，垃圾回收一般用复制算法，速度快。每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空

2) 在Old Generation块中，垃圾回收一般用标记整理的算法，速度慢些，但减少内存要求.

垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收Old段中的垃圾；1级或以上为部分垃圾回收，只会回收New中的垃圾，内存溢出通常发生于Old段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

Out Of Memory 只发生在jvm对old和perm generation 回收后还不能获足够内存的情况.
当生成一个新对象时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
D. Survivor区被用来作为Eden及Old的中间交换区域，当Old区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当Old区空间不够时，JVM会在Old区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及Old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

造成full gc的原因
new了很多对象,没有即时在主动释放掉->Eden内存不够用->不断把对象往old迁移->old满了->full gc

总结：上面的内容就介绍了Java虚拟机如何管理对象的，我们也看到了上面主要就是收集算法和堆空间的从新划分，这样做的目的都是在于垃圾回收的高效执行，但是总归看来，如果对象交给系统来管理，在系统运行的过程效率肯定会有影响的，但是这有一点比较好，就是不需要手动管理，给程序猿带来方便。