Java内存区域运行时,程序计数器、虚拟机栈、本地方法栈随线程而生,随线程而灭;栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作,每一个栈帧中分配多少内存在类结构确定下来时(编译期)大体上是已知的。方法结束或者线程结束时,内存自然就回收了,所以这几个区域就不需要过多考虑内存分配和回收的问题。而Java堆和方法区就不一样,我们只有在程序处于运行期间才知道会需要多少内存,这部分的内存分配和回收都是动态的,GC收集器所关注的就是这部分内存。
1、哪些对象需要回收
在堆里面存放着Java世界中几乎所有的对象实例,垃圾收集器在对堆进行回收前,第一件事情就是要确定这些对象之中哪些还“存活”着,哪些已经“死去”(即不可能再被任何途径使用的对象)。
1.1、引用计数算法
给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1:当引用失效时,计数器值就减1:任何时刻计数器为0的对象就是不可能再被使用的。引用计数算法(Reference Counting)的实现简单,判定效率也很高,在大部分情况下它都是一个不错的算法。但是,至少主流的Java虚拟机里面没有选用引用计数算法来管理内存,其中最主要的原因是它很难解决对象之间相互循环引用的问题。
举个简单的例子,假设对象objA和objB都有字段instance,赋值令 objA.instance=objB及 objB.instance=objA,除此之外,这两个对象再无任何引用,实际上这两个对象已经不可能再被访问,但是它们因为互相引用着对方,导致它们的号用计数都不为0,于是引用计数算法无法通知GC收集器回收它们。
1.2、可达性分析算法
在主流的商用程序语言的主流实现中,都是称通过可达性分析(Reachability Analysis)来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说,就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。如图所示,对象object5、object6、object7虽然互相有关联,但是它们到 GC-Roots是不可达的,所以它们将会被判定为是可回收的对象。
在Java语言中,可作为GC Roots的对象包括下面几种:
- 在虚拟机栈(栈帧中的本地变量表)中引用的对象,譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
- 在方法区中类静态属性引用的对象,譬如Java类的引用类型静态变量。
- 在方法区中常量引用的对象,譬如字符串常量池(StringTable)里的引用。
- 在本地方法栈中JNI(即通常所说的Native方法)引用的对象。
- Java虚拟机内部的引用,如基本数据类型对应的Class对象,一些常驻的异常对象(比如NullPointExcepiton、OutOfMemoryError)等,还有系统类加载器。
- 所有被同步锁(synchronized关键字)持有的对象。
- 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
1.3、对象的引用
无论是通过引用计数算法判断对象的引用数量,还是通过可达性分析算法判断对象的引用链是否可达,判定对象是否存活都与“引用”有关。在JDK1.2以前,Java中的引用的定义很传统:如果 reference类型的数据中存储的数值代表的是另外一块内存的起始地址,就称这块内存代表着一个引用。这种定义很纯粹,但是太过狭隘,一个对象在这种定义下只有被引用或者没有被引用两种状态,对于如何描述一些“食之无味,弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象:当内存空间还足够时,则能保留在内存之中;如果内存空间在进行垃圾收集后还是非常紧张,则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。
在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)。这4种引用强度依次减弱,具体参考【Java基础】强引用,软引用,弱引用,虚引用_通往神秘的道路的专栏-CSDN博客。
1.4、finalize() 方法
即使在可达性分析算法中不可达的对象,也并非是“非死不可”的,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:
- 如果对象在进行可达性分析后发现没有与 GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行 finalize方法。当对象没有覆盖 finalize方法,或者 finalize方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”,对象被回收。
- 如果这个对象被判定为有必要执行finalized方法,那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样做的原因是,如果一个对象在 finalize方法中执行缓慢,或者发生了死循环(更极端的情况),将很可能会导致F-Queue队列中其他对象永久处于等待,甚至导致整个内存回收系统崩溃。 finalize方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F- Queue中的对象进行第二次小规模的标记,如果对象要在 finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。
另外一个值得注意的地方是,任何一个对象的 finalize方法都只会被系统自动调用一次,如果对象面临下一次回收,它的 finalize方法不会被再次执行。
1.5、回收方法区
Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区中进行垃圾收集的“性价比”一般比较低:在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收70%~95%的空间,相比之下,方法区回收囿于苛刻的判定条件,其区域垃圾收集的回收成果往往远低于此。
方法区的垃圾收集主要回收两部分内容:废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个 String对象是叫做“abc”的,换句话说,就是没有任何 String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果这时发生内存回收,而且必要的话,这个“abc”常量就会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
判定一个常量是否是“废弃常量”比较简单,而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”:
- 该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例。
- 加载该类的 ClassLoader已经被回收,这个条件除非是经过精心设计的可替换类加载器的场景,如OSGi、JSP的重加载等,否则通常是很难达成的。
- 该类对应的 java.lang.Class象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
2、垃圾收集算法
2.1、分代收集理论
部分收集( Partial GC ):指目标不是完整收集整个 Java 堆的垃圾收集,其中又分为:■ 新生代收集( Minor GC/Young GC ):指目标只是新生代的垃圾收集。■ 老年代收集( Major GC/Old GC ):指目标只是老年代的垃圾收集。目前只有 CMS收集器会有单独收集老年代的行为。另外请注意 “Major GC”这个说法现在有点混淆,在不同资料上常有不同所指读者需按上下文区分到底是指老年代的收集还是整堆收集。■ 混合收集( Mixed GC ):指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有 G1收集器会有这种行为。整堆收集( Full GC ):收集整个 Java 堆和方法区的垃圾收集。
[1] 值得注意的是,分代收集理论也有其缺陷,最新出现(或在实验中)的几款垃圾收集器都展现出了面向全区域收集设计的思想,或者可以支持全区域不分代的收集的工作模式。[2] 新生代( Young )、老年代( Old )是 HotSpot 虚拟机,也是现在业界主流的命名方式。在 IBM J9虚拟机中对应称为婴儿区( Nursery )和长存区( Tenured ),名字不同但其含义是一样的。[3] 通常能单独发生收集行为的只是新生代,所以这里 “ 反过来 ”的情况只是理论上允许,实际上除了CMS 收集器,其他都不存在只针对老年代的收集。
2.2、标记-清除算法
最基础的收集算法是“标记-清除(Mark-Sweep)”算法。算法分为“标记”和“清除”两个阶段:标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象,也可以反过来,标记存活的对象,统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。
它的主要不足有两个:第一个是执行效率不稳定,如果Java堆中包含大量对象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除的动作,导致标记和清除两个过程的执行效率都随对象数量增长而降低;第二个是内存空间的碎片化问题,标记、清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.3、标记-复制算法
标记-复制算法常被简称为复制算法。为了解决效率问题,一种称为“复制(Copying)”的收集算法出现了。它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针按顺序分配内存即可,简单高效。它的不足,简而言之就是拿空间换时间,将内存缩小为了原来的一半,这代价未免太高了。
现在主流的商业JVM都采用这种收集算法来回收新生代,新生代中的对象98%是“朝生夕死”的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块儿较大的Eden空间和两块较小的Surivior空间,每次使用Eden和其中一块Survivor空间。当需要内存回收时,将Eden和Survivor中还活着的对象一次性的复制到另一块Survivor空间上,最后清理掉Eden和刚才使用过的Survivor空间。Hotspot VM默认的Eden和Survivor的大小比例是8:1,也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的内存会被“浪费”。
当然,98%的对象可回收只是在一般场景下,我们没有办法保证每次回收都只有不多于10%的对象存活,但Survivor空间不够用时,需要依赖其他内存(例如老年代)进行分配担保。内存的分配担保的意思是,如果另外一块Surivior没有足够空间存放上一次新生代收集下来的存活对象时,这些对象将直接通过分配担保机制进入老年代。
2.4、标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。更关键的是,如果不想浪费掉50%的空间,就需要有额外的空间进行分配担保,以应对被使用的内存中所有对象都100%存活的极端情况,所以在老年代中一般不直接选用这种算法。
根据老年代的特点,新的“标记-整理(Mark-Compact)”算法出现了,标记过程仍然与“标记-清除”算法一样,但后续步骤并不直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
[1] 最新的 ZGC 和 Shenandoah 收集器使用读屏障( Read Barrier)技术实现了整理过程与用户线程的并发执行,稍后将会介绍这种收集器的工作原理。[2] 通常标记 -清除算法也是需要停顿用户线程来标记、清理可回收对象的,只是停顿时间相对而言要来的短而已。