jvm垃圾回收机制探析
最近比较粗浅的接触了一下JVM,发现有很多东西还是非常有意思的,并不像之前的印象,觉得JVM相关的东西生涩难懂。本文主要记录这段时间内对JVM的接触,主要包括这么几个内容:
-
JVM结构及内存管理机制
-
JVM垃圾回收常见算法
-
各种垃圾回收器对比分析
-
垃圾回收器参数汇总
1. JVM组成结构
JVM主要由3部分组成,分别是类加载子系统(ClassLoader),执行引擎(Execute Engine),运行数据区域(Runtime Data Area)。
1.1 类加载器
类加载器负责对Class文件的装载工作,JVM内部对ClassLoader也有一套完整的体系结构,ClassLoader主要分为以下几种:
-
Bootstrap ClassLoader
启动类加载器,Classloader体系的根节点,其他ClassLoader都是通过直接或间接继承至它,它在JVM启动时加载,主要加载<JAVA_HOME>\lib,或是-Xbootclasspath参数指定的路径中的,并且可以被虚拟机识别(仅仅按照文件名识别的)的类库到虚拟机内存中。 -
Extension ClassLoader
扩展类加载器,继承于Bootstrap,主要负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库。 -
Application ClassLoader
应用程序类加载器,继承至扩展类加载器,主要负责加载ClassPath路径上的类库,如果应用程序没有自定义自己类加载器,则这个就是默认的类加载器。
类加载器采用双亲委派模型工作,如果一个类加载器收到一个类加载的请求,它首先将这个请求委派给父类加载器去完成,每一个层次类加载器都是如此,则所有的类加载请求都会传送到顶层的启动类加载器,只有父加载器无法完成这个加载请求(即它的搜索范围中没有找到所要的类),子类才尝试加载。这样做的好处有两点:1)可以避免重复加载,2)安全角度考虑,防止用户自定义类加载器替代Java的核心API。
1.2 运行数据区
运行数据区实际上就是JVM的内存管理区,它主要分为5个部分,分别是:
-
方法区(Method Area)
方法区主要存放类信息,类的静态变量,常量,属性,方法等信息。 -
堆(heap)
所有通过new操作创建的对象的内存都在堆中分配。堆又被划分为新生代(Young Generation)和旧生代(Tenured Generation)。新生代又被进一步划分为Eden和Survivor区,最后Survivor由From和To组成,新建的对象都是用新生代的Eden分配内存,Eden空间不足的时候,会把存活的对象转移到Survivor中,新生代大小可以由-Xmn来控制,也可以用-XX:SurvivorRatio来控制Eden和Survivor的比例旧生代。eden,from ,to的默认比例是8:1:1。 -
栈(Stack)
每个线程执行每个方法的时候都会在栈中申请一个栈帧,每个栈帧包括局部变量区和操作数栈,用于存放此次方法调用过程中的临时变量、参数和中间结果 -
程序计数器(Program Counter Register)
-
本地方法栈(Native Method Stack)
用于支持native方法的执行,存储了每个native方法调用的状态。
2. JVM垃圾回收算法
JVM垃圾回收要经过两个主要过程,垃圾的收集和垃圾的回收,对于垃圾收集,主要有以下两种算法:
2.1 垃圾收集
2.1.1 引用计数算法
在JDK1.2之前,使用的是引用计数器算法,即当这个类被加载到内存以后,就会产生方法区,堆栈、程序计数器等一系列信息,当创建对象的时候,为这个对象在堆栈空间中分配对象,同时会产生一个引用计数器,同时引用计数器+1,当有新的引用的时候,引用计数器继续+1,而当其中一个引用销毁的时候,引用计数器-1,当引用计数器被减为零的时候,标志着这个对象已经没有引用了,可以回收了!
,但是随着业务的发展,很快出现了一个问题当我们的代码出现下面的情形时,该算法将无法适应:
ObjA.obj = ObjB
ObjB.obj = ObjA
这样的代码会产生如下引用情形 objA指向objB,而objB又指向objA,这样当其他所有的引用都消失了之后,objA和objB还有一个相互的引用,也就是说两个对象的引用计数器各为1,而实际上这两个对象都已经没有额外的引用,已经是垃圾了。
2.1.2 根搜索算法
根搜索算法是从离散数学中的图论引入的,程序把所有的引用关系看作一张图,从一个节点GC ROOT开始,寻找对应的引用节点,找到这个节点以后,继续寻找这个节点的引用节点,当所有的引用节点寻找完毕之后,剩余的节点则被认为是没有被引用到的节点,即无用的节点。
目前java中可作为GC Root的对象有:
1、 虚拟机栈中引用的对象(本地变量表)
2、 方法区中静态属性引用的对象
3、 方法区中常量引用的对象
4、 本地方法栈中引用的对象(Native对象)
2.2 垃圾回收算法
对于收集到的垃圾,JVM是采用什么算法进行回收的呢?主要有这么几种:
- 标记-清除算法
- 复制算法
- 标记-整理算法
2.2.1 标记清除算法
标记-清除算法采用从根集合进行扫描,对存活的对象对象标记,标记完毕后,再扫描整个空间中未被标记的对象,进行回收,如图所示。
标记-清除算法不需要进行对象的移动,并且仅对不存活的对象进行处理,在存活对象比较多的情况下极为高效,但由于标记-清除算法直接回收不存活的对象,因此会造成内存碎片!
标记清除算法
2.2.2 复制算法
复制算法采用从根集合扫描,并将存活对象复制到一块新的,没有使用过的空间中,这种算法当控件存活的对象比较少时,极为高效,但是带来的成本是需要一块内存交换空间用于进行对象的移动
复制算法
2.2.3 标记整理算法
标记-整理算法采用标记-清除算法一样的方式进行对象的标记,但在清除时不同,在回收不存活的对象占用的空间后,会将所有的存活对象往左端空闲空间移动,并更新对应的指针。标记-整理算法是在标记清除算法的基础上,又进行了对象的移动,因此成本更高,但是却解决了内存碎片的问题。
标记整理算法
3. JVM 常见垃圾回收器
为了达到最优效果,JVM分别针对新生代和旧生代实现了不同的垃圾回收器。如图:
垃圾回收器
3.1 串行回收器(Serial)
Serial收集器是历史最悠久的一个回收器,JDK1.3之前广泛使用这个收集器,目前也是ClientVM下 ServerVM 4核4GB以下机器的默认垃圾回收器。串行收集器并不是只能使用一个CPU进行收集,而是当JVM需要进行垃圾回收的时候,需要中断所有的用户线程,知道它回收结束为止,因此又号称“Stop The World”的垃圾回收器。
3.2 ParNew回收器
ParNew收集器其实就是多线程版本的Serial收集器,同样有
Stop The World的问题,他是多CPU模式下的首选回收器(该回收器在单CPU的环境下回收效率远远低于Serial收集器,所以一定要注意场景哦),也是Server模式下的默认收集器。
3.3 ParallelScavenge
ParallelScavenge又被称为是吞吐量优先的收集器。
3.4 SerialOld
SerialOld是旧生代Client模式下的默认收集器,单线程执行;在JDK1.6之前也是ParallelScvenge回收新生代模式下旧生代的默认收集器,同时也是并发收集器CMS回收失败后的备用收集器。
3.5 ParallelOld
ParallelOld是老生代并行收集器的一种,使用标记整理算法、是老生代吞吐量优先的一个收集器。这个收集器是JDK1.6之后刚引入的一款收集器,早期没有ParallelOld之前,吞吐量优先的收集器老生代只能使用串行回收收集器,大大的拖累了吞吐量优先的性能,自从JDK1.6之后,才能真正做到较高效率的吞吐量优先。
3.6 CMS
CMS又称响应时间优先(最短回收停顿)的回收器,使用并发模式回收垃圾,使用标记-清除算法,CMS对CPU是非常敏感的,它的回收线程数=(CPU+3)/4,因此当CPU是2核的实惠,回收线程将占用的CPU资源的50%,而当CPU核心数为4时仅占用25%。