JVM知识点扫盲系列(2)

JVM知识点扫盲系列(2)

JVM的堆内存实现为什么采用分代思想?

每次被小伙伴问到这种空洞的问题,简直头皮发麻,每次的草草解释,感觉都是苍白无力的语言,词穷的我只能和他们说,算法是慢慢优化,并演化过来的...

先来点专业的知识:1960年,McCarthy和Collins发表了第一篇有关自动动态内存管理(垃圾回收)的论文,而垃圾回收机制最早诞生于1958年的Lisp古老语言。垃圾回收的出现,给软件开发带来的众多收益,大大消除了开发过程中的几大类错误,比如尝试对悬挂指针进行解引用,对已经释放的内存进行二次释放等。

如果没有采用分代思想实现内存,会怎么样?

首先应该知道,新创建的对象都在堆上分配内存,每次垃圾回收,先标记出那些存活的对象(或者是垃圾对象),这时可以采取多种方式进行后续处理。

1、清空垃圾对象,保留存活对象。

这种方式,不会涉及对象复制,应该效率还不错,但是存在致命的问题,可能发生GC几次之后,就出现大量的内存碎片,而这些碎片已经小到不足以分配任何对象。

2、移动存活对象。

这种方式,需要把这些对象移动到内存的一端,可以完美解决内存碎片问题,但是,对于长期活跃的对象,每次GC都要进行移动,特别是对于大对象来说,这个效率实在可怕。

有一个"弱分代假说",weak generational hypothesis,大概含义是:大多数对象都在年轻的时候死亡,而且这个假说已经在各种不同类型的编程语言中得到证实。因此可以利用这一特性,尽量的提高回收效益(回收之后所得的空间),同时减小回收时的时间开销,这里就需要对第二种方式进行适当的改进,对于一些长期活跃的对象,甚至大对象来说,应该尽量的减少他们被复制的次数,其实就是避免每次垃圾回收都进行复制。

所以,这里很巧妙的引入了分代思想,把整个内存堆分成两块区域,即新生代和老年代。

img

上图就是HotSpot虚拟机的具体算法实现了,对新生代进行了更细的划分,分成Eden区和2个Survivor,新创建的小对象直接在Eden进行分配,大对象可以选择在老年代进行分配(这样可以有效的防止在YGC的时候进行移动)。

当Eden分配满了之后,就会触发我们熟悉的YGC进行垃圾回收,先标记存活对象,再复制到其中一个Survivor区,如果Survivor区装不下存活对象,那说明JVM参数设置的不太合理,因为Eden区和2个Survivor的默认比例是8:1:1,但是我看到过,有同学竟然在线上环境设置了22:1:1,这个比例实在有点偏激,因为Survivor装不下的对象,会被提前放入老年,会导致老年代提早被用完。

使用这种方式,如果一个对象经历了多次YGC(默认是15次,但是这个值是动态变化的),依然还是存活的,我们就可以粗暴的认为这个对象已经不再年轻,可以进入老年代进行养老了,在之后的YGC,这些对象就不会再参与复制了,有效的避免了上面提到的问题。

其实采用了分代之后,会引入另外一个问题,因为YGC算法只对新生代进行垃圾回收,但是老年代也有被用完的时候,也需要一个对应的垃圾回收算法,很明显,整体的算法复杂度上升了不止一点点,而且为了能够找出新生代全部的存活对象,还需要维护对象之间的跨代的引用,不过相对于分代回收所带来的收益相比,这一开销是值得的。

如何设计分代垃圾回收器,同时达到高吞吐量和低耗时,是一门长期而又精妙的艺术。

你可能感兴趣的:(JVM知识点扫盲系列(2))