《深入理解Java虚拟机》——垃圾收集器与内存分配策略
GC需要完成:
- 哪些内存需要回收
- 什么时候回收
- 如何回收
如何确定对象不再使用
- 引用计数算法
给对象添加一个引用计数器,当有一个地方引用它时,计数器值进行加1操作;当引用失效时,计数器值进行减1操作;当计数器值为0,则说明对象不可能再被使用。但是它无法解决循环引用的问题。
public class ReferenceCountingGC {
public Object instance = null;
public static void testGC(){
ReferenceCountingGC objA = new ReferenceCountingGC ();
ReferenceCountingGC objB = new ReferenceCountingGC ();
// 对象之间相互循环引用,对象objA和objB之间的引用计数永远不可能为 0
objB.instance = objA;
objA.instance = objB;
objA = null;
objB = null;
System.gc();
}
}
上述代码最后面两句将objA和objB赋值为null,也就是说objA和objB指向的对象已经不可能再被访问,但是由于它们互相引用对方,导致它们的引用计数器都不为 0,那么垃圾收集器就永远不会回收它们。(目前主流的Java虚拟机没有选用引用计数法来管理内存,主要原因也就是因为无法解决循环引用的问题)
- 可达性分析算法
通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。如下图,对象Object5、Object6、Object7虽然互相有所关联,但是它们到GC Roots是不可达的,因此将它们判定为可回收的对象。
在Java语言中,可作为GC Roots的对象包括:- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI(即一般说的Native方法)引用的对象。
关于引用
无论是通过引用计数算法还是可达性分析算法,判断对象是否存活都与“引用”有关。
宣告一个对象真正失效,至少要经历两次标记过程,如果对象在进行可达性分析后发现没有与 GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize() 方法,当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”。
关于Java中的引用:
- 强引用:程序代码中普遍存在,类似“Object obj = new Object()”这类的引用,只要强引用还存在,垃圾收集器永远不会回收掉被引用的对象。
- 软引用:用来描述一些还有用但并非必需的对象。对于软引用关联的对象,在系统将要发生内存溢出异常之前,将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存,才会抛出内存溢出异常。在JDK 1.2之后,提供了SoftReference类来实现软引用。
- 弱引用:用来描述非必需对象,强度比软引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用挂链的对象。在JDK 1.2之后,提供了WeakReference类来实现弱引用。
- 虚引用:也称为幽灵引用或者幻影引用,它是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2之后,提供了PhantomReference类来实现虚引用。
永久代的垃圾收集主要回收两部分内容:废弃常量和无用的类。相较于废弃常量,判定一个类是否是“无用的类”的条件则相对苛刻很多,类需要同时满足下面三个条件:(不满足一定不回收,满足不一定回收,区别于对象无效就回收)
- 该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法
垃圾收集算法
-
标记-清除(Mark-Sweep)算法
首先标记出所有需要回收的对象,在标记完成之后统一回收所有被标记的对象。标记过程就是使用引用计数法或可达性分析进行标记。
不足:- 效率问题:标记和清除两个过程的效率都不高
- 空间问题:标记清除之后会产生大量不连续的内存碎片,空间碎片太多导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
-
复制算法
将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用的内存空间一次清理掉。当然,这种算法的代价是将内存缩小为原来的一半,代价未免过高了一点。而IBM公司经过专门研究,表明新生代的对象98%是“朝生夕死”的,所以并不需要按照1:1的比例划分内存空间,而是将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor,当回收时,将Eden和Survivor中还存活着的对象一次性地赋值到另一块Survivor空间上,然后清理Eden和刚才用过的Survivor空间。其比例大小默认是为8:1:1,也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%)。
-
标记-整理算法
标记过程仍然与“标记-清除”算法一样,但后续步骤不再直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
-
分代收集算法
根据对象存活周期的不同将内存划分为几块,一般把Java堆分为新生代和老年代,根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那么就选用复制算法,而老年代中因为对象存活率高、没有额外空间对它进行分配担保,必须使用“标记-清理”或者“标记-整理”算法来进行回收。
垃圾收集器
并行(Parallel):指多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态
并发(Concurrent):指用户线程与垃圾收集线程同事执行(但不一定是并行的,可能会交替执行),用户程序在继续运行,而垃圾收集程序运行于另一个CPU上。
如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。图示展示了7种用于不同分代的收集器,如果两个收集器之间存在连线,就说明它们可以搭配使用。虚拟机所处的区域,则表示它是属于新生代收集器还是老年代收集器。
-
Serial收集器
Serial收集器是最基本、发展最悠久的收集器,在JDK 1.3.1之前是虚拟机新生代收集的唯一选择。这个收集器是一个单线程的收集器,其不仅仅只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。”Stop The World"这项工作实际上是由虚拟机在后台自动发起和自动完成的,在用户不可见的情况下把用户正常工作的线程全部停掉。尽管由于“Stop The World”带来很差的用户体验,但实际上到目前为止,它仍然是虚拟机运行在Client模式下的默认新生代收集器。在用户的桌面应用场景中,分配给虚拟机管理的内存一般来说并不会很大,收集几十兆甚至一两百兆的新生代,停顿时间完全可以控制在几十毫秒最多一百多毫秒以内。
-
ParNew收集器
Serial收集器的多线程版本,除了使用多条线程进行垃圾收集之外,其余行为与Serial收集器完全一样。由于目前只有Serial收集器和ParNew收集器能与CMS收集器配合工作,因此许多运行在Server模式下的虚拟机中首选ParNew收集器作为新生代收集器。对于单CPU环境,ParNew收集器不会有比Serial收集器更好的效果,甚至由于存在交互的开销,该收集器在通过超线程技术实现的两个CPU的环境中都不能百分百地保证可以超越Serial收集器。
-
Parallel Scavenge收集器
新生代收集器,使用复制算法的并行多线程收集器。其特点在于区别于CMS等收集器的尽可能缩短垃圾收集时用户线程的停顿时间,它的目标是达到一个可控制的吞吐量。高吞吐量可以高效率地利用CPU时间。Parallel Scavenge收集器提供两个参数用于精确控制吞吐量:-XX:MaxVIPauseMillis(控制最大垃圾收集停顿时间),-XX:GCTimeRatio(直接设置吞吐量的大小)。对于MaxGCPauseMillis参数(大于0的毫秒数),收集器尽可能的保证内存回收花费的时间不超过设定值,但并非设置得越小越好,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。
-
Serial Old收集器
Serial Old是Serial收集器的老年代版本,同样是一个单线程收集器,使用“标记-整理”算法。 -
Paralle Old收集器
Paralle Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。在此之前,Parallel Scavenge收集器与Serial Old配合使用(无法与CMS配合使用),但Serial Old在服务端没有较好的性能,直到Parallel Old出现,“吞吐量优先”收集器才有了比较名副其实的应用组合。 -
CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器基于“标记-清除”算法实现,整个过程分为4个步骤,包括- 初始标记(CMS initial mark):需要“Stop The World“,标记GC Roots能直接关联到的对象,速度很快
- 并发标记(CMS concurrent mark):进行GC Roots Tracing的过程
- 重新标记(CMS remark):修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般比初始标记阶段稍长,但远比并发标记的时间短
- 并发清除(CMS concurrent sweep):
CMS收集器无法处理浮动垃圾(Floating Garbage),可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生,另外CMS是一款基于“标记-清楚”算法实现的收集器,这意味着收集结束时会有大量碎片产生。空间碎片过多,将会给大对象分配带来很大的麻烦,往往会出现老年代还有很大空间剩余,但是无法找到足够大的连续空间来分配当前对象,不得不提前触发一次Full GC。
-
G1收集器
G1(Garbage-First)收集器是当今收集器技术发展的最新前沿技术之一,其具有如下特点: -
并行与并发:G1能充分利用多CPU、多核环境下的硬件优势,来缩短“Stop The World”的时间,在执行GC动作,G1收集器可以通过并发的方式让Java程序继续执行。
-
分代收集:分代概念在G1中依然得以保留,G1可以不需要其他收集器配合就能独立管理整个GC堆。
-
空间整合:G1从整体来看是基于“标记-整理”算法实现的,从局部来看是基于“复制”算法实现的。
-
可预测的停顿:G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒。
内存分配与回收策略
在 Java 中,堆被划分成两个不同的区域:新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被划分为三个区域:Eden、From Survivor、To Survivor。 这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象,包括内存的分配以及回收。 堆的内存模型大致为:
从图中可以看出: 堆大小 = 新生代 + 老年代。其中,堆的大小可以通过参数 –Xms、-Xmx 来指定。 默认的,新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 ),即:新生代 ( Young ) = 1/3 的堆空间大小。老年代 ( Old ) = 2/3 的堆空间大小。其中,新生代 ( Young ) 被细分为 Eden 和 两个 Survivor 区域,这两个 Survivor 区域分别被命名为 from 和 to,以示区分。
默认的,Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 ),即: Eden = 8/10 的新生代空间大小,from = to = 1/10 的新生代空间大小。 JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务,所以无论什么时候,总是有一块 Survivor 区域是空闲着的。因此,新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。
新生代GC(Minor GC):指发生在新生代的垃圾收集动作,因为Java对象大多都具备朝生夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快
老年代GC(Major GC/Full GC):指发生在老年代的GC,出现Major GC,经常会伴随至少一次的Minor GC(但分绝对,在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。
- 对象优先在Eden分配
大多数情况,对象在新生代Eden区中分配,当Eden区没有足够空间进行分配时,虚拟机发起一次MinorGC。 - 大对象直接进入老年代
所谓大对象指需要大量连续内存空间的Java对象,最典型的大对象就是长的字符串和数组。虚拟机提供了一个-XX:PretenureSizeThreshold
参数,令大于这个设置值的对象直接在老年代分配,这样能避免在Eden区及两个Survivor区之间发生大量的内存复制。 - 长期存活的对象将进入老年代
虚拟机给每个对象定义了一个对象年龄计数器,如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能被Survivor容纳,将被移动到Survivor空间中,并且对象年龄设为1。对象在Survivor区中每熬过一次Minor GC,年龄就增加一岁,当它的年龄增加到一定程度(默认15岁),就会晋升到老年代。另外,可根据-XX:MaxTenuringThreshold
设置年龄阈值。 - 动态对象年龄判定
晋升老年代不一定需要年龄达到MaxTenuringThreshold,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。
┆ 凉 ┆ 暖 ┆ 降 ┆ 等 ┆ 幸 ┆ 我 ┆ 我 ┆ 里 ┆ 将 ┆ ┆ 可 ┆ 有 ┆ 谦 ┆ 戮 ┆ 那 ┆ ┆ 大 ┆ ┆ 始 ┆ 然 ┆
┆ 薄 ┆ 一 ┆ 临 ┆ 你 ┆ 的 ┆ 还 ┆ 没 ┆ ┆ 来 ┆ ┆ 是 ┆ 来 ┆ 逊 ┆ 没 ┆ 些 ┆ ┆ 雁 ┆ ┆ 终 ┆ 而 ┆
┆ ┆ 暖 ┆ ┆ 如 ┆ 地 ┆ 站 ┆ 有 ┆ ┆ 也 ┆ ┆ 我 ┆ ┆ 的 ┆ 有 ┆ 精 ┆ ┆ 也 ┆ ┆ 没 ┆ 你 ┆
┆ ┆ 这 ┆ ┆ 试 ┆ 方 ┆ 在 ┆ 逃 ┆ ┆ 会 ┆ ┆ 在 ┆ ┆ 清 ┆ 来 ┆ 准 ┆ ┆ 没 ┆ ┆ 有 ┆ 没 ┆
┆ ┆ 生 ┆ ┆ 探 ┆ ┆ 最 ┆ 避 ┆ ┆ 在 ┆ ┆ 这 ┆ ┆ 晨 ┆ ┆ 的 ┆ ┆ 有 ┆ ┆ 来 ┆ 有 ┆
┆ ┆ 之 ┆ ┆ 般 ┆ ┆ 不 ┆ ┆ ┆ 这 ┆ ┆ 里 ┆ ┆ 没 ┆ ┆ 杀 ┆ ┆ 来 ┆ ┆ ┆ 来 ┆