• 第一部分 走近Java
• 第一章 走近Java
  • 1.1 概述
  • 1.2 Java技术体系
  • 1.3 Java发展史
  • 1.4 Java虚拟机发展史
    • 1.4.1 Sun Classic / Exact VM
    • 1.4.2 Sun HotSpot VM
    • 1.4.3 Sun Moblie-Embedded VM / Meta-Circular VM
    • 1.4.4 BEA JRockit / IBM J9 VM
    • 1.4.5 Azul VM / BEA Liquid VM
    • 1.4.6 Apache Harmony / Google Android Dalvik VM
    • 1.4.7 Microsoft JVM及其他
  • 1.5 展望Java技术的未来
    • 1.5.1 模块化
    • 1.5.2 混合语言
    • 1.5.3 多核并行
    • 1.5.4 进一步丰富语法
    • 1.5.5 64位虚拟机
  • 1.6 实战：子集编译JDK
    • 1.6.1 获取JDK源码
    • 1.6.2 系统需求
    • 1.6.3 构建编译环境
    • 1.6.4 进行编译
    • 1.6.5 在IDE工具中进行源码调试
  • 1.7 本章小结
• 第二部分 自动内存管理机制
• 第2章 Java内存区域与内存溢出异常
  • 2.1 概述
  • 2.2 运行时数据区域
    • 2.2.1 程序计数器
    • 2.2.2 Java虚拟机栈
    • 2.2.3 本地方法栈
    • 2.2.4 Java堆
    • 2.2.5 方法区
    • 2.2.6 运行时常量池
    • 2.2.7 直接内存
  • 2.3 HotSpot虚拟机对象探秘
    • 2.3.1 对象的创建
      • 一、检测类是否被加载
      • 二、为新生对象分配内存
      • 三、初始化零值
      • 四、进行必要的设置
      • 五、执行init方法
    • 2.3.2 对象的内存布局
    • 2.3.3 对象的访问定位
  • 2.4 实战：OutOfMemoryError异常
    • 2.4.1 Java堆溢出
    • 2.4.2 虚拟机栈和本地方法栈溢出
    • 2.4.3 方法区和运行时常量池溢出
    • 2.4.4 本机直接内存溢出
  • 2.5 本章小结
• 第3章 垃圾收集器与内存分配策略
  • 3.1 概述
  • 3.2 对象已死吗？
    • 3.2.1 引用计数算法
    • 3.2.2 可达性分析算法
    • 3.2.3 再谈引用
    • 3.2.4 生存还是死亡
    • 3.2.5 回收方法区
  • 3.3 垃圾收集算法
    • 3.3.1 标记-清除算法
    • 3.3.2 复制算法
    • 3.3.3 标记-整理算法
    • 3.3.4 分代收集算法
  • 3.4 HotSpot的算法实现
    • 3.4.1 枚举根节点
    • 3.4.2 安全点

第一部分 走近Java

第一章 走近Java

1.1 概述

1.2 Java技术体系

Sun官方所定义的Java技术体系包括：

• Java程序设计语言
• 各种硬件平台上的Java虚拟机
• Class文件格式
• Java API类库
• 来自商业机构和开源社区的第三方Java类库

我们可以把Java程序设计语言、Java虚拟机、Java API类库这三部分统称为JDK（Java Development Kit），JDK是用于支持Java程序开发的最小环境。

可以把Java API类库中的Java SE API子集和Java虚拟机这两部分统称为JRE（Java Runtime Environment），JRE是支持Java程序运行的标准环境。

Java技术体系可以分为4个平台，分别为：

• Java Card：支持一些Java小程序（Applets）运行在小内存设备（如智能卡）上的平台
• Java ME（Micro Edition）：支持Java程序运行在移动端（手机、PDA）上的平台，对Java API有所精简，并加入了针对移动端的支持，这个版本以前称为J2ME。
• Java SE（Standard Edition）：支持面向桌面级应用（如Windows下的应用程序）的Java平台，提供了完整的Java核心API，这个版本以前称为J2SE。
• Java EE（Enterprise Edition）：支持使用多层架构的企业应用（如ERP、CRM应用）的Java平台，除了提供Java SE API外，还对其做了大量的扩充，并提供了相关的部署支持，这个版本以前称为J2EE。

1.3 Java发展史

1.4 Java虚拟机发展史

1.4.1 Sun Classic / Exact VM

1.4.2 Sun HotSpot VM

1.4.3 Sun Moblie-Embedded VM / Meta-Circular VM

1.4.4 BEA JRockit / IBM J9 VM

1.4.5 Azul VM / BEA Liquid VM

1.4.6 Apache Harmony / Google Android Dalvik VM

1.4.7 Microsoft JVM及其他

1.5 展望Java技术的未来

1.5.1 模块化

1.5.2 混合语言

1.5.3 多核并行

• JDK 1.5：java.util.concurrent
• JDK 1.7：Fork/Join
• java8：Lambda支持

1.5.4 进一步丰富语法

1.5.5 64位虚拟机

1.6 实战：子集编译JDK

1.6.1 获取JDK源码

OpenJDK

1.6.2 系统需求

1.6.3 构建编译环境

1.6.4 进行编译

1.6.5 在IDE工具中进行源码调试

1.7 本章小结

第二部分 自动内存管理机制

第2章 Java内存区域与内存溢出异常

2.1 概述

2.2 运行时数据区域

2.2.1 程序计数器

程序计数器（Program Counter Register）是一块较小的内存，它可以看作是当前线程所执行的字节码文件的行号指示器。在虚拟机的概念模型里，字节码解释工作时就是通过改变这个计数器的值来选取下一条指令、分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖于这个程序计数器来完成的。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只执行一条线程中的指令。因此，为了线程切换后能够恢复到正确的执行位置，每条线程都需要一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个Java方法，这个计数器记录的是 正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法，这个计数器值则为空（Undifined）。此内存区域是唯一一个在Java虚拟机规范中没有规定人格OutOfMemoryError情况的区域

2.2.2 Java虚拟机栈

Java虚拟机栈（Java Virtual Machine Statcks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverFlowError异常；如果虚拟机栈可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

2.2.3 本地方法栈

本地方法栈（Native Method Stack）与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈位虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

2.2.4 Java堆

对于大多数应用来说，Java堆是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

Java对是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”，从内存回收的角度看，由于现在收集器基本都在用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间等。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都依然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快的分配内存。

根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存中，只要逻辑上是连续的即可，就像我们的磁盘一样。在实现时，既可以实现成固定的大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

2.2.5 方法区

方法区域Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态方法、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但它却有一个别名叫做Non-Heap(非堆)，目的应该是与Java堆区分开来

对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说，很多人都更愿意把方法区成为“永久代”，本质上两者是不等价的，仅仅是因为HotSpot虚拟机的设计团队把GC分代收集扩展至方法区，或者说使用永生代来实现方法区而已，这样HotSpot虚拟机的垃圾回收器可以像管理Java对堆一样管理这部分内存，能够省去专门为这些方法区编写内存管理代码的工作。原则上如何实现方法区属于虚拟机实现细节，不受虚拟机规范的要求，但是用永生代来实现方法区，现在并不是一个好主意，因为这样更容易遇到内存溢出的问题（永生代有-XX：MaxPermSize 的上限，J9和JRockit只要没有触碰到进程可用内存的上限，例如32位系统中的4GB，就不会出现问题），而且有极少数方法会因为这个原因导致不同虚拟机下有不同的表现。因此，对于HotSpot虚拟机，根据官方发布的路线图信息，现在也有放弃永久代并逐步采用Native Memory来实现方法区的规划了，在目前已经发布的JDK 1.7的HotSpot中，已经把原来放在永久代的字符串常量池移除。

Java虚拟机规范对方法的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说，这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是必要的。在SUN公司的BUG列表中，曾出现过的若干个严重的BUG就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

2.2.6 运行时常量池

2.2.7 直接内存

直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域.但是这部分内存也被频繁的使用,而且也可能导致OutOfMemoryError异常出现.

在JDK1.4中新加入NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作.这样能在一些场景中显著提高性能,因为避免了在Java堆和Native对中来回复制数据.

显然,本机直接内存的分配不会受到Java堆大小的影响,但是既然是内存,肯定还是会受到本机总内存(包括RAM以及SWAP区或者分页文件)大小以及处理器寻址空间的限制.服务器管理员在配置虚拟机参数时,会根据实际内存设置-Xmx等参数信息,但是经常忽略直接内存,是的各个内存区域总和大于物理内存限制(包括物理的和操作系统级的限制),从而导致动态扩展时出现OutOfMemoryError异常.

2.3 HotSpot虚拟机对象探秘

2.3.1 对象的创建

Java是一门面向对象的编程语言，在Java程序运行过程中每时每刻都有对象被创建出来。在语言层面上,创建对象通常仅仅是一个new关键字而已，而在虚拟机中，对象的创建又是怎样一个过程呢？

一、检测类是否被加载

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

二、为新生对象分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定。

假设Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那么分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”。

如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”。

选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

线程安全问题：

• 采用CAS配上失败重试的方式保证更新操作的原子性
• 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定

三、初始化零值

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

四、进行必要的设置

接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头之中。

五、执行init方法

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从Java程序的视角来看，对象创建才刚开始，&ltginit>方法还没有执行，所有的字段都还为零。所以一般来说，执行new指令之后会接着执行方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

2.3.2 对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。

HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32bit和64bit，官方称它为”Mark Word”。

HotSpot虚拟机对象头Mark Word

对象头的另外一部分时类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。另外，如果对象是一个Java数组，那么对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组的大小。

2.3.3 对象的访问定位

这两种对象访问方式各有优势：

• 使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而reference本身不需要修改
• 使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。

Sun HotSpot使用第二种方式进行对象访问。

2.4 实战：OutOfMemoryError异常

2.4.1 Java堆溢出

java.lang.OutOfMemoryError: Java heap space

要解决这个区域的异常，一般的手段时先通过内存映像分析工具对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

• 如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。
• 如果不存在泄漏，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

2.4.2 虚拟机栈和本地方法栈溢出

在单个线程下，无论是由于帧栈太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。

Exception in thread "main" java.lang.StackOverflowError

如果测试时不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常。

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

2.4.3 方法区和运行时常量池溢出

方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景有：CGLib字节码增强、动态语言、大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGi的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。

2.4.4 本机直接内存溢出

DirectMemory容量可通过-XX: MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值（-Xmx指定）一样。

Exception in thread "main" java.lang.OutOfMemoryError

由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以考虑检查以下是不是这方面的原因。

2.5 本章小结

第3章 垃圾收集器与内存分配策略

3.1 概述

思考GC需要完成的3件事情：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

3.2 对象已死吗？

3.2.1 引用计数算法

至少主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。

3.2.2 可达性分析算法

算法基本思路：通过一系列的称为”GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话说，就是从GC Roots到这个对象不可达）时，则证明此对象时不可用的。

在Java语言中，可作为GC Roots的对象包括下面几种：

• 虚拟机栈（帧栈中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的Native方法）引用的对象

3.2.3 再谈引用

在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱应用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

• 强引用就是指在程序代码种普遍存在的，类似”Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用时用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。
• 虚引用也称为幽灵引用或者幻影引用，它时最弱的一种引用关系。一个对象是否虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

3.2.4 生存还是死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GCRoots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。

任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象第一次在finalize()方法种逃逸成功，面临下一次回收时，它的finalize()方法不会被再次执行。

3.2.5 回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

3.3 垃圾收集算法

3.3.1 标记-清除算法

算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后同一回收所有被标记的对象。

不足：

1. 一个是效率问题，标记和清除两个过程的效率都不高
2. 另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

3.3.2 复制算法

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

代价：内存缩小为了原来的一半，未免太高了一点。

新生代中的对象98%是“朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handel Promotion）。如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

3.3.3 标记-整理算法

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而实让所有存活的对象都向一端移动，然后直接清理掉端边界意外的内存。

3.3.4 分代收集算法

在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

3.4 HotSpot的算法实现

3.4.1 枚举根节点

枚举根节点时必须要停顿的。

由于目前的主流Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。

3.4.2 安全点

HotSpot没有为每条指令都生成OopMap，只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。

如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。两种方案：

• 抢先式中断（Preemptive Suspension）：不需要线程的执行代码主动取配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现抢先式中断来暂停线程从而响应GC事件。
• 主动式中断（Voluntary Suspension）：当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动取轮询这个标志，发现中断标志为真时就自己中断挂起，轮询标志的地方和安全点时重合的，另外再加上创建对象需要分配内存的地方。

### 3.4.3 安全区域

安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。

在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了，在线程要离开Safe Region时，它要检查系统是否已经完成了根节点的枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。

## 3.5 垃圾收集器

如果说手机算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

HotSpot虚拟机的垃圾收集器