0
点赞
收藏
分享

微信扫一扫

java虚拟机学习 -- 垃圾收集器


判断对象的存活

引用计数法:快,方便,实现简单。缺点,对象相互引用时,很难判断对象是否存活

可达性分析

是用来判断对象是否存活的。这个算法的基本思路就是通过一系列的“GC Roots”的对象作为起始点,从这些节点开始向下搜索。搜索过的引用链(Reference chain),当一个对象到GC Roots没有任何引用链时,则证明此对象是不可用的。

能作为GC ROOTS的对象包括下面几种

1.虚拟机栈(栈帧中的局部变量表)中引用的对象。

2.方法区中类静态属性引用的对象。

3.方法区中常量引用的对象。

4.本地方法栈JNI)(native方法)引用的对象。

各种引用

强引用

一般指的是Object obj = new object()

软引用 SoftReference

一些有用但是非必需。用软引用关联的对象,系统将要发生OOM之前,这些对象将会被回收

弱引用

public class TestSoftRef {

public static class User{
public int id = 0;
public String name = "";
public User(int id, String name) {
super();
this.id = id;
this.name = name;
}
@Override
public String toString() {
return "User [id=" + id + ", name=" + name + "]";
}

}

public static void main(String[] args) {

User u = new User(1,"caojiulu");
SoftReference<User> userSoft = new SoftReference<>(u);
u = null;//保证new User(1,"caojiulu")这个实例只有userSoft在软引用

System.out.println(userSoft.get());
System.gc();//展示gc的时候,SoftReference不一定会被回收
System.out.println("AfterGc");
System.out.println(userSoft.get());//new User(1,"caojiulu")没有被回收
List<byte[]> list = new LinkedList<>();

try {
for(int i=0;i<100;i++) {
//User(1,"caojiulu")实例一直存在
System.out.println("********************"+userSoft.get());
list.add(new byte[1024*1024*1]);
}
} catch (Throwable e) {
//抛出了OOM异常后打印的,User(1,"caojiulu")这个实例被回收了
System.out.println("Throwable********************"+userSoft.get());
}

}
}

User [id=1, name=caojiulu]
AfterGc
User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
********************User [id=1, name=caojiulu]
Throwable********************null
 

弱引用 WeakReference

 一些有用(程度比软引用更低),用弱引用关联的对象,只能生存到下一次GC之前,不管内存够不够,都会被回收。

public class TestWeakRef {
public static class User{
public int id = 0;
public String name = "";
public User(int id, String name) {
super();
this.id = id;
this.name = name;
}
@Override
public String toString() {
return "User [id=" + id + ", name=" + name + "]";
}

}

public static void main(String[] args) {
User u = new User(1,"Caojiulu");
WeakReference<User> userWeak = new WeakReference<>(u);
u = null;
System.out.println(userWeak.get());
System.gc();
System.out.println("AfterGc");
System.out.println(userWeak.get());

}
}

User [id=1, name=Caojiulu]
AfterGc
null

虚引用 PhantomReference

又称幽灵引用,最弱,被垃圾回收收到一个通知而已。

注意:

软引用 SoftReference和弱引用 WeakReference,可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候,缓存中的内容是可以被释放的。

例如,一个程序用来处理用户提供的图片。如果将所有图片读入内存,这样虽然可以很快的打开图片,但内存空间使用巨大,一些使用较少的图片浪费内存空间,需要手动从内存中移除。如果每次打开图片都从磁盘文件中读取到内存再显示出来,虽然内存占用较少,但一些经常使用的图片每次打开都要访问磁盘,代价巨大。这个时候就可以用软引用构建缓存。

垃圾回收算法

标记-清除算法(Mark-Sweep)

java虚拟机学习 -- 垃圾收集器_软引用

算法分为“标记”和“清除”两个阶段:首先标记出需要回收的对象。再标记完成后统一回收被标记的对象。

他的问题是会产生很多不连续的内存碎片,分配大对象的时候,无法找到足够的连续内存而不得不提前触发另外的垃圾收集动作。

复制算法(Copying)

java虚拟机学习 -- 垃圾收集器_软引用_02

将可用的内存按容量划分为大小相等的两块,然后每次只使用一块。垃圾回收的时候,将存活的对象复制到另外一块上面,然后把已经使用过的清理掉。这样使得每次都是对一半的内存区域做回收。缺点也是同理,将内存缩小到原来的一半。

标记-整理算法(Mark-Compact)

java虚拟机学习 -- 垃圾收集器_垃圾收集_03

首先标记出所有需要回收的对象,标记完成后,不是直接清理掉标记的对象。而是将存活的对象都向一端移动,然后直接清理掉旁边的内存区域。

当前商业虚拟机的垃圾收集都采用“分代收集”算法。一般将java堆分为新生代和老年代。

研究表明,新生代中98%的对象都是“朝生夕死”的。所以不需要按照1:1的比例来划分内存空间。而是将内存分为一块较大的Eden区和两块较小的survivor空间,比例是8:1:1,每次使用Eden和一块survivor,当回收时,将Eden和survivor区存活的对象一次性复制到另外一个survivor区。最后清理掉Eden和刚才使用的survivor区。这样保证了每次都是只有10%的空间被浪费了。当然98%的对象只是一般场景下的数据。我们没办法保证每次只有不超过10%的对象存活。所以需要其他内存(老年代)进行分配担保。

不够用时,需要依赖其他内存(这里指老年代)进行分配担保(Handle Promotion)。

在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

java虚拟机学习 -- 垃圾收集器_老年代_04

垃圾回收器列表

新生代相关收集器

java虚拟机学习 -- 垃圾收集器_垃圾收集_05

老年代相关收集器

java虚拟机学习 -- 垃圾收集器_老年代_06

垃圾回收期里面的并发和并行

并行:垃圾收集的多线程的同时运行。

并发:垃圾收集的多线程和应用的多线程同时进行。

Serial /Serial Old

java虚拟机学习 -- 垃圾收集器_软引用_07

最古老的,单线程,独占式,成熟,适合单cpu服务器

-XX:+UserSerialGC 新生代使用Serial,老年代SerialOld

-XX:+UserParNewGC 新生代使用ParNew,老年代使用Serial Old

-XX:+UserParallelGC 新生代使用ParallelGC,老年代使用Serial Old

ParNew

java虚拟机学习 -- 垃圾收集器_垃圾收集_08

和Serial基本没区别,唯一的区别:多线程,多CPu,停顿时间比serial少

Parallel Scavenge(ParallelGC)/Praallel Old

java虚拟机学习 -- 垃圾收集器_软引用_09

关注于吞吐量的垃圾收集器,高吞吐量则可以高效率的利用Cpu时间,尽快完成程序的运算任务,主要适合在后台计算而不需要太多交互的任务里。所谓吞吐量就是Cpu用于运行用户代码的时间与Cpu总消耗时间的比值。即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%

-XX:MaxGCPauseMills  :参数允许的值是一个大于0的毫秒数,收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的:系统把新生代调小一些,收集300MB新生代肯定比收集500MB快吧,这也直接导致垃圾收集发生得更频繁一些,原来10秒收集一次、每次停顿100毫秒,现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降,但吞吐量也降下来了。

-XX:GCTimeRatio参数的值应当是一个大于0且小于100的整数,也就是垃圾收集时间占总时间的比率,相当于是吞吐量的倒数。如果把此参数设置为19,那允许的最大GC时间就占总时间的5%(即1/(1+19)),默认值为99,就是允许最大1%(即1/(1+99))的垃圾收集时间。

-XX:+UseAdaptiveSizePolicy 当这个参数打开之后,就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量,这种调节方式称为GC自适应的调节策略。

如果对于收集器运作原来不太了解,手工优化存在困难的时候,使用Parallel Scavenge收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好(如-Xmx设置最大堆),然后使用MaxGCPauseMillis参数(更关注最大停顿时间)或GCTimeRatio(更关注吞吐量)参数给虚拟机设立一个优化目标,那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

-XX:+UserParallelOldGC:新生代使用ParallelGC,老年代使用Parallel Old

Concurrent Mark Sweep (CMS)

java虚拟机学习 -- 垃圾收集器_老年代_10

收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

从名字(包含“Mark Sweep”)上就可以看出,CMS收集器是基于“标记—清除”算法实现的,它的运作过程相对于前面几种收集器来说更复杂一些,整个过程分为4个步骤,包括:

  1. 初始标记-短暂,仅仅只是标记一下GC Roots能直接关联到的对象,速度很快。
  2. 并发标记-和用户的应用程序同时进行,进行GC RootsTracing的过程
  3. 重新标记-短暂,为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段稍长一些,但远比并发标记的时间短。
  4. 并发清除

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作,所以,从总体上来说,CMS收集器的内存回收过程是与用户线程一起并发执行的。

-XX:+UseConcMarkSweepGC ,表示新生代使用ParNew,老年代的用CMS

浮动垃圾:由于CMS并发清除阶段用户线程还在运行着,伴随着程序运行自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好留待下一次GC时再清理掉。这一部分垃圾称为浮动垃圾。

同时用户的线程还在运行,需要给用户线程留下运行的内存空间。

-XX:CMSInitialOccupyFraction  ,因为以上两点,因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满再进行收集。需要预留一部分空间提供并发收集时程序运行的空间使用。在JDk早期版本的默认设置下,CMS收集器当老年代使用了68%的空间时就会被激活。这是一个偏保守的设置,如果在应用中老年代增长不是太快,可以适当提高参数-XX:CMSInitialOccupyFraction的值来提高触发百分比,以降低回收次数来提供性能。在JDK1.6中,CMS收集器的启动阈值已经提升到92%。要是CMS运行期间预留的内存无法满足内存需要,就会出现一次“Concurrent Mode Failure”失败。这时虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。所以说参数XX:CMSInitialOccupyFraction设置得太高很容易导致大量的“Concurrent Mode Failure”失败,性能反而降低。

-XX:+UseCMSCompactAtFullCollection为了解决这个问题,CMS收集器提供了一个这个开关参数(默认是开启的),用于在CMS收集器顶不住要进行FUllGC时开启内存碎片的合并整理过程,内存整理的过程是无法并发的。空间碎片问题没有了,但停顿时间不得不变长。

-XX:CMSFullGCsBeforeCompaction,这个是用于设置执行多少次不压缩的FUllGC后,跟着来一次带压缩的(默认值为0,表示每次进入FullGC时都进行碎片整理)

 

G1

java虚拟机学习 -- 垃圾收集器_垃圾收集_11

-XX:+UseG1GC

并行和并发:G1能充分利用多Cpu,多核环境下的硬件优势,使用多个Cpu(Cpu或者Cpu核心)来缩短Stop-the-world停顿的时间,部分其他收集器原本需要停顿java线程执行的GC动作,G1收集器仍然可以通过并发的方式让java程序继续执行。

分代收集:与其他收集器一样,分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间,熬过多次GC的旧对象以获取更好的收集效果。

空间整合:与CMS的标记清理算法不同,G1从整体来看是基于 标记-整理算法实现的收集器,从局部(两个Region之间)是基于“复制算法”实现的,但无论如何,这两种算法都意味着G1在运行期间不会产生内存空间碎片,收集后能提供规整的可用内存。这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续空间内存而提前触发下一次GC。

内存布局:在G1之前的其他收集器进行收集的范围都是整个新生代和老年代,而G1不再是这样。使用G1收集器时,java堆的内存布局就与其他收集器有很大差别,他讲整个java堆划分为多个大小相等的独立区域(Region)。虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离,它们都是一部分region(不需要连续)的集合。

新生代GC

回收eden区和survivor区,回收后,所有的eden区被清空,存在一个survivor区保存了部分数据。老年代区域会增多,因为部分新生代的对象会晋升到老年代。

并发标记周期

java虚拟机学习 -- 垃圾收集器_老年代_12

初始标记:短暂,仅仅只是标记一下GC roots能直接关联到的对象,速度很快,产生一个全局停顿,都伴随有一个新生代的GC

根区域扫描:扫描survivor区可以直接到达的老年代区域。

并发标记阶段:扫描和查找整个堆的存活对象,并标记。

重新标记:会产生全局停顿,对并发标记阶段的结果进行修正。

独占清理:会产生全局停顿,对GC回收比例进行排序,供混合收集阶段使用

并发清理:识别并清理完全空闲的区域,并发进行

混合收集

对含有垃圾比例较高的region进行回收

G1当出现内存不足的情况,也可能进行的FullGC回收。

G1重要的参数:

-XX:MaxGCPauseMillis 指定目标的最大停顿时间,G1尝试调整新生代和老年代的比例,堆大小,晋升年龄来达到这个目标时间。

-XX:ParallerGCThreads:设置GC的工作线程数量

未来的垃圾回收

ZGC通过技术手段把stw的情况控制在仅有一次,就是第一次的初始标记才会发生,这样也就不难理解为什么GC停顿时间不随着堆增大而上升了,再大我也是通过并发的时间去回收了

关键技术

  1. 有色指针(Colored Pointers)
  2. 加载屏障(Load Barrier)

Stop The World现象

 

举报

相关推荐

0 条评论