深入理解Java虚拟机 - 第三章
第三章 垃圾收集器与内存分配策略
概述
垃圾收集（Garbage Collection , GC）的历史远远比Java久远。它需要完成三件事：
- 哪些内存需要回收
- 什么时候回收
- 如何回收
程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作，每一个栈帧需要分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但是大体上可以认为是编译器可知的），因此在这几个区域的内存分配和回收都具有确定性，这几个区域不太需要过多地考虑回收的问题。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分的内存分配和回收都是动态的，垃圾收集器需要关注的是这部分内存，我们所讨论的“内存”分配与回收也仅仅指着一部分。
对象已死？
堆中存放着Java世界中几乎所有的对象，垃圾收集器在对堆进行回收前，第一件事就是要确定哪些对象还“存活着”，哪些已经“死去”（即不可能再被任何途径使用的对象）。
引用计数算法
引用计数算法（Reference Counting）：给对象添加一个引用计数器，每当有一个地方引用它时，计数器的数值就加1；当引用失效时，计数器数值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。
实际上，Java并没有采用引用计数算法，因为它很难解决对象之间的相互循环引用的问题。
根搜索算法
在主流的商业程序语言中（Java和C#），都是使用根搜索算法（GC Roots Tracing）来判定对象是否存活的。
这个算法的基本思路是：通过一系列的名字为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链对象相连（用图论的话说，就是从GC Roots到这个对象不可到达）时，则证明此对象不可用。
如下图示：
对象object5、object6和object7虽然互相关联，但是他们到GC Roots是不可到达的，所以它们会被判定为师可回收对象。
在Java中，可以作为GC Roots的对象有以下几种：虚拟机栈（栈中的本地变量表）中的引用的对象
方法区中的类静态属性引用的对象
方法区中的常量引用的对象
本地方法栈中JNI（即一般说的Native方法）的引用的对象
再谈引用
在JDK1.2之前，Java中的引用（Reference）非常狭隘：
如果Reference类型的数据中存储的数值代表着另一块内存的起始地址，就称这块内存代表着一个引用。
在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。这四种引用强度依次减弱。
- 强引用，就是在程序代码中普遍存在的，类似
Object obj = new Object()这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象。 - 软引用，用来描述一些还有用，但是并非必需的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象放进回收范围之中并进行第二次的回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
- 弱引用，也是用来描述非必需对象的，但是它的强度要比软引用弱一些，被弱引用关联的对象只能生存到下一次垃圾回收之前。当垃圾回收器工作时，不论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference来实现弱引用。
- 虚引用，也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不影响其生存时间，也无法通过虚引用来获取一个对象的实例。为一个对象设置虚引用的唯一目的就是希望这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。
生存还是死亡？
在根搜索算法不可达的对象，也并非是“非死不可”的，它们暂时处于“死缓”状态，要真正宣告对象的死亡，至少要经历两次标记：
如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它就会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。
如果这个对象被判定为有必要执行finalize()方法，那么这个对象就会被放在名为F-Queue的队列中，并在稍后有一条由虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所说的“执行”是指虚拟机会触发这个方法，但是并不承诺会保证等待它运行结束。（这样做的目的是，如果一个对象在finalize()方法中执行缓慢或者是发生了死循环，将可能会导致F-Queue里的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃）。
finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize()方法中成功拯救自己，只要重新与引用链上的任何对象建立关联即可，譬如把自己（this关键字）复制给某个类变量或者对象的成员变量。
回收方法区
Java虚拟机规范不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般都比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可回收70%～95%的空间，而永久代的垃圾收集效率远低于此。
永久代的垃圾收集主要分为两部分内容：废弃常量和无用的类。
回收废弃常量与回收Java堆中的对象非常类似，假如一个字符串“abc”已经进入常量池，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说就是没有任何对象引用常量池的“abc”常量，也没有其他地方引用了这个字面量，如果这时候发生内存回收，而且有必要的话，这个“abc”就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
类需要同时满足以下三个条件，才能算是“无用的”类：
- 该类所有的实例都被回收，也就是说Java堆中已经不存在该类的所有实例。
- 加载该类的ClassLoader已经被回收
- 该类对应的
java.lang.class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
虚拟机在一个类同时满足以上三个条件时，可以对这个无用类进行回收。（ 这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收）。HotSpot虚拟机提供了 -Xnoclassgc 参数来进行控制，还可以使用 -verbose:class , -XX:+TraceClassLoading , -XX:+TraceClassUnLoading 查看类的加载和卸载信息。
在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
垃圾收集算法
垃圾收集算法涉及到大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此本节着重介绍几种算法的思想和发展过程。
标记-清除算法
标记-清除（Mark-Sweep）算法，分为两个部分标记和清除，首先标记出所有需要回收的对象，在标记完成之后统一回收掉所有被标记的对象。
它是最基础的算法，是因为后续的算法都是基于这种思路并对其缺点进行改进而得到的。
它的主要缺点有两个：
1, 效率问题，标记或清除过程的效率都不高；
2, 空间问题，标记清除之后会产生大量的不连续的空间碎片，在以后需要分配大对象时无法找到足够的连续内存空间而不得不进行一次另一次垃圾清理。
复制算法
复制（Copying）算法的出现是为了解决“标记-清除算法”的效率问题，它将可用内存按照容量划分为大小相等的两块，每次只使用其中一块。当这一块内存使用完了，就将还存活着对象复制到另外一块上面，然后再将已使用过的内存空间一次清理掉。这样就使得每一次都是对其中一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
现在的商业虚拟机都采用这种收集算法来回收新生代，新生代中的对象绝大部分都是朝生夕死的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor，每次使用Eden和其中一块Survivor，当回收时，将Eden和Survivor中存活的对象一次性地拷贝到另一块Survivor空间，最后清理掉Eden和Survivor空间。
HotSpot虚拟机默认的Eden和Survivor大小比例为8:1，也就是说每次新生代中可用空间为整个新生代空间的90%（80%+10%），只有10%的内存空间是被“浪费”的。当Survivor的空间不够用的时候，需要依赖其他内存（老年代）进行分配担保（Handle Promotion）。
标记-整理算法
标记-整理（Mark-Compact）算法：标记过程与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有的存活对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
当前商业虚拟机的垃圾收集都是采用“分代收集（Generational Collection）算法”，根据对象的存活周期的不同将内存划分为几块。
一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特定采用最适当的收集算法。在新生代，每次垃圾收集都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成省收集。而老年代中因为对象存活率高，没有额外的空间进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
垃圾收集器
垃圾收集器是内存回收的具体实现，Java虚拟机规范对垃圾收集器的实现并没有具体规定，因此不同厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大的区别。
以下是 HotSpot JVM 1.6 的垃圾收集器：
其中，如果两个收集器之间有连线，说明可以搭配使用。
Serial 收集器
特点：
- 单线程收集器
- 在进行垃圾收集时，必需暂停其他所有的工作线程（打扫卫生时，必需要求房间里停止工作产生垃圾）
- 简单而高效，专心做垃圾收集
- 虚拟机运行在Client模式下的默认新生代收集器
ParNew 收集器
ParNew收集器其实就是Serial收集器的多线程版本，是运行在Server模式下的虚拟机中首选的新生代收集器。
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替运行），用户程序继续运行，而垃圾收集线程运行在另一个CPU上。
Parallel Scavenge
Parallel Scavenge收集器是一个使用复制算法的并行的多线程收集器，它关注于提高吞吐量（Throughput，CPU用于运行用户代码的时间和CPU消耗时间的比值）。另外，自适应调节策略也是Parallel Scavenge和ParNew收集器的区别
Serial Old 收集器
是Serial收集器的老年版本。
Parallel Old 收集器
是Parallel Scavenge 收集器的老年版本。
CMS 收集器
CMS（Concurrent Mask Sweep）收集器是一个以获取最短回收停顿时间为目标的收集器。因此，此收集器特别适合现代的互联网或 B/S 架构的服务端上。
CMS 收集器是基于“标记-清除”算法实现的，整个过程分为4个步骤：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
它是一种优秀的收集器。
- 优点是：并发收集、低停顿
- 缺点是：对CPU资源非常敏感、无法处理浮动垃圾、收集结束后会产生大量的空间碎片以致于在给大对象分配空间时带来麻烦
G1 收集器
G1（Garbage First）收集器是当前收集器技术发展的最新成果，相对于上文的 CMS 收集器有两个显著改进：
- 基于“标记-整理”算法，也就是说它不会产生空间碎片
- 非常精确地控制停顿
G1 收集器可以实现在基本不牺牲吞吐量的情况下完成低停顿的回收，它将整个Java堆划分为多个大小固定的独立区域（Region），并跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这也是Garbage First名称的由来）。总而言之，区域划分和有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。
垃圾收集器参数总结
-XX:+UseSerialGC：在新生代和老年代使用串行收集器
-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例
-XX:NewRatio:新生代和老年代的比
-XX:+UseParNewGC：在新生代使用并行收集器
-XX:+UseParallelGC ：新生代使用并行回收收集器
-XX:+UseParallelOldGC：老年代使用并行回收收集器
-XX:ParallelGCThreads：设置用于垃圾回收的线程数
-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器
-XX:ParallelCMSThreads：设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收
-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收
-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收
内存分配与回收策略
Java 技术体系中的自动内存管理最终可以可以归结为自动化地解决了以下两个问题：给对象分配内存和回收分配给对象的内存。
其中，关于回收内存是上文介绍的虚拟机中垃圾收集体系及其工作原理所阐述的内容。
而，关于分配内存则是本节需要阐述的内容。
对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。
- 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多数都具有朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
- 老年代GC（Major GC／Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少发生一次的Minor GC（但是并非绝对，在ParallelScavenge收集器的收集策略里，就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。
大对象直接进入老年代
大对象，是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组。大对象对于虚拟机的内存分配来说，是一个坏消息，因为它的经常出现容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。
虚拟机提供了-XX:PretenureSizeThreshold参数，让大于这个设置值的对象直接在老年代中分配，这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法来收集内存）。
PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，一般也没必要设置。如果遇到必需使用此参数的场合，可以考虑ParNew+CMS的收集器组合
长期存活的对象进入老年代
虚拟机采用了分代收集的思想来管理内存，那么回收时就必须能够识别哪些对象应当放在新生代，哪些对象应该放在老年代。为了达到这个目的，虚拟机给每个对象定义了一个对象年龄（Age）计数器。
如果对象在Eden出现并经过第一次MinorGC后仍然存活，并且能被Survivor容纳，将被移动到Survivor空间，对象年龄加1。对象在Survivor区每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认值是15）时，就会被晋升到老年代中。
对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold来设置
动态对象年龄判定
为了能够更好地适应不同程序的内存状况，虚拟机并不是总要求对象的年龄必需达到MaxTenuringThreshold 才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。
空间分配担保
在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行Minor GC；如果不允许，则也要改为进行一次Full GC。
本博客所有文章除特别声明外均采用CC BY-NC-SA 4.0许可。转载请注明来自https://newgr8player.com。
本文链接：https://newgr8player.com/2018/07/17/深入理解Java虚拟机---第三章/