JVM体系结构、垃圾回收算法

JVM体系概览

上图中亮色区域有两个特点：
1.所有线程共享，灰色是线程私有的
2.存在垃圾回收GC

类加载器

注意：
1.方法区并不是存放方法的区域，而是存放类的描述信息（类模板）
2.Class Loader类加载器只负责类的加载，角色就像“快递员”，可以有多种
3.加载之前是“小class”，加载之后就变成“大Class”，这是安装java.lang.Class模板生成的实例。大Class装载在方法区，模板实例化可以得到n个相同的实例对象
4.jvm通过文件开头的特定文件标识来判断文件是否需要被加载，而不是通过后缀名.class,如下图

类装载器的分类：

类装载器分为虚拟机自带的和用户自定义的，系统自带的三个：
1.启动类加载器（Bootstrap），C++所写
2.扩展类加载器（Extension），Java所写
3.应用程序类加载器（AppClassLoader）
（我们自己new的时候创建的是应用程序类加载器）

public class test {
	//查看类加载器
	public static void main(java.lang.String[] args) {
		// TODO Auto-generated method stub
		Object object=new Object();
		System.out.println(object.getClass().getClassLoader());
		//输出null
		//查看Object的加载器上一层
		//System.out.println(object.getClass().getClassLoader().getParent());
		//Exception in thread "main" java.lang.NullPointerException  已经是祖先了不能再向上
		
		System.out.println();
		
		test t = new test();
		System.out.println(t.getClass().getClassLoader().getParent().getParent());
		//null  到达最顶
		System.out.println(t.getClass().getClassLoader().getParent());
		//sun.misc.Launcher$ExtClassLoader@15db9742
		System.out.println(t.getClass().getClassLoader());
		//sun.misc.Launcher$AppClassLoader@73d16e93
	}

}

1.JDK自带的类（Object，String，ArrayList等）使用的是Bootstrap加载器；自己写的类使用的是APPClassLoader加载器；Extension加载器是负责加载java更新的程序包的类进行加载
2.sun.misc.Launcher是JVM的入口应用
3.Java加载器个数为3+1。前三个是系统自带的，用户可以定制类的加载方式，通过继承Java. lang. ClassLoader

• 双亲委派机制–>向上找：一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载器中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载。
• 采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object对象。

public class String {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		System.out.println("hello world");
		//错误: 在类 2020.String 中找不到 main 方法
	}

}

在上面的代码中，加载到Bootstrap加载器中时，由于JVM有java.lang.String这个类，所以会先加载这个类，而不是自己写的String类，但是jvm的String中没有main方法，所以报错找不到 main 方法。
上面的例子中就说明java中有两个相同的类时，java会用哪一个，因此为了保证用户写的源代码不会污染java出厂自带的源代码，JVM的双亲委派机制，保证了“沙箱安全”。

Execution Engine执行引擎

Execution Engine执行引擎负责解释命令，提交操作系统执行。

Native Interface本地接口

本地接口的作用是融合不同的编程语言为 Java 所用，它的初衷是融合 C/C++程序，Java 诞生的时候是 C/C++横行的时候，要想立足，必须有调用 C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是 Native Method Stack中登记 native方法，在Execution Engine 执行时加载native libraies。
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用 Socket通信，也可以使用Web Service等等

本地方法栈

它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。

native关键字声明的方法是系统级的，属于底层操作系统，java不能对其进行操作，native方法装载载本地方法栈中（Native method stack）

• 注：java栈和本地方法栈的区别：我们平时说的栈是指的Java栈，native method stack 里面装的都是native方法。

PC寄存器

native方法不归java管，所以计数器是空的。

方法区Method Area

供各线程共享的运行时内存区域。它存储了每一个类的结构信息，例如运行时常量池（Runtime Constant Pool）、字段和方法数据、构造函数和普通方法的字节码内容。上面讲的是规范，在不同虚拟机里头实现是不一样的，最典型的就是永久代(PermGen space)和元空间(Metaspace)。
注：实例变量存在堆内存中,和方法区无关
方法区不是放方法的地方，存储的是类的结构信息

Stack栈

    栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

栈帧中主要保存3 类数据：
本地变量（Local Variables）:输入参数和输出参数以及方法内的变量；
栈操作（Operand Stack）:记录出栈、入栈的操作；
栈帧数据（Frame Data）:包括类文件、方法等等。
注意：
栈管运行，堆管存储；
栈是线程私有，不存在垃圾回收；
栈帧：java中的方法被扔进虚拟机的栈空间后就成为栈帧，比如main方法，被压栈后就成为栈帧。Java 方法 = 栈帧

public class test {
    public static void m() {
        m();
    }
    public static void main(String[] args) {
        System.out.println("1111");
        m();
        System.out.println("2222");

    }
}

/*
output:
1111
Exception in thread "main" java.lang.StackOverflowError
 */

注意：StackOverflowError是一个错误，并非异常！！！

• HotSpot:一般jdk的名字就叫做HotSpot
  

元数据 = 类型数据：描述数据的数据，即模板==大Class，例如：

Heap 堆

java8把永久区换成了元空间
逻辑上，堆由新生区+养老区+元空间三部分组成，物理上由新生区+养老区组成。新生区占1/3,养老区占2/3,新生区又分成三部分。
当执行new Person()；时，其实是new在新生区的伊甸园区，然后往下走，走到养老区，但是并未到元空间

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到 1 区。那如果1 区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

1.GC发生在伊甸园区，当对象快占满新生代时，就会发生YGC（Young GC，轻量级GC），伊甸园区基本全部清空
2.幸存者0区(S0)，别名“from区”。伊甸园区没有被YGC清空的对象将移至幸存者0区，如果幸存者0区满了，就会继续往下移到幸存者1区（也叫to区），如果经历数次YGC操作对象还没有消亡，最终会来到养老区
3.如果到最后，养老区也满了，那么就对养老区进行FGC(Full GC，重GC)，对养老区进行清洗
4.如果进行了多次FGC之后，还是无法腾出养老区的空间，就会报OOM（out of Memory）异常
5.from区和to区的位置是不固定的，每次GC过后都会进行交换，交换后，谁空谁是to区

永久区（方法区）几乎没有垃圾回收。

JVM垃圾回收

堆的参数主要有两个：-Xms，-Xmx，xms是对的初始化大小，xmx是堆的最大化
新生代Young Gen有一个参数-Xmn，这个参数可以调整新生区和养老区的比例，但是一般不调。
永久带也有两个参数，-XX:PermSize,-XX:MaxPermSize,分别调永久带的初始值和最大值，java8后没有这两个参数了，因为java8后元空间不在虚拟机内，而是在本机物理内存中

public class TestHeap {

	public static void main(java.lang.String[] args) {
		// TODO Auto-generated method stub
		long maxMemory = Runtime.getRuntime().maxMemory();
		//返回java虚拟机试图使用的最大内存量,=物理内存的1/4（-Xmx）
		
		long totalMemory = Runtime.getRuntime().totalMemory();
		//返回java虚拟机中的内存容量（初始值） = 物理内存的1/64（-Xms）
		
		System.out.println("Max_Memory="+maxMemory+"(字节)、"+(maxMemory/(double)1024/1024)+"MB");
		
		System.out.println("TOTAL_memory="+totalMemory+"（字节）、"+(totalMemory/(double)1024/1024)+"MB");
		
		
		
	}

}

GC收集日志信息详解：

面试题
1.GC是什么（分代收集算法）：次数上频繁收集Young区，较少收集Old区，基本不动元空间
2.GC四大算法：复制算法、标记清除算法、标记压缩算法、分代收集算法
3.下面程序中，有几个进程在运行

ans:有两个线程，一个是main线程，一个是后台的gc线程。

• 知识点：
• JVM在进行GC时，并非每次都对三个内存区域一起回收，大部分回收的是新生代。因此GC按照回收的区域分为普通GC（minor GC或Young GC），一种是全局GC（major GC或Full GC）
• Minor GC和Full GC的区别：普通GC（minor GC）：只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。全局GC（major GC or Full GC）：指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC（但并不是绝对的）。Major GC的速度一般要比Minor GC慢上10倍以上 (因为养老区比较大，占堆的2/3)

GC四大算法

1.复制算法
年轻带中Minor GC使用的就是复制算法。

因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块(from)，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法的优点是不会产生内存碎片，缺点是耗费空间，浪费内存。 如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。 所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。

2.标记清除（Mark- Sweep）

主要进行两项工作，第一项则是标记，第二项则是清除。
标记：从引用根节点开始标记遍历所有的GC Roots， 先标记出要回收的对象。
清除：遍历整个堆，把标记的对象清除。

1.标记清除算法缺点是效率比较低，而且在GC时，需要停止应用程序，这会导致用户体验差
2.其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

3.标记压缩（Mark-Compact）
标记压缩(Mark-Compact)又叫标记清除压缩(Mark-Sweep-Compact)，或者标记清除整理算法。老年代一般是由标记清除或者是标记清除与标记整理的混合实现

4.分代收集算法

当前商业虚拟机都是采用分代收集算法，它根据对象存活周期的不同将内存划分为几块，一般是把Java堆分为新生代和老年代，然后根据各个年代的特点采用最适当的收集算法，在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，就选用复制算法，而老年代因为对象存活率高，没有额外空间对它进行分配担保，就必须使用“标记清理”或者“标记整理”算法来进行回收。

1.四种算法哪个好？
Answer：没有那个算法是能一次性解决所有问题的，因为JVM垃圾回收使用的是分代收集算法，没有最好的算法，只有根据每一代他的垃圾回收的特性用对应的算法。新生代使用复制算法，老年代使用标记清除和标记整理算法。没有最好的垃圾回收机制，只有最合适的。
2.各个垃圾回收算法的优缺点
ans：内存效率：复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法=标记整理算法>标记清除算法。
内存利用率：标记整理算法=标记清除算法>复制算法。
可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程

难道就没有一种最优算法吗？Java 9 之后出现了G1垃圾回收器（使用分代收集），能够解决以上问题。

—总结：

年轻代(Young Gen)

年轻代特点是区域相对老年代较小，对像存活率低。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)

老年代的特点是区域较大，对像存活率高。

这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

Mark阶段的开销与存活对像的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率。

Sweep阶段的开销与所管理区域的大小形正相关，但Sweep“就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

Compact阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一选择并不合适。

基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以hotspot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对像的回收效率很高，而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器做为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。

参考：尚硅谷周阳视频