JVM类加载原理以及CG垃圾回收(JDK1.8永久代废除)大法

@[TOC](JVM类加载原理以及JAVA CG资料(包括JDK1.8永久代废除)整理)

1、JVM组成

最近在复习整理jvm调优方案,故而对JVM组成以及类加载过程进行一次整理,网上虽然也有,但是五花八门,自己通过多方面了解,进行整理.

1.1、JVM内存组成部分

比较详细的分法是分成五大部分:

1. 堆——用于对象的空间的分配。类的实例都是在堆内存上进行分配的。
2. 方法区——方法区底层存储也是在计算机堆内存上。但是为了与JVM给对象实例分配内存的堆进行区分，才将方法区称为非堆（non-heap）
3. 方法栈——每个方法被执行的时候都会创建一个栈帧用于存储局部变量表，操作栈，动态链接，方法出口等信息。每一个方法被调用的过程就对应一个栈帧在虚拟机栈中从入栈到出栈的过程。
4. 程序计数器——程序计数器是一块很小的内存空间，它是线程私有的，可以认作为当前线程的行号指示器
5. 本地方法栈——本地方法栈是与虚拟机栈发挥的作用十分相似,区别是虚拟机栈执行的是Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的native方法服务，可能底层调用的c或者c++,我们打开jdk安装目录可以看到也有很多用c编写的文件，可能就是native方法所调用的c代码。

其中1、2属于线程共享区,3、4、5则属于线程私有区,所以也有一种说法把最后三种统称为线程栈

1.2、.Class文件加载过程

加载过程如下图
当我们一个.Class文件在加载时,实际上是通过类加载器,加载到方法区中

2、GC简介

GC(Garbage Collection)：即垃圾回收器，诞生于1960年MIT的Lisp语言，主要是用来回收，释放垃圾占用的空间。
java GC泛指java的垃圾回收机制，该机制是java与C/C++的主要区别之一，我们在日常写java代码的时候，一般都不需要编写内存回收或者垃圾清理的代码，也不需要像C/C++那样做类似delete/free的操作。

2.1、为什么要学习GC?

对象的内存分配在java虚拟机的自动内存分配机制下，一般不容易出现内存泄漏问题。但是写代码难免会遇到一些特殊情况，比如OOM异常的。。所以了解GC算法后,可以比较快速的解决问题。

2.2、哪些内存要回收

java内存模型中分为五大区域已经有所了解。我们知道程序计数器、方法栈、本地方法栈属于线程私有，由线程而生，随线程而灭，其中栈中的栈帧随着方法的进入顺序的执行的入栈和出栈的操作，一个栈帧需要分配多少内存取决于具体的虚拟机实现并且在编译期间即确定下来【忽略JIT编译器做的优化，基本当成编译期间可知】，当方法或线程执行完毕后，内存就随着回收，因此无需关心。
而Java堆、方法区则不一样。方法区存放着类加载信息，但是一个接口中多个实现类需要的内存可能不太一样，一个方法中多个分支需要的内存也可能不一样【只有在运行期间才可知道这个方法创建了哪些对象没需要多少内存】，这部分内存的分配和回收都是动态的，gc关注的也正是这部分的内存。
所以以下针对这两块区域进行详解:

2.2.1、Java堆

对于大多数应用来说，Java 堆（Java Heap）是Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。

此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

堆内存是所有线程共有的，可以分为两个部分：年轻代和老年代。

下图中的Perm代表的是永久代，但是注意永久代并不属于堆内存中的一部分，同时jdk1.8之后永久代已经被移除。

1.新生代（Young Generation）NewSize和MaxNewSize分别可以控制年轻代的初始大小和最大的大小
2.老年代（Old Generation）
3.永久代（Permanent Generation）
从广义上讲，在堆中进行垃圾回收分为新生代（Young Generation）和老生代（Old Generation）；从细微之处来看，为了提高Java虚拟机进行垃圾回收的效率，又将新生代分成了三个独立的区域（这里的独立区域只是一个相对的概念，并不是说分成三个区域以后就不再互相联合工作了），分别为：Eden区（Eden Region）、From Survivor区（Form Survivor Region）以及To Survivor（To Survivor Region），而Eden区分配的内存较大，其他两个区较小，每次使用Eden和其中一块Survivor。Java虚拟机在进行垃圾回收时，将Eden和Survivor中还存活着的对象进行一次性地复制到另一块Survivor空间上，直到其两个区域中对象被回收完成，当Survivor空间不够用时，需要依赖其他老年代的内存进行分配担保。当另外一块Survivor中没有足够的空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老生代，在老生代中不仅存放着这一种类型的对象，还存放着大对象（需要很多连续的内存的对象），当Java程序运行时，如果遇到大对象将会被直接存放到老生代中，长期存活的对象也会直接进入老年代。如果老生代的空间也被占满，当来自新生代的对象再次请求进入老生代时就会报OutOfMemory异常。新生代中的垃圾回收频率高，且回收的速度也较快。就GC回收机制而言，JVM内存模型中的方法区更被人们倾向的称为永久代（Perm Generation），保存在永久代中的对象一般不会被回收。其永久代进行垃圾回收的频率就较低，速度也较慢。永久代的垃圾收集主要回收废弃常量和无用类。以String常量abc为例，当我们声明了此常量，那么它就会被放到运行时常量池中，如果在常量池中没有任何对象对abc进行引用，那么abc这个常量就算是废弃常量而被回收；判断一个类是否“无用”，则需同时满足三个条件：

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

虚拟机可以对满足上述3个条件的无用类进行回收，这里说的是可以回收而不是必然回收。

大多数情况下，对象在新生代Eden区中分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC；同理，当老年代中没有足够的内存空间来存放对象时，虚拟机会发起一次Major GC/Full GC。只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full CG。

虚拟机通过一个对象年龄计数器来判定哪些对象放在新生代，哪些对象应该放在老生代。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将该对象的年龄设为1。对象每在Survivor中熬过一次Minor GC，年龄就增加1岁，当他的年龄增加到最大值15时，就将会被晋升到老年代中。虚拟机并不是永远地要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中所有相同年龄的对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

2.2.2、方法区

有些文章并不将永久代纳入Java堆内存。其实永久代就是我们所说的方法区，而方法区经常被称为Non-Heap(非堆)。仅仅在HotSpot虚拟机的实现中才将GC分代收集扩展至方法区，或者说使用永久代来实现方法区，对于其他的虚拟机是不存在永久代这个概念的。
但是永久代其实是JDK1.8以前的说法,也就是说JDK1.8之后,就废除了永久代这个说法,改称之为元空间,且在1.7版本时,已经将字符串常量由永久代转移到堆中。所以方法区已经不负责保存字符串常量了,这一点也是需要注意的.
2.1 官方说明
参照JEP122：http://openjdk.java.net/jeps/122
原文截取：
Motivation
This is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation.

即：移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代。