深入理解java虚拟机-----垃圾回收与内存分配策略

JVM（Java虚拟机)

3 垃圾收集器

3.1 对象的生死

• 引用计数算法

  • 在对象中添加一个引用计数器，当有新的引用指向该对象时，计数器就加1，当有引用失效时计数器就减1。

• 可达性分析算法

  • 基本思路：通过一系列成为“GC ROOTS"的根对象作为起始节点集，从这些节点开始以引用关系向下进行搜索，该过程中所走过的路径成为“引用链”(Reference Chain)，如果某个对象没有任何的引用链与"GC ROOTS"相连，那么该对象就认为是不可用的。
  • GC ROOTS对象：
    • 在虚拟机栈(栈帧中的局部变量表)中引用的对象，比如当前正在运行的方法所使用到的参数、局部变量等。
    • 在方法区中静态属性引用的对象，如Java类的引用类型的静态变量。
    • 在方法区中常量引用的对象，如字符串常量池(String Table)中的引用。
    • 在本地方法栈中JNI(Native方法)所引用的对象。
    • Java虚拟机内部的引用，如基本数据类型所对应的Class类对象，以及一些常驻的异常类对象，还有系统加载器。
    • 所有被同步锁(synchronized)持有的对象。
    • 反应Java虚拟机内部情况的JMCBean、JVMTI中注册的回调、本地代码缓存等。

• 引用的分类

  JDK1.2 之前，一个对象只有“已被引用”和"未被引用"两种状态，这将无法描述某些特殊情况下的对象，比如，当内存充足时需要保留，而内存紧张时才需要被抛弃的一类对象。所以在 JDK.1.2 之后，Java 对引用的概念进行了扩充，将引用分为了：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4 种，这 4 种引用的强度依次减弱。

  • 强引用：只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足时，JVM也会直接抛出OutOfMemoryError，不会去回收。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null，这样一来，JVM就可以适时的回收对象了
  • 软引用：软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统将要发生内存溢出异常之前，系统则会将软引用对象列入回收范围之内进行第二次回收，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。这种特性常常被用来实现缓存技术，比如网页缓存，图片缓存等。在 JDK1.2 之后，用java.lang.ref.SoftReference类来表示软引用。
  • 弱引用：弱引用的引用强度比软引用要更弱一些，无论内存是否足够，只要 JVM 开始进行垃圾回收，那些被弱引用关联的对象都会被回收。在 JDK1.2 之后，用 java.lang.ref.WeakReference 来表示弱引用。
  • 虚引用：虚引用是最弱的一种引用关系，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，它随时可能会被回收，在 JDK1.2 之后，用 PhantomReference 类来表示，通过查看这个类的源码，发现它只有一个构造函数和一个 get() 方法，而且它的 get() 方法仅仅是返回一个null，也就是说将永远无法通过虚引用来获取对象，虚引用必须要和 ReferenceQueue 引用队列一起使用。

• 两次标记定生死

  判定一个对象的死亡最多经过两次标记的过程：

  • 通过可达性分析算法，若对象没有引用链与GC Roots对象相连接，则该对象会被第一次标记
  • 第一次标记之后会进行一次筛选，筛选的条件是该对象是否有必要执行finalize()方法，如果该对象没有覆盖finalize()方法或者finalize()方法已经被JVM调用过一次则会判定为没有必要执行。否则判定为有必要执行，有必要执行finalize()方法的对象会被放置在一个名为F-Queue的队列之中，然后由虚拟机自动创建的低调度优先级的Finalize线程去执行该队列中对象的finalize()方法，但虚拟机只保证方法开始执行，不保证方法执行结束。finalize()方法的执行是对象最后逃离死亡的机会，在代码里与引用链上的任意对象建立关联即可成功拯救自己。稍后会对F-Queue队列中的对象进行第二次标记，没有成功逃脱的对象将会被二次标记。

3.2 垃圾收集算法

• 分代收集理论

  • 弱分代假说
  • 强分代假说
  • 跨代引用假说

• 垃圾回收算法

  • 标记-清除算法
  • 标记-复制算法
  • 标记-整理算法

3.3 垃圾收集器

3.3.1 经典垃圾收集器

• 年轻代收集器

  • Serial收集器--------------------------------------------------标记-复制算法
    • HotSpot在客户端模式下默认的新生代收集器
  • ParNew收集器-----------------------------------------------标记-复制算法
    • Serial收集器的多线程版本
  • Parallel Scavenge收集器---------------------------------标记-复制算法
    • 目标是达到一个可控的吞吐量

• 老年代收集器

  • Serial Old收集器---------------------------------------------标记-整理算法

    • Serial收集器的老年代版本，
    • 作为CMS收集器在运行期间预留的内存空间无法为用户线程创建新对象，发生"并发失败"的时候临时启用。

  • Parallel Old收集器------------------------------------------标记-整理算法

    • Parallel Scavenge收集器的老年代版本，支持多线程并发收集。

  • CMS(Concurrent Mark Sweep)收集器----------------标记-清除算法

    是一款并发的、使用标记-清除算法的垃圾回收器，以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器，对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。过程分为以下几步：

    1. 初始标记(STW initial mark)：在这个阶段，需要虚拟机停顿正在执行的任务，官方的叫法STW(Stop The Word)。这个过程从垃圾回收的"根对象"开始，只扫描到能够和"根对象"直接关联的对象，并作标记。所以这个过程虽然暂停了整个JVM，但是很快就完成了。

    2. 并发标记(Concurrent marking)：这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记。并发标记阶段耗时较长，但是应用程序的线程和并发标记的线程并发执行，所以用户不会感受到停顿。

    3. 并发预清理(Concurrent precleaning) ：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代， 或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段"重新标记"的工作，因为下一个阶段会Stop The World。

    4. 重新标记(STW remark)：为了修正并发标记期间因为用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，此阶段也会Stop The Word并且通常停顿时间比初始标记阶段稍长，但远比并发标记阶段时间短。

    5. 并发清理(Concurrent sweeping)：清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行。

    6. 并发重置(Concurrent reset)：这个阶段，重置CMS收集器的数据结构，等待下一次垃圾回收。

    • CMS收集器的缺点

      1. CMS收集器对处理器资源十分敏感

      2. CMS收集器无法处理"浮动垃圾(Floating Garbage)",可能导致"Concurrent Model Failure"进而导致一次完全"Stop The Word"的Full GC的产生。

      3. 基于标记-清除算法导致空间碎片过多，无法找到足够大的连续空间来分配大对象，不得不触发Full GC。

• 面向全堆收集的收集器

  • Garbage First(G1)收集器

    • 基本理论：G1收集器是一款基于Region的内存布局形式的面向局部收集的垃圾收集器，主要面向服务端应用，且G1收集器能够建立"停顿预测模型",即在长度为M毫秒的时间片段内实现消耗在垃圾收集上的时间大概率不超过N毫秒这样的目标。

    • 基于Region的内存布局：G1把连续的Java堆划分为多个大小相等的独立区域(Region)，每一个Region区域可以根据需要扮演新生代的Eden空间、Survivor空间以及老年代空间。Region中还有专门存储大对象的Humongous区域，G1认为只要大小超过了一个Region的大小的一般的对象就可以判定为大对象。Region的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围为1MB-32MB，且应为2的N次幂。新生代和老年代不是固定的，他们都是一系列区域(不需要连续)的动态集合。Region是G1单次回收的最小单元，根据用户设定允许的最大收集停顿时间优先处理回收价值收益最大的那些Region。

  • 不计用户线程运行过程中的动作(如使用写屏障维护记忆集的操作),G1收集器的运作过程大致可以分为如下的四步：

    • 初始标记：仅标记GC Roots能够直接关联到的对象，并修改TAMS指针，使得下一阶段用户线程并发运行时能够正确的在Region中分配对象，此阶段需要停顿线程，但是时间很短。
    • 并发标记：从GC Roots开始对堆中的对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，耗时较长，但是是并发执行的，且当对象图扫描完成以后还要重新处理STAB中记录的在并发时由引用变动的对象。
    • 最终标记：对用户线程做另一个短暂的暂停，用于处理并发阶段仍留下来的少量的STAB记录。
    • 筛选回收：更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户 所期望的停顿时间来选择任意多个Region构成回收集，然后把要回收的Region的存活对象复制到空的Region中，再清理掉整个旧的Region的全部空间，必须暂停用户线程，有多条收集器线程并行完成。

  • G1整体来看是基于标记-整理算法实现的收集器，但是两个Region看来是基于标记-复制实现的。

3.3.2 低延迟垃圾收集器

• 衡量垃圾收集器的三项最重要的指标

  • 内存占用
  • 吞吐量
  • 延迟

• Shenandoah收集器(只在OpenJDK中存在)

• ZGC收集器：一款基于Region内存布局的，(暂时)不使用分代设计，使用了读屏障、染色指针和内存多重映射等技术实现可并发的标记-整理算法的，以低延迟为首要目标的一款垃圾收集器。

  • ZGC的Region具有动态性–动态创建和销毁以及动态的区域容量大小：

    • 小型：固定容量为2MB，用于放置小于256KB的小对象。
    • 中性：固定容量为32MB，用于放置大于等于256KB但小于4MB的对象。
    • 大型：容量不固定，可以动态变化，但是必须为2MB的整数倍，用于放置4MB及以上的大对象。每个大型的Region中只会存放一个大对象，也就是说大型Region的容量可能小于中型Region的容量
    • 大型Region在ZGC的实现中不会重分配。

  • ZGC收集器的染色指针技术：除掉64位指针的高18位，将剩余46位的高4位提取出来用于存储四个标志信息，通过这些标志位，虚拟机可以直接从指针中看到引用对象的三色标记，是否进入了重分配集，是否只能通过finalize()方法进行访问。这导致ZGC能够管理的内存不超过4TB(2的42次幂)。

  • 染色指针技术的三大优势：

    • 染色指针可以使得一旦某个Region中的存活对象被移走之后，这个Region可以立即被释放和重用。
    • 染色指针可以大幅减少在垃圾收集过程中的内存屏障的使用数量，实际上，ZGC目前为止只是用了读屏障，没有使用过任何的写屏障。
    • 染色指针可以作为一种扩展的存储结构用于记录更多的与对象标记和重定位过程相关的数据，方便日后进一步提升性能。

  • ZGC的内存多重映射技术：在Linux和x86-64平台上的ZGC使用了多重映射将多个不同的虚拟内存地址映射到同一个物理内存地址上，这是一种多对一的映射。

  • ZGC收集器的运作过程：

    • 并发标记：此阶段的前后也要有短暂的暂停用于初始标记和最终标记，该过程是遍历对象图做可达性分析的阶段。与G1、Shenandoah不同的是,ZGC的标记实在指针上而不是在对象上，标记阶段会更新染色指针的Marked 0 和Marked 1标志位。
    • 并发预备重分配：根据特定的查询条件得出本次收集过程要清理哪些Region，将这些Region组成重分配集。
    • 并发重分配：这个阶段把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表，记录就对象到新对象的转发关系。得益于染色指针技术，ZGC能够根据指针判断一个对象是否在重分配集中，这时如果用户并发访问了重分配集中的就对象，就会被预置的内存屏障截获，然后根据Region上维护的转发表来将访问转发到复制的新对象上，并同时修正更新该引用的值，使其直接指向新对象，这种行为称为指针的自愈能力。对象复制完成后，该Region就可以立即释放(仍保留维护的转发表)用于新对象的分配。
    • 并发重映射：该阶段所做的就是修正整个堆中指向重分配集中就对象的所有引用，但这项任务并不迫切，可以合并到下一次垃圾收集循环中的并发标记阶段去完成，可以节省一次遍历对象图的开销。

  • ZGC收集器的缺点：对象分配速率不会太高，收集周期过长，对象分配速率高的话会产生大量的浮动垃圾，回收的内存空间小于浮动垃圾所占用的内存空间，可用内存空间越来越小。

3.4 内存分配与回收策略

• 对象默认优先分配到Eden区

• 大对象直接进入老年代--------------------：-XX:PretenureSizeThreshold=3145728(不能直接写3M)，该参数只对Serial和ParNew收集器有效。

• 长期存活的对象进入老年代--------------：-XX:MaxTenuringThreshold=15(默认是15，在Survivor区中每熬过一次Minor GC就加1)。

• 动态判断对象年龄：如果在Survivor空间中低于或等于某个年龄的所有对象的大小的综合大于Survivor空间的一半，年龄大于或者等于该年龄的对象可以直接进入老年代，无需等到-XX:MaxTenuringThreshold指定的年龄。

• 空间分配担保（JDK 6 Upadte 24之前）

  • 首先检查老年代最大连续空间是否大于新生代所有对象的大小之和，若大于则直接进行Minor GC，无需担保。
  • 若小于，检查参数-XX:HandlePromotionFailure的值是否允许担保失败
  • 若允许担保失败，则继续检查老年代最大可用的连续空间大小是否大于历次晋升到老年代的对象的平均大小，若大于将允许进行一次Minor GC，若小于则不允许。

• 空间分配担保（JDK 6 Upadte 24之后）

  • 只要老年代最大可用的连续空间大小大于新生代所有对象的大小之和或者历次晋升到老年代的对象的平均大小就会进行Minor GC，否则进行Full GC。