上一次咱们已经介绍了Java内存模型,今天来简单介绍一下Java的垃圾回收机制。java
Java 的自动内存管理主要是针对对象内存的回收和对象内存的分配。同时,Java 自动内存管理最核心的功能是堆内存中对象的分配与回收。git
Java 堆是垃圾收集器管理的主要区域,所以也被称做GC 堆(Garbage Collected Heap)。github
- 对象优先在eden区分配
- 大对象直接进入老年代
- 长期存活的对象将进入老年代
对象优先在eden区分配
目前主流的垃圾收集器都会采用分代回收算法,所以须要将堆内存分为新生代和老年代,这样咱们就能够根据各个年代的特色选择合适的垃圾收集算法。算法
大多数状况下,对象在新生代中eden区分配。当eden区没有足够空间进行分配时,虚拟机将发起一次 Minor GC.segmentfault
咱们先来看看 Minor GC 和 Full GC 有什么不一样呢?数组
大对象直接进入老年代
大对象就是须要大量连续内存空间的对象(好比:字符串、数组)。服务器
为何要这样呢?
这样作的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。多线程
长期存活的对象将进入老年代
既然虚拟机采用了分代收集的思想来管理内存,那么内存回收时就必须能识别哪些对象应放在新生代,哪些对象应放在老年代中。为了作到这一点,虚拟机给每一个对象一个对象年龄(Age)计数器。闭包
若是对象在 Eden 出生并通过第一次 Minor GC 后仍然可以存活,而且能被 Survivor 容纳的话,将被移动到 Survivor 空间中,并将对象年龄设为 1.对象在 Survivor 中每熬过一次 MinorGC,年龄就增长 1岁,当它的年龄增长到必定程度(默认为 15 岁),就会被晋升到老年代中。对象晋升到老年代的年龄阈值,能够经过参数-XX:MaxTenuringThreshold
来设置。并发
注意:为了更好的适应不一样程序的内存状况,虚拟机不是永远要求对象年龄必须达到了某个值才能进入老年代, 若是 Survivor 空间中相同年龄对象大小的总和大于 Survivor 空间的一半,年龄大于或等于该年龄的对象就能够直接进入老年代,无需达到要求的年龄。
堆中几乎放着全部的对象实例,对堆垃圾回收前的第一步就是要判断那些对象已经死亡(即不能再被任何途径使用的对象)。
引用计数法
给对象中添加一个引用计数器,每当有一个地方引用它,计数器就加 1;当引用失效,计数器就减 1;任什么时候候计数器为 0 的对象就是不可能再被使用的。
这个方法实现简单,效率高,可是目前主流的虚拟机中并无选择这个算法来管理内存,其最主要的缘由是它很难解决对象之间相互循环引用的问题。
可达性分析算法
这个算法的基本思想就是经过一系列的称为 “GC Roots” 的对象做为起点,从这些节点开始向下搜索,节点所走过的路径称为引用链,当一个对象到 GC Roots 没有任何引用链相连的话,则证实此对象是不可用的。
目前垃圾收集算法有如下几种:
- 标记-清除算法
- 复制算法
- 标记-整理算法
- 分代收集算法
标记-清除算法
该算法分为“标记”和“清除”阶段:首先标记出全部须要回收的对象,在标记完成后统一回收全部被标记的对象。它是最基础的收集算法,后续的算法都是对其不足进行改进获得。这种垃圾收集算法会带来两个明显的问题:
复制算法
为了解决效率问题,“复制”收集算法出现了。它能够将内存分为大小相同的两块,每次使用其中的一块。当这一块的内存使用完后,就将还存活的对象复制到另外一块去,而后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
标记-整理算法
根据老年代的特色提出的一种标记算法,标记过程仍然与“标记-清除”算法同样,但后续步骤不是直接对可回收对象回收,而是让全部存活的对象向一端移动,而后直接清理掉端边界之外的内存。
分代收集算法
当前虚拟机的垃圾收集都采用分代收集算法,这种算法没有什么新的思想,只是根据对象存活周期的不一样将内存分为几块。通常将 java 堆分为新生代和老年代,这样咱们就能够根据各个年代的特色选择合适的垃圾收集算法。
好比在新生代中,每次收集都会有大量对象死去,因此能够选择复制算法,只须要付出少许对象的复制成本就能够完成每次垃圾收集。而老年代的对象存活概率是比较高的,并且没有额外的空间对它进行分配担保,因此咱们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
若是说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。
接下来咱们来了解一下各类垃圾收集器,这样才能根据具体应用场景选择适合本身的垃圾收集器。
Serial收集器
Serial(串行)回收器收集器是最基本、历史最悠久的垃圾收集器了。你们看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不只仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工做,更重要的是它在进行垃圾收集工做的时候必须暂停其余全部的工做线程,直到它收集结束。
新生代采用复制算法,老年代采用标记-整理算法。
ParNew收集器
ParNew 收集器其实就是 Serial 收集器的多线程版本,除了使用多线程进行垃圾收集外,其他行为(控制参数、收集算法、回收策略等等)和 Serial 收集器彻底同样。
Parallel Scavenge收集器
Parallel Scavenge 收集器也是使用复制算法的多线程收集器,它看上去几乎和ParNew都同样。
Parallel Scavenge 收集器关注点是吞吐量(高效率的利用 CPU)。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间(提升用户体验)。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。
新生代采用复制算法,老年代采用标记-整理算法。
Serial Old收集器
Serial 收集器的老年代版本,它一样是一个单线程收集器。它主要有两大用途:一种用途是在 JDK1.5 以及之前的版本中与 Parallel Scavenge 收集器搭配使用,另外一种用途是做为 CMS 收集器的后备方案。
Parallel Old收集器
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合,均可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它很是符合在注重用户体验的应用上使用。
CMS(Concurrent Mark Sweep)收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程(基本上)同时工做。
CMS 收集器是一种“标记-清除”算法实现的,它的运做过程相比于前面几种垃圾收集器来讲更加复杂一些。整个过程分为四个步骤:
从它的名字就能够看出它是一款优秀的垃圾收集器,主要优势:并发收集、低停顿。可是它有下面三个明显的缺点:
G1收集器
G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高几率知足 GC 停顿时间要求的同时,还具有高吞吐量性能特征.
被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具有一下特色:
G1 收集器的运做大体分为如下几个步骤:
G1 收集器在后台维护了一个优先列表,每次根据容许的收集时间,优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)。这种使用 Region 划份内存空间以及有优先级的区域回收方式,保证了 GF 收集器在有限时间内能够尽量高的收集效率(把内存化整为零)。