2014JVM面试题及其答案

2014JVM面试题及其答案

JVM内存模型？

JVM内存区域可以被分为 堆、虚拟机栈、本地方法栈、方法区、程序计数器

写一段代码实现堆溢出？栈溢出？常量池溢出？方法区溢出？

堆溢出：

List<OOheap> l = new ArrayList<OOheap>();
while (true) {
    l.add(new OOheap());
}

栈溢出

/**
 * VM Args : -Xss100k
 */
public class OverStack {

	public void leakStack() {
		leakStack();
	}

	public static void main(String[] args) {
		OverStack o = new OverStack();
		try {
			o.leakStack();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

常量池

/**
 * VM Args: -XX:PremSize=100k -XX:MaxPremSize=100k
 */
import java.util.ArrayList;
import java.util.List;

public class OverPremGen {

	public static void main(String[] args) {

		List l = new ArrayList();
		int i = 0;
		while(true){
			
			l.add(String.valueOf(i++).intern());
		}
	}
}

方法区

import java.lang.reflect.Method;  
  
import net.sf.cglib.proxy.Enhancer;  
import net.sf.cglib.proxy.MethodInterceptor;  
import net.sf.cglib.proxy.MethodProxy;  
/** 
 * VM args -XX:PermSize=10M -XX:MaxPermSize=10M 
 * 
 */  
public class JavaMethodAreaOOM {  
    public static void main(String[] args) {  
        while (true) {  
            Enhancer enhancer = new Enhancer();  
            enhancer.setSuperclass(OOM.class);  
            enhancer.setUseCache(false);  
            enhancer.setCallback(new MethodInterceptor() {  
  
                @Override  
                public Object intercept(Object obj, Method arg1, Object[] args, MethodProxy proxy) throws Throwable {  
                    return proxy.invokeSuper(obj, args);  
                }  
            });  
            OOM oom = (OOM) enhancer.create();  
            oom.sayHello("xxx");  
        }  
    }  
  
    static class OOM {  
        public String sayHello(String str) {  
            return "HI " + str;  
        }  
    }  

类的生命周期？

1. 加载：查找并加载类的二进制数据
2. 连接
   • 验证：确保被加载的类的正确性
   • 准备：为类的静态变量分配内存，并将其初始化为默认值
   • 解析：把类中的符号引用转换为直接引用
3. 初始化：为类的静态变量赋予正确的初始值
4. 使用
5. 卸载

哪四种情况会触发类的初始化（也就是主动引用）？

1. 遇到new、getstatic、putstatic、invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。
   • new 一个类的时候会发生初始化
   • 调用类中的静态成员，除了final字段，看下面这个例子，final被调用但是没有初始化类
   • 调用某个类中的静态方法，那个类一定先被初始化了
2. 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。(如Class.forName("my.xyz.Test"))
3. 当初始化一个类的时候，如果发现其父类还没进行过初始化，则需要先触发其父类的初始化。
4. 当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类。

被动引用会触发初始化吗？请举例

1. 通过子类引用父类的静态字段，不会导致子类初始化

   package test.class_life_cycle.initialize;  
     
   class Dfather{  
       static int count = 1;  
       static{  
           System.out.println("Initialize class Dfather");  
       }  
   }  
     
   class Dson extends Dfather{  
       static{  
           System.out.println("Initialize class Dson");  
       }  
   }  
     
   public class Test4 {  
       public static void main(String[] args) {  
           int x = Dson.count;  
       }  
   }  

2. 通过数组定义类引用类，不会触发此类的初始化

   package test.class_life_cycle.initialize;  
   class E{  
       static{  
           System.out.println("Initialize class E");  
       }  
   }  
     
   public class Test5 {  
       public static void main(String[] args) {  
           E[] e = new E[10];  
       }  
   }  

3. 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化

   package test.class_life_cycle.initialize;  
     
   class F{  
       static final int count = 1;  
       static{  
           System.out.println("Initialize class F");  
       }  
   }  
     
   public class Test6 {  
       public static void main(String[] args) {  
           int x = F.count;  
       }  
   }  

Class对象在堆中的作用？

Class对象是存放在堆区的，不是方法区，这点很多人容易犯错。类的元数据（元数据并不是类的Class对象。Class对象是加载的最终产品，类的方法代码，变量名，方法名，访问权限，返回值等等都是在方法区的）才是存在方法区的。

类加载器（ClassLoader）的类加载模式？为什么要选择这种模式？双亲委托加载模式的代码实现？

Java中ClassLoader的加载采用了双亲委托机制

要确定某一个类，需要类的全限定名以及加载此类的ClassLoader来共同确定。也就是说即使两个类的全限定名是相同的，但是因为不同的ClassLoader加载了此类，那么在JVM中它是不同的类。采用了委托模型以后加大了不同的 ClassLoader的交互能力，比如上面说的，我们JDK本生提供的类库，比如hashmap,linkedlist等等，这些类由bootstrp 类加载器加载了以后，无论你程序中有多少个类加载器，那么这些类其实都是可以共享的，这样就避免了不同的类加载器加载了同样名字的不同类以后造成混乱。

参见代码java.lang.ClassLoader#loadClass(java.lang.String, boolean)

protected Class<?> loadClass(String name, boolean resolve)
     throws ClassNotFoundException
 {
     synchronized (getClassLoadingLock(name)) {
         // First, check if the class has already been loaded
         Class<?> c = findLoadedClass(name);
         if (c == null) {
             long t0 = System.nanoTime();
             try {
                 if (parent != null) {
                     c = parent.loadClass(name, false);
                 } else {
                     c = findBootstrapClassOrNull(name);
                 }
             } catch (ClassNotFoundException e) {
                 // ClassNotFoundException thrown if class not found
                 // from the non-null parent class loader
             }

             if (c == null) {
                 // If still not found, then invoke findClass in order
                 // to find the class.
                 long t1 = System.nanoTime();
                 c = findClass(name);

                 // this is the defining class loader; record the stats
                 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                 sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                 sun.misc.PerfCounter.getFindClasses().increment();
             }
         }
         if (resolve) {
             resolveClass(c);
         }
         return c;
     }
 }

如何实现自定义的ClassLoader?

extends ClassLoader
自定义实现

• loadClass 实现类的加载（从文件加载，是否实施双亲委托）
• findClass 比如从文件加载类java.lang.ClassLoader#defineClass(java.lang.String, byte[], int, int)生成类

JDK动态代理的原理？

在java的动态代理机制中，有两个重要的类或接口，一个是 InvocationHandler(Interface)、另一个则是 Proxy(Class)，这一个类和接口是实现我们动态代理所必须用到的。

InvocationHandler

每一个动态代理类都必须要实现InvocationHandler这个接口，并且每个代理类的实例都关联了一个handler，当我们通过代理对象调用一个方法的时候，这个方法的调用就会被转发为由InvocationHandler这个接口的 invoke 方法来进行调用。我们来看看InvocationHandler这个接口的唯一一个方法 invoke 方法：

Object invoke(Object proxy, Method method, Object[] args) throws Throwable

我们看到这个方法一共接受三个参数，那么这三个参数分别代表如下：

• proxy 指代JDK动态生成的最终代理对象
• method 指代的是我们所要调用真实对象的某个方法的Method对象
• args 指代的是调用真实对象某个方法时接受的参数

Proxy

Proxy这个类的作用就是用来动态创建一个代理对象的类，它提供了许多的方法，但是我们用的最多的就是 newProxyInstance 这个方法：

public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,  InvocationHandler h)  throws IllegalArgumentException

这个方法的作用就是得到一个动态的代理对象，其接收三个参数，我们来看看这三个参数所代表的含义：

• loader 一个ClassLoader对象，定义了由哪个ClassLoader来对生成的代理对象进行加载
• interfaces 一个Interface对象的数组，表示的是我将要给我需要代理的对象提供一组什么接口，如果我提供了一组接口给它，那么这个代理对象就宣称实现了该接口(多态)，这样我就能调用这组接口中的方法了
• 一个InvocationHandler对象，表示的是当我这个动态代理对象在调用方法的时候，会关联到哪一个InvocationHandler对象上

其实我们所说的DynamicProxy（动态代理类）是这样一种class：它是在运行时生成的class，在生成它时你必须提供一组interface给它，然后该class就宣称它实现了这些 interface。如此一来，我们可以把该class的实例当作这些interface中的任何一个来用（可以强转为相应的接口类型）。当然，这个DynamicProxy其实就是一个Proxy，它不会做实质性的工作，在生成它的实例时你必须提供一个handler，由它接管实际的工作。

虚拟机栈栈帧包含哪些部分以及各部分功能？

一个栈帧包括局部变量表，操作数栈，动态链接，方法返回地址和一些额外的附加信息组成.

• 局部变量表：存放方法参数和方法内局部变量
• 操作数栈：方法执行的过程中各种字节码指令往此写入和提取内容
• 动态连接：栈帧中的符号引用在运行期间转化为直接引用
• 方法返回地址：退出方法
• 附加信息：jvm规范中没有描述的信息

参考：https://www.cnblogs.com/jing99/p/6076102.html

字节码执行引擎方法调用中静态分派和动态分派区别？重写与重载？

静态分派

在编译期所有依赖静态类型来定位方法执行版本的分派动作称为静态分派，其典型应用是方法重载（根据参数的静态类型来定位目标方法）。
静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机执行的。静态类型在编译期是可知的；

动态分派

运行期根据实际类型确定方法执行版本的分派动作称为动态分派，其典型应用是方法重写。

public class DynamicDispatch {  
    static abstract class Human{  
        protected abstract void sayHello();  
    }  
    static class Man extends Human{   
        @Override  
        protected void sayHello() {   
            System.out.println("man say hello!");  
        }  
    }  
    static class Woman extends Human{   
        @Override  
        protected void sayHello() {   
            System.out.println("woman say hello!");  
        }  
    }   
    public static void main(String[] args) {  
          
        Human man=new Man();  
        Human woman=new Woman();  
        man.sayHello();  
        woman.sayHello();  
        man=new Woman();  
        man.sayHello();   
    }  
}  

输出：

man say hello!
woman say hello!
woman say hello!

显然，这里不可能再根据静态类型来决定，因为静态类型同样是Human的两个变量man和woman在调用sayHello()方法时执行了不同的行为，并且变量man在两次调用中执行了不同的方法。导致这个现象的原因很明显，是这两个变量的实际类型不同，Java虚拟机是如何根据实际类型来分派方法执行版本的呢？
我们从invokevirtual指令的多态查找过程开始说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤：

1. 找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
2. 如果在类型C中找到与常量中的描述符和简单名称相符合的方法，然后进行访问权限验证，如果验证通过则返回这个方法的直接引用，查找过程结束；如果验证不通过，则抛出java.lang.IllegalAccessError异常。
3. 否则未找到，就按照继承关系从下往上依次对类型C的各个父类进行第2步的搜索和验证过程。
4. 如果始终没有找到合适的方法，则跑出java.lang.AbstractMethodError异常。

由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令把常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。

参考：http://blog.csdn.net/sunxianghuang/article/details/52280002

重载(Overloading)

方法重载是让类以统一的方式处理不同类型数据的一种手段。多个同名函数同时存在，具有不同的参数个数/类型。重载Overloading是一个类中多态性的一种表现。 Java的方法重载，就是在类中可以创建多个方法，它们具有相同的名字，但具有不同的参数和不同的定义。调用方法时通过传递给它们的不同参数个数和参数类型来决定具体使用哪个方法, 这就是多态性。重载的时候，方法名要一样，但是参数类型和个数不一样，返回值类型可以相同也可以不相同。无法以返回型别作为重载函数的区分标准。

重载的规则：

1）、必须具有不同的参数列表；

2）、可以有不同的返回类型，只要参数列表不同就可以了；

3）、可以有不同的访问修饰符；

4）、可以抛出不同的异常；

重写(overriding）

在Java程序中，类的继承关系可以产生一个子类，子类继承父类，它具备了父类所有的特征，继承了父类所有的方法和变量。
子类可以定义新的特征，当子类需要修改父类的一些方法进行扩展，增大功能，程序设计者常常把这样的一种操作方法称为重写，也叫称为覆写或覆盖。
重写体现了Java优越性，重写是建立在继承关系上，它使语言结构更加丰富。在Java中的继承中，子类既可以隐藏和访问父类的方法，也可以覆盖继承父类的方法。

重写方法的规则：

1）、参数列表必须完全与被重写的方法相同，否则不能称其为重写而是重载。

2）、返回的类型必须一直与被重写的方法的返回类型相同，否则不能称其为重写而是重载。

3）、访问修饰符的限制一定要大于被重写方法的访问修饰符（public>protected>default>private）

4）、重写方法一定不能抛出新的检查异常或者比被重写方法申明更加宽泛的检查型异常。例如：

父类的一个方法申明了一个检查异常IOException，在重写这个方法是就不能抛出Exception,只能抛出IOException的子类异常，可以抛出非检查异常。

动态代理的原理？好处？JDK动态代理与Cglib动态代理的区别？

AOP，是通过动态代理实现的。

一、简单来说：

JDK动态代理只能对实现了接口的类生成代理，而不能针对类

CGLIB是针对类实现代理，主要是对指定的类生成一个子类，覆盖其中的方法（继承）

二、Spring在选择用JDK还是CGLiB的依据：

(1)当Bean实现接口时，Spring就会用JDK的动态代理

(2)当Bean没有实现接口时，Spring使用CGlib是实现

(3)可以强制使用CGlib（在spring配置中加入<aop:aspectj-autoproxy proxy-target-class=”true”/>）

三、CGlib比JDK快？

(1)使用CGLib实现动态代理，CGLib底层采用ASM字节码生成框架，使用字节码技术生成代理类，比使用Java反射效率要高。唯一需要注意的是，CGLib不能对声明为final的方法进行代理，因为CGLib原理是动态生成被代理类的子类。

(2)在对JDK动态代理与CGlib动态代理的代码实验中看，1W次执行下，JDK7及8的动态代理性能比CGlib要好20%左右。

垃圾收集算法？标记-清除算法缺点？复制算法缺点？标记-整理算法适用区域？解释一下分代收集算法？

Mark-Sweep（标记-清除）算法

标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。
标记-清除算法实现起来比较容易，当时容易产生内存碎片。碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。

Copying（复制）算法

复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。
这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
而且Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。

Mark-Compact（标记-整理）算法

为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。

Generational Collection（分代收集）算法

将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

内存分配与回收策略？

1. 对象优先在Eden分配
2. 大对象直接进入老年代
3. 长期存活的对象将进入老年代
4. 空间分配担保

有哪些垃圾收集器以及各自区别？Serial与ParNew异同点? ParNew与Paralell Scanvenge区别？

CMS最大特点及显著缺点？

Serial（新生代）/Serial Old（老年代）

Serial/Serial Old收集器是最基本最古老的收集器，它是一个单线程收集器，并且在它进行垃圾收集时，必须暂停所有用户线程。它的优点是实现简单高效，但是缺点是会给用户带来停顿。
Serial收集器是针对新生代的收集器，采用的是Copying算法。它的缺点是当Serial收集器想进行垃圾回收的时候，必须暂停用户的所有进程，即stop the world。但到现在为止，它依然是虚拟机运行在client模式下的默认新生代收集器，与其他收集器相比，对于限定在单个CPU的运行环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾回收自然可以获得最高的单线程收集效率。
Serial Old收集器是针对老年代的收集器，采用的是Mark-Compact算法。这个收集器的主要意义也是被Client模式下的虚拟机使用。在Server模式下，它主要还有两大用途：一个是在JDK1.5及以前的版本中与Parallel Scanvenge收集器搭配使用，另外一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。

通过指定-UseSerialGC参数，使用Serial + Serial Old的串行收集器组合进行内存回收。

ParNew（新生代）

ParNew收集器是Serial收集器新生代的多线程实现，注意在进行垃圾回收的时候依然会stop the world，只是相比较Serial收集器而言它会运行多条进程进行垃圾回收。

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百的保证能超越Serial收集器。当然，随着可以使用的CPU的数量增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

-UseParNewGC: 打开此开关后，使用ParNew + Serial Old的收集器组合进行内存回收，这样新生代使用并行收集器，老年代使用串行收集器。

Parallel Scavenge（新生代）/Parallel Old（老年代）

Parallel是采用复制算法的多线程新生代垃圾回收器，似乎和ParNew收集器有很多的相似的地方。但是Parallel Scanvenge收集器的一个特点是它所关注的目标是吞吐量(Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能够提升用户的体验；而高吞吐量则可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，采用多线程和”标记－整理”算法。这个收集器是在jdk1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是如果新生代Parallel Scavenge收集器，那么老年代除了Serial Old(PS MarkSweep)收集器外别无选择。由于单线程的老年代Serial Old收集器在服务端应用性能上的”拖累“，即使使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，又因为老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合”给力“。直到Parallel Old收集器出现后，”吞吐量优先“收集器终于有了比较名副其实的应用祝贺，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

-UseParallelGC: 虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行内存回收。-UseParallelOldGC: 打开此开关后，使用Parallel Scavenge + Parallel Old的收集器组合进行垃圾回收

CMS（老年代）

CMS(Concurrent Mark Swep)收集器是一个比较重要的回收器，应用非常广泛，CMS一种获取最短回收停顿时间为目标的收集器，这使得它很适合用于和用户交互的业务。从名字(Mark Swep)就可以看出，CMS收集器是基于标记清除算法实现的。它的收集过程分为四个步骤：

初始标记(initial mark) -stop the world
并发标记(concurrent mark)
重新标记(remark) -stop the world
并发清除(concurrent sweep)
注意初始标记和重新标记还是会stop the world，但是在耗费时间更长的并发标记和并发清除两个阶段都可以和用户进程同时工作。

不过由于CMS收集器是基于标记清除算法实现的，会导致有大量的空间碎片产生，在为大对象分配内存的时候，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前开启一次Full GC。为了解决这个问题，CMS收集器默认提供了一个-XX:+UseCMSCompactAtFullCollection收集开关参数（默认就是开启的)，用于在CMS收集器进行FullGC完开启内存碎片的合并整理过程，内存整理的过程是无法并发的，这样内存碎片问题倒是没有了，不过停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction参数用于设置执行多少次不压缩的FULL GC后跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。

不幸的是，它作为老年代的收集器，却无法与jdk1.4中已经存在的新生代收集器Parallel Scavenge配合工作，所以在jdk1.5中使用cms来收集老年代的时候，新生代只能选择ParNew或Serial收集器中的一个。ParNew收集器是使用-XX:+UseConcMarkSweepGC选项启用CMS收集器之后的默认新生代收集器，也可以使用-XX:+UseParNewGC选项来强制指定它。

G1

G1收集器是一款面向服务端应用的垃圾收集器。HotSpot团队赋予它的使命是在未来替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点：

并行与并发：G1能更充分的利用CPU，多核环境下的硬件优势来缩短stop the world的停顿时间。
分代收集：和其他收集器一样，分代的概念在G1中依然存在，不过G1不需要其他的垃圾回收器的配合就可以独自管理整个GC堆。
空间整合：G1收集器有利于程序长时间运行，分配大对象时不会无法得到连续的空间而提前触发一次GC。
可预测的非停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
在使用G1收集器时，Java堆的内存布局和其他收集器有很大的差别，它将这个Java堆分为多个大小相等的独立区域，虽然还保留新生代和老年代的概念，但是新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

虽然G1看起来有很多优点，实际上CMS还是主流。

哪些对象可归为GC Roots？

1. 虚拟机栈中引用的对象；
2. 方法区中类静态属性引用的对象；
3. 方法区中常量引用的对象；
4. 本地方法栈中Native方法引用的对象。

MinorGC与FullGC？

Minor GC

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。

1. 当 JVM 无法为一个新的对象分配空间时会触发Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
2. 内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
3. 执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
4. 质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。

所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。

Major GC

是清理整个堆空间—包括年轻代和老年代。

• 当年老代满时会引发Full GC，Full GC将会同时回收年轻代、年老代，
• 当永久代满时也会引发Full GC，会导致Class、Method元信息的卸载

许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的.