垃圾收集器需要干三件事:哪些内存需要回收,什么时候回收,如何回收?本文将围绕着三个方面探讨。
目录
3.3.3、 Parallel Scavenge收集器(多线程复制算法、高效)
3.3.4、Serial Old收集器(单线程标记整理算法)
3.3.5、Parallel Old收集器(多线程标记整理算法)
一、哪些内存需要回收?
Java运行时区域各部分包含:程序计数器、虚拟机栈、本地方法栈,JAVA堆、方法区五大部分。其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生,随线程而灭,且在编译器可知(每个栈贞中分配多少内存基本上是在类结果确定下来时就已知),因此这三个区域的内存分配和回收是确定的,所有垃圾收集器无需关注,而需要回收的是java堆与方法区两部分的内存。
二、什么时候回收?
- java堆
2.1 引用计数法(非主流)
在Java中,引用和对象是有关联的。如果要操作对象则必须用引用进行。因此,很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说,即一个对象如果没有任何与之关联的引用,即他们的引用计数都不为0,则说明对象不太可能再被用到,那么这个对象就是可回收对象。
2.2、判读对象的生死(可达性分析算法,主流)
java用可达性分析算法计算对象是否存活,这个算法原理是通过一系列的GC Roots的根对象作为起始节点集,从这些节点开始根据引用关系向下搜索,搜索过程中经过所有的路径称为引用链,如果某个对象没有任何引用链相连,则证明此对象不可能被引用。
如下图:object5、object6、object7判定为可回收对象(不可达)
2.3、对象自救(finalize方法)
即使对象定为不可达对象,也不是非死不可,这时他们暂时处于缓存阶段,要宣告死亡需要经过两次标记阶段,再经过一次标记之后会进行一次刷选,刷选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法、或者finalize()方法已经被虚拟机调用果,那么虚拟机将这两种情况视为没必要执行,换言之可判为死刑。此处可借用finalize()方法来自救对象,java中一般不用此方法,推荐用try-finally。
2.4、可作为GC Roots的对象有:
- 虚拟机栈(栈帧中的本地变量表)中引用的对象。
- 方法区中类静态属性引用的对象,如java类的引用类型静态变量
- 方法区中常量引用的对象。
- 本地方法栈中JNI(即一般说的Native方法)引用的对象。
- Java虚拟机内部的引用,基本类型对应得class对象,异常对象,类加载器。
- 所有同步锁持有的对象(synchronized关键字)
- 除了固定的GC Roots集还有其他零时性地加入共同构成GC Roots集。
- 方法区
2.5、方法区回收
方法区主要回收两部分:废弃的常量和不再使用的类型
- 常量:没有任何字符串引用常量池中的‘常量’,且虚拟机也没任何地方引用这个字面量,如果在这时发生内存回收且垃圾回收器判断有必要回收,系统就会清理。常量池中的其他类(接口)、方法、字段的符号引用与此类似。
- 类型:回收的三个条件,该类的所有实例已经被收回;加载该类的加载器已被收回;该类对应的java.lang.class对象没有任何对象被引用。
三、如何回收?
分代收集理论:
1、强分代收集理论:绝大多数对象是朝生熄灭;
2、熬过月多次垃圾收集过程的对象就越难以消亡;
这两条分代理论奠定了多款常用的垃圾回收器的一直设计原则:收集器应该讲JAVA堆划分为不同的区域,然后将回收对象根据年龄分配到不同的区域中存储,JAVA堆划分为不同的区域后,垃圾收集器才每次可以只回收某一个或某些部分区域,因而才有了
Minor GC、Major GC、Full GC这样的回收类型划分,也因此根据不同区域的特性产生了,标记清除算法(Mark-Sweep)、复制算法(Copying)、标记整理算法(Mark-Compact)。
3.1垃圾回收算法
3.1.1标记清除算法(Mark-Sweep)
顾名思义分为两个阶段,标注和清除。标记阶段标记出所有需要回收的对象,清除阶段回收被标记的对象所占用的空间。
缺点:
1、从图中我们就可以发现,该算法最大的问题是内存碎片化严重,后续可能发生大对象不能找到可利用空间的问题;
2、随着清理对象的增加,性能下降,所以执行效率不稳定。
3.1.2复制算法(copying)
为了解决Mark-Sweep算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块,当这一块内存满后将尚存活的对象复制到另一块上去,把已使用的内存清掉
优点:
没有标记和清除过程,实现简单,运行高效。
复制过去以后保证空间的连续性,不会出现"碎片"问题
缺点:
可用内存被压缩到了原本的一半,且存活对象增多的话,Copying算法的效率会大大降低。
3.1.3标记整理算法(Mark-Compact)
结合了以上两个算法,为了避免缺陷而提出。标记阶段和Mark-Sweep算法相同,标记后不是清理对象,而是将存活对象移向内存的一端。然后清除端边界外的对象
3.2、各分区所用的算法
分代收集法是目前大部分JVM所采用的方法,其核心思想是根据对象存活的不同生命周期将内存划分为不同的域,一般情况下将GC堆划分为老生代(Tenured/Old Generation)和新生代(Young Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收,新生代的特点是每次垃圾回收时都有大量垃圾需要被回收,因此可以根据不同区域选择不同的算法。
3.2.1、新生代与复制算法
目前大部分JVM的GC对于新生代都采取Copying算法,因为新生代中每次垃圾回收都要回收大部分对象,即要复制的操作比较少,但通常是按照8 : 1 : 1来划分新生代。一般将新生代划分为一块较大的Eden空间和两个较小的Survivor空间(From Space, To Space),每次使用Eden空间和其中的一块Survivor空间,当进行回收时,将该两块空间中还存活的对象复制到另一块Survivor空间中。
3.2.3、老年代与标记整理算法
老年代因为每次只回收少量对象,因而采用Mark-Compact算法。
3.2.4、各区域清理数据
1.JAVA虚拟机提到过的处于方法区的永生代(Permanet Generation),它用来存储class类,常量,方法描述等。对永生代的回收主要包括废弃常量和无用的类。
2.对象的内存分配主要在新生代的Eden Space和Survivor Space的From Space(Survivor目前存放对象的那一块),少数情况会直接分配到老生代。
3.当新生代的Eden Space和From Space空间不足时就会发生一次GC,进行GC后,Eden Space和From Space区的存活对象会被挪到To Space,然后将Eden Space和From Space进行清理。
4.如果To Space无法足够存储某个对象,则将这个对象存储到老生代。
5.在进行GC后,使用的便是Eden Space和To Space了,如此反复循环。
6.当对象在Survivor区躲过一次GC后,其年龄就会+1。默认情况下年龄到达15的对象会被移到老生代中。
3.3、虚拟机的垃圾收集器
Java堆内存被划分为新生代和年老代两部分,新生代主要使用复制和标记-清除垃圾回收算法;年老代主要使用标记-整理垃圾回收算法,因此java虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器。
3.3.1、Serial垃圾收集器(单线程、复制算法)
Serial(英文连续)是最基本垃圾收集器,使用复制算法,曾经是JDK1.3.1之前新生代唯一的垃圾收集器。Serial是一个单线程的收集器,它不但只会使用一个CPU或一条线程去完成垃圾收集工作,并且在进行垃圾收集的同时,必须暂停其他所有的工作线程,直到垃圾收集结束。Serial垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程,但是它简单高效,对于限定单个CPU环境来说,没有线程交互的开销,可以获得最高的单线程垃圾收集效率,因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。
3.3.2、ParNew垃圾收集器(Serial+多线程)
ParNew垃圾收集器其实是Serial收集器的多线程版本,也使用复制算法,除了使用多线程进行垃圾收集之外,其余的行为和Serial收集器完全一样,ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。ParNew收集器默认开启和CPU数目相同的线程数,可以通过-XX:ParallelGCThreads参数来限制垃圾收集器的线程数。【Parallel:平行的】ParNew虽然是除了多线程外和Serial收集器几乎完全一样,但是ParNew垃圾收集器是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。
3.3.3、 Parallel Scavenge收集器(多线程复制算法、高效)
Parallel Scavenge收集器也是一个新生代垃圾收集器,同样使用复制算法,也是一个多线程的垃圾收集器,它重点关注的是程序达到一个可控制的吞吐量(Thoughput,CPU用于运行用户代码的时间/CPU总消耗时间,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)),高吞吐量可以最高效率地利用CPU时间,尽快地完成程序的运算任务,主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。
3.3.4、Serial Old收集器(单线程标记整理算法)
Serial Old是Serial垃圾收集器年老代版本,它同样是个单线程的收集器,使用标记-整理算法,这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。在Server模式下,主要有两个用途:
1.在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。
2.作为年老代中使用CMS收集器的后备垃圾收集方案。
新生代Serial与年老代Serial Old搭配垃圾收集过程图:
新生代Parallel Scavenge收集器与ParNew收集器工作原理类似,都是多线程的收集器,都使用的是复制算法,在垃圾收集过程中都需要暂停所有的工作线程。新生代Parallel Scavenge/ParNew与年老代Serial Old搭配垃圾收集过程图:
3.3.5、Parallel Old收集器(多线程标记整理算法)
Parallel Old收集器是Parallel Scavenge的年老代版本,使用多线程的标记-整理算法,在JDK1.6才开始提供。在JDK1.6之前,新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器,只能保证新生代的吞吐量优先,无法保证整体的吞吐量,Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器,如果系统对吞吐量要求比较高,可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。
新生代ParallelScavenge和年老代Parallel Old收集器搭配运行过程图:
3.3.6、CMS收集器(多线程标记清除算法)
Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器,其最主要目标是获取最短垃圾回收停顿时间,和其他年老代使用标记-整理算法不同,它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。
CMS工作机制相比其他的垃圾收集器来说更复杂,整个过程分为以下4个阶段:
初始标记:
只是标记一下GC Roots能直接关联的对象,速度很快,仍然需要暂停所有的工作线程。
并发标记:
进行GC Roots跟踪的过程,和用户线程一起工作,不需要暂停工作线程。
重新标记:
为了修正在并发标记期间,因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录,仍然需要暂停所有的工作线程。
并发清除:
清除GC Roots不可达对象,和用户线程一起工作,不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中,垃圾收集线程可以和用户现在一起并发工作,所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。
CMS收集器工作过程:
3.3.7、G1收集器
Garbage first垃圾收集器是目前垃圾收集器理论发展的最前沿成果,相比与CMS收集器,G1收集器两个最突出的改进是:
1.基于标记-整理算法,不产生内存碎片。
2.可以非常精确控制停顿时间,在不牺牲吞吐量前提下,实现低停顿垃圾回收。
G1收集器避免全区域垃圾收集,它把堆内存划分为大小固定的几个独立区域,并且跟踪这些区域的垃圾收集进度,同时在后台维护一个优先级列表,每次根据所允许的收集时间,优先回收垃圾最多的区域。区域划分和优先级区域回收机制,确保G1收集器可以在有限时间获得最高的垃圾收集效率。
3.4、GC参数
规律:
GC常用参数:
-Xmn -Xms -Xmx –Xss 年轻代 最小堆 最大堆 栈空间
-XX:+UseTLAB 使用 TLAB,默认打开
-XX:+PrintTLAB 打印 TLAB的使用情况
-XX:TLABSize 设置 TLAB大小
-XX:+DisableExplicitGC 启用用于禁用对的调用处理的选项 System.gc()
-XX:+PrintGC 查看 GC基本信息
-XX:+PrintGCDetails 查看 GC详细信息
-XX:+PrintHeapAtGC 每次一次 GC后,都打印堆信息
-XX:+PrintGCTimeStamps 启用在每个 GC上打印时间戳的功能
-XX:+PrintGCApplicationConcurrentTime 打印应用程序时间(低)
-XX:+PrintGCApplicationStoppedTime 打印暂停时长(低)
-XX:+PrintReferenceGC 记录回收了多少种不同引用类型的引用(重要性低)
-verbose:class 类加载详细过程
-XX:+PrintVMOptions 可在程序运行时,打印虚拟机接受到的命令行显示参数
-XX:+PrintFlagsFinal -XX:+PrintFlagsInitial 打印所有的 JVM参数、查看所有 JVM参数启动的初始值(必须会用)
-XX:MaxTenuringThreshold 升代年龄,最大值 15, 并行(吞吐量)收集器的默认值为 15,而 CMS收集器的默认值为 6。
Parallel常用参数
-XX:SurvivorRatio 设置伊甸园空间大小与幸存者空间大小之间的比率。默认情况下,此选项设置为 8
-XX:PreTenureSizeThreshold 大对象到底多大,大于这个值的参数直接在老年代分配
-XX:MaxTenuringThreshold 升代年龄,最大值 15, 并行(吞吐量)收集器的默认值为 15,而 CMS收集器的默认值为 6。
-XX:+ParallelGCThreads 并行收集器的线程数,同样适用于 CMS,一般设为和 CPU核数相同
-XX:+UseAdaptiveSizePolicy 自动选择各区大小比例
CMS常用参数
-XX:+UseConcMarkSweepGC 启用 CMS垃圾回收器
-XX:+ParallelGCThreads 并行收集器的线程数,同样适用于 CMS,一般设为和 CPU核数相同
-XX:CMSInitiatingOccupancyFraction 使用多少比例的老年代后开始 CMS收集,默认是 68%(近似值),如果频繁发生 SerialOld卡顿,应该调小,(频繁 CMS回收)
-XX:+UseCMSCompactAtFullCollection 在 FGC时进行压缩
-XX:CMSFullGCsBeforeCompaction 多少次 FGC之后进行压缩
-XX:+CMSClassUnloadingEnabled 使用并发标记扫描(CMS)垃圾收集器时,启用类卸载。默认情况下启用此选项。
-XX:CMSInitiatingPermOccupancyFraction 达到什么比例时进行 Perm回收,JDK 8中不推荐使用此选项,不能替代。
-XX:GCTimeRatio 设置 GC时间占用程序运行时间的百分比(不推荐使用)
-XX:MaxGCPauseMillis 停顿时间,是一个建议时间,GC会尝试用各种手段达到这个时间,比如减小年轻代
G1常用参数
-XX:+UseG1GC 启用 CMS 垃圾收集器
-XX:MaxGCPauseMillis 设置最大 GC暂停时间的目标(以毫秒为单位)。这是一个软目标,并且 JVM将尽最大的努力(G1会尝试调整 Young区的块数来)来实现它。默认情况下,没有最大暂停时间值。
-XX:GCPauseIntervalMillis GC的间隔时间
-XX:+G1HeapRegionSize 分区大小,建议逐渐增大该值,1 2 4 8 16 32。随着 size 增加,垃圾的存活时间更长,GC间隔更长,但每次 GC 的时间也会更长
-XX:G1NewSizePercent 新生代最小比例,默认为 5%
-XX:G1MaxNewSizePercent 新生代最大比例,默认为 60%
-XX:GCTimeRatioGC 时间建议比例,G1会根据这个值调整堆空间
-XX:ConcGCThreads 线程数量
-XX:InitiatingHeapOccupancyPercent 启动 G1的堆空间占用比例,根据整个堆的占用而触发并发 GC周期