JVM里的垃圾回收机制

垃圾回收器不是我们程序员能去控制的,但是可以通过程序去影响它。

再来看一下JVM架构图:


在jvm中,内存中的垃圾数据都是有jvm中的垃圾回收器自动处理的,这里需要我们了解的知识点:
1、垃圾回机制是什么
自动垃圾收集机制是不定时查看堆内存、判定那些对象是在使用的对象和未使用的对象、删除未使用的对象的一个过程。对于使用对象或者引用对象,指的是你的程序持有一个指向那个对象的引用。对于未使用的对象或者是无引用对象,则不被你程序的任何部分持有引用。所以,无引用对象使用的内存是可以被重新回收利用的。
 
 
2、垃圾回收算法
①引用计数法:
给对象中添加一个引用计数器,每当有一个地方引用他时,计数器值就+1,;当引用失效时,计数器值就-1;任何时刻计数器为0的对象就是不可能在被使用,判断为不可达,等待gc清理。
这种算法几乎报废因为存在两个问题:
a) 两个对象相互引用,gc永远都清除不了,看例子

 

b) 引用计数法无法解决多种类型引用的问题

java内存管理分为内存分配和内存回收,都不需要程序员负责,垃圾回收的机制主要是看对象是否有引用指向该对象。
java对象的引用包括: 强引用,软引用,弱引用,虚引用
Java中提供这四种引用类型主要有两个目的:
第一是可以让程序员通过代码的方式决定某些对象的生命周期;
第二是有利于JVM进行垃圾回收。
1.强引用
是指创建一个对象并把这个对象赋给一个引用变量。
比如:
public void fun1() {
Object object = new Object();
Object[] objArr = new Object[1000];
}
当运行至Object[] objArr = new Object[1000];这句时,如果内存不足,JVM会抛出OOM错误也不会回收object指向的对象。不过要注意的是,当fun1运行完之后,object和objArr都已经不存在了,所以它们指向的对象都会被JVM回收。
如果想中断强引用和某个对象之间的关联,可以显示地将引用赋值为null,这样一来的话,JVM在合适的时间就会回收该对象。
 
2.软引用(SoftReference
如果一个对象(软可达)具有软引用,内存空间足够,垃圾回收器就不会回收它;
如果内存空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。
软引用可用来实现内存敏感的高速缓存,比如网页缓存、图片缓存等。使用软引用能防止内存泄露,增强程序的健壮性。
也就是说,一旦SoftReference保存了对一个Java对象的软引用后,在垃圾线程对 这个Java对象回收前,SoftReference类所提供的get()方法返回Java对象的强引用;垃圾线程回收该Java对象之 后,get()方法将返回null。
比如:
MyObject aRef = new MyObject();
SoftReference aSoftRef=new SoftReference(aRef);
此时,对于这个MyObject对象,有两个引用路径,一个是来自aSoftRef对象的软引用,一个来自变量aRef的强引用,所以这个MyObject对象是强可及对象。
随即,我们可以结束aReference对这个MyObject实例的强引用:aRef = null;
此后,这个MyObject对象成为了软引用对象。如果垃圾收集线程进行内存垃圾收集,并不会因为有一个SoftReference对该对象的引用而始终保留该对象。
Java虚拟机的垃圾收集线程对软可及对象和其他一般Java对象进行了区别对待:软可及对象的清理是由垃圾收集线程根据其特定算法按照内存需求决定的。
也就是说,垃圾收集线程会在虚拟机抛出OutOfMemoryError之前回收软可及对象,而且虚拟机会尽可能优先回收长时间闲置不用的软可及对象,对那些刚刚构建的或刚刚使用过的“新”软可及对象会被虚拟机尽可能保留。在回收这些对象之前,我们可以通过:MyObject anotherRef=(MyObject)aSoftRef.get(); 重新获得对该实例的强引用。而回收之后,调用get()方法就只能得到null了。
 
3.弱引用(WeakReference)
弱引用也是用来描述非必需对象的,当JVM进行垃圾回收时,无论内存是否充足,都会回收被弱引用关联的对象。在java中,用java.lang.ref.WeakReference类来表示。下面是使用示例:

2019-10-14新增开始
import java.lang.ref.WeakReference;

public class Test02 {
    public static void main(String[] args) {
        WeakReference<Object> reference = new WeakReference<Object>(new Object());
        System.out.println(reference.get());
        System.gc(); //通知JVM回收资源
        System.out.println(reference.get());
    }
}
 
2019-10-14新增结束

要JVM进行垃圾回收,被弱引用关联的对象必定会被回收掉。不过要注意的是,这里所说的被弱引用关联的对象是指只有弱引用与之关联,如果存在强引用同时与之关联,则进行垃圾回收时也不会回收该对象。例如:

2019-10-14新增开始
import java.lang.ref.WeakReference;

public class Test01 {
    
    public static void main(String[] args) {
        Object object = new Object();
        WeakReference<Object> reference = new WeakReference<Object>(object);
        System.out.println(reference.get());
        System.gc(); //通知JVM回收资源
        System.out.println(reference.get());
    }
}
 
2019-10-14新增结束

4.虚引用(PhantomReference)
虚引用和前面的软引用、弱引用不同,它并不影响对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联,则跟没有引用与之关联一样,在任何时候都可能被垃圾回收器回收。这种引用,使用的少之又少,就不深讲了!(软引用、弱引用、虚引用都可以与引用队列一起使用)
 
总结:对于强引用,我们平时在编写代码时经常会用到。而对于其他三种类型的引用,使用得最多的就是软引用和弱引用,这2种既有相似之处又有区别。它们都是用来描述非必需对象的,但是被软引用关联的对象只有在内存不足时才会被回收,而被弱引用关联的对象在JVM进行垃圾回收时总会被回收。
 
②复制算法
首先将内存分为大小相等的两部分(假设A、B两部分),每次呢只使用其中的一部分(这里我们假设为A区),等这部分用完了,这时候就将这里面还能活下来的对象复制到另一部分内存(这里设为B区)中,然后把A区中的剩下部分全部清理掉。
这样一来每次清理都要对一半的内存进行回收操作,这样内存碎片的问题就解决了,可以说简单,高效。
但是呢,肯定发现了,本来挺大一片地方,现在只能用一半,搞得挺不爽的,世界上本来没有免费的饭菜,就算是用空间换取时间吧。这种算法会导致50%的内存空间始终空闲浪费!
 
③标记清除算法
步骤一:标记
第一步是标记,通过这一步骤来区分哪块内存在使用,那哪块内存未使用。
引用对象用蓝色标识,未引用的对象用金色标识。在标记阶段,扫描所有的对象并判断。如果系统中所有的对象都要被扫描的,那么这一步骤可能非常耗时。
步骤二:正常删除
正常删除移除无引用对象,留下引用对象及指向空闲空间的指针。
内存分配器持有空闲内存的引用,这些空闲内存都链接到一个List中,当需要的时候可以分配给新的对象。
 
④标记压缩算法
将上面的步骤二改为:带压缩删除
为了进一步改善性能,除了删除未引用的对象,用户也可以压缩存活的引用对象。把引用对象移动到一起,通过这种方法可以使更快速、更方便的分配新的内存。
⑤分代算法
分代算法是针对对象的不同特性,而使用适合的算法,这里面并没有实际上的新算法产生。与其说分代搜集算法是第五个算法,不如说它是对前三个算法的实际应用,在新生代使用复制算法eden在8分空间,survivor在两个1分,只浪费10%的空间空闲。 老年代使用标记清除/标记压缩算法清除。

当幸存对象的年龄到达某个值后,就会从年轻代进入老年代。
 
如果老年代内存满了,就会触发major GC或者full GC。触发full GC就会出现所谓的STW(stop the world)现象。即所有的进程都挂起等待清理垃圾。major GC是回收老年代的垃圾。Full GC是回收老年代和年轻代的垃圾。
 
3、垃圾收集器
如果说回收算法是内存回收的方法论,垃圾收集器就是内存回收的具体实现
Serial收集器
串行收集器是最古老,最稳定以及效率高的收集器,可能会产生较长的停顿,只使用一个线程去回收。新生代、老年代使用串行回收;新生代复制算法老年代标记-压缩;垃圾收集的过程中会Stop The World(服务暂停)
参数控制:-XX:+UseSerialGC 串行收集器
ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本。新生代并行,老年代串行;新生代复制算法、老年代标记-压缩
参数控制:-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制线程数量
Parallel收集器
Parallel Scavenge收集器类似ParNew收集器,Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或最大的吞吐量;也可以通过参数控制GC的时间不大于多少毫秒或者比例;新生代复制算法、老年代标记-压缩
参数控制:-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行
 
 
Parallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6中才开始提供
参数控制: -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行
 
 
 
CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。
从名字(包含“Mark Sweep”)上就可以看出CMS收集器是基于“标记-清除”算法实现的,它的运作过程相对于前面几种收集器来说要更复杂一些,整个过程分为4个步骤,包括:
初始标记(CMS initial mark)
并发标记(CMS concurrent mark)
重新标记(CMS remark)
并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象,速度很快,并发标记阶段就是进行GC Roots Tracing的过程,而重新标记阶段则是为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段稍长一些,但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程中,收集器线程都可以与用户线程一起工作,所以总体上来说,CMS收集器的内存回收过程是与用户线程一起并发地执行。CMS是老年代收集器(新生代使用ParNew)
优点:并发收集低停顿
缺点:产生大量空间碎片(因为垃圾回收期间不会移动对象实例)、并发阶段会降低吞吐量
参数控制:-XX:+UseConcMarkSweepGC 使用CMS收集器
-XX:+ UseCMSCompactAtFullCollection Full GC后,进行一次碎片整理;整理过程是独占的,会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后,进行一次碎片整理
-XX:ParallelCMSThreads 设定CMS的线程数量(一般情况约等于可用CPU数量)
 
 
 
G1收集器
G1是目前技术发展的最前沿成果之一,HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点:
1. 空间整合,G1收集器采用标记整理算法,不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
2. 可预测停顿,这是G1的另一大优势,降低停顿时间是G1和CMS的共同关注点,但G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为N毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒,这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。
上面提到的垃圾收集器,收集的范围都是整个新生代或者老年代,而G1不再是这样。使用G1收集器时,Java堆的内存布局与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔阂了,它们都是一部分(可以不连续)Region的集合。
G1的新生代收集跟ParNew类似,当新生代占用达到一定比例的时候,开始出发收集。和CMS类似,G1收集器收集老年代对象会有短暂停顿。
 
收集步骤:
1、标记阶段,首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event),并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)
2、Root Region Scanning,程序运行过程中会回收survivor区(存活到老年代),这一过程必须在young GC之前完成。
3、Concurrent Marking,在整个堆中进行并发标记(和应用程序并发执行),此过程可能被young GC中断。在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那个这个区域会被立即回收(图中打X)。同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)。
4、Remark, 再标记,会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行);G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
5、Copy/Clean up,多线程清除失活对象,会有STW。G1将回收区域的存活对象拷贝到新区域,清除Remember Sets,并发清空回收区域并把它返回到空闲区域链表中。
6、复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。
 
 
常用的收集器组合
 
新生代GC策略
年老代GC策略
说明
组合1
Serial
Serial Old
Serial和Serial Old都是单线程进行GC,特点就是GC时暂停所有应用线程。
组合2
Serial
CMS+Serial Old
CMS(Concurrent Mark Sweep)是并发GC,实现GC线程和应用线程并发工作,不需要暂停所有应用线程。另外,当CMS进行GC失败时,会自动使用Serial Old策略进行GC。
组合3
ParNew
CMS
使用-XX:+UseParNewGC选项来开启。ParNew是Serial的并行版本,可以指定GC线程数,默认GC线程数为CPU的数量。可以使用-XX:ParallelGCThreads选项指定GC的线程数。 如果指定了选项-XX:+UseConcMarkSweepGC选项,则新生代默认使用ParNew GC策略。
组合4
ParNew
Serial Old
使用-XX:+UseParNewGC选项来开启。新生代使用ParNew GC策略,年老代默认使用Serial Old GC策略。
组合5
Parallel Scavenge
Serial Old
Parallel Scavenge策略主要是关注一个可控的吞吐量:应用程序运行时间 / (应用程序运行时间 + GC时间),可见这会使得CPU的利用率尽可能的高,适用于后台持久运行的应用程序,而不适用于交互较多的应用程序。
组合6
Parallel Scavenge
Parallel Old
Parallel Old是Serial Old的并行版本
组合7
G1GC
G1GC
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC #开启 -XX:MaxGCPauseMillis =50 #暂停时间目标 -XX:GCPauseIntervalMillis =200 #暂停间隔目标 -XX:+G1YoungGenSize=512m #年轻代大小 -XX:SurvivorRatio=6 #幸存区比例
 
 
4、总结回收策略的常用配置
  -XX:+UseSerialGC
  串行(SerialGC)是jvm的默认GC方式,一般适用于小型应用和单处理器,算法比较简单,GC效率也较高,但可能会给应用带来停顿
  -XX:+UseParallelGC
  并行(ParallelGC)是指多个线程并行执行GC,一般适用于多处理器系统中,可以提高GC的效率,但算法复杂,系统消耗较大。(配合使用:-XX:ParallelGCThreads=8,并行收集器的线程数,此值最好配置与处理器数目相等)
  -XX:+UseParNewGC
  设置年轻代为并行收集,JKD5.0以上,JVM会根据系统配置自行设置,所以无需设置此值。
  -XX:+UseParallelOldGC
  设置年老代为并行收集,JKD6.0出现的参数选项。
  -XX:+UseConcMarkSweepGC
  并发(ConcMarkSweepGC)是指GC运行时,对应用程序运行几乎没有影响(也会造成停顿,不过很小而已),GC和app两者的线程在并发执行,这样可以最大限度不影响app的运行。
  -XX:+UseCMSCompactAtFullCollection
  在Full GC的时候,对老年代进行压缩整理。因为CMS是不会移动内存的,因此非常容易产生内存碎片。因此增加这个参数就可以在FullGC后对内存进行压缩整理,消除内存碎片。当然这个操作也有一定缺点,就是会增加CPU开销与GC时间,所以可以通过-XX:CMSFullGCsBeforeCompaction=3 这个参数来控制多少次Full GC以后进行一次碎片整理。
  -XX:+CMSInitiatingOccupancyFraction=80
  代表老年代使用空间达到80%后,就进行Full GC。CMS收集器在进行垃圾收集时,和应用程序一起工作,所以,不能等到老年代几乎完全被填满了再进行收集,这样会影响并发的应用线程的空间使用,从而再次触发不必要的Full GC。
posted @ 2019-10-12 14:51  Java-Legend  阅读(682)  评论(0编辑  收藏  举报