学习笔记：JVM知识体系（上）——内存结构、虚拟机对象、垃圾回收、内存分配、调优

原文：https://github.com/doocs/jvm

---

一、JVM 内存结构

Java 虚拟机的内存空间分为 5 个部分：

• 程序计数器
• Java 虚拟机栈
• 本地方法栈
• 堆
• 方法区

JDK 1.8 同 JDK 1.7 比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。

1、程序计数器（PC 寄存器）

1. 程序计数器的定义

程序计数器是一块较小的内存空间，是当前线程正在执行的那条字节码指令的地址。若当前线程正在执行的是一个本地方法，那么此时程序计数器为Undefined。

2. 程序计数器的作用

• 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制。
• 在多线程情况下，程序计数器记录的是当前线程执行的位置，从而当线程切换回来时，就知道上次线程执行到哪了。

3. 程序计数器的特点

• 是一块较小的内存空间。
• 线程私有，每条线程都有自己的程序计数器。
• 生命周期：随着线程的创建而创建，随着线程的结束而销毁。
• 是唯一一个不会出现 OutOfMemoryError 的内存区域。

2、Java 虚拟机栈（Java 栈）

1. Java 虚拟机栈的定义

Java 虚拟机栈是描述 Java 方法运行过程的内存模型。

Java 虚拟机栈会为每一个即将运行的 Java 方法创建一块叫做“栈帧”的区域，用于存放该方法运行过程中的一些信息，如：

• 局部变量表
• 操作数栈
• 动态链接
• 方法出口信息
• …

2. 压栈出栈过程

当方法运行过程中需要创建局部变量时，就将局部变量的值存入栈帧中的局部变量表中。

Java 虚拟机栈的栈顶的栈帧是当前正在执行的活动栈，也就是当前正在执行的方法，PC 寄存器也会指向这个地址。只有这个活动的栈帧的本地变量可以被操作数栈使用，当在这个栈帧中调用另一个方法，与之对应的栈帧又会被创建，新创建的栈帧压入栈顶，变为当前的活动栈帧。

方法结束后，当前栈帧被移出，栈帧的返回值变成新的活动栈帧中操作数栈的一个操作数。如果没有返回值，那么新的活动栈帧中操作数栈的操作数没有变化。

由于 Java 虚拟机栈是与线程对应的，数据不是线程共享的（也就是线程私有的)，因此不用关心数据一致性问题，也不会存在同步锁的问题。

3. 局部变量表

定义为一个数字数组，主要用于存储方法参数、定义在方法体内部的局部变量，数据类型包括各类基本数据类型，对象引用，以及 return address 类型。

局部变量表容量大小是在编译期确定下来的。最基本的存储单元是 slot，32 位占用一个 slot，64 位类型（long 和 double）占用两个 slot。

对于 slot 的理解：

• JVM 虚拟机会为局部变量表中的每个 slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值。
• 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用 this，会存放在 index 为 0 的 slot 处，其余的参数表顺序继续排列。
• 栈帧中的局部变量表中的槽位是可以重复的，如果一个局部变量过了其作用域，那么其作用域之后申明的新的局部变量就有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

在栈帧中，与性能调优关系最密切的部分，就是局部变量表，方法执行时，虚拟机使用局部变量表完成方法的传递局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

4. 操作数栈

• 栈顶缓存技术：由于操作数是存储在内存中，频繁的进行内存读写操作影响执行速度，将栈顶元素全部缓存到物理 CPU 的寄存器中，以此降低对内存的读写次数，提升执行引擎的执行效率。
• 每一个操作数栈会拥有一个明确的栈深度，用于存储数值，最大深度在编译期就定义好。32bit 类型占用一个栈单位深度，64bit 类型占用两个栈单位深度操作数栈。
• 并非采用访问索引方式进行数据访问，而是只能通过标准的入栈、出栈操作完成一次数据访问。

5. 方法的调用

• 静态链接：当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行时期间保持不变，这种情况下降调用方的符号引用转为直接引用的过程称为静态链接。
• 动态链接：如果被调用的方法无法在编译期被确定下来，只能在运行期将调用的方法的符号引用转为直接引用，这种引用转换过程具备动态性，因此被称为动态链接。
• 方法绑定
  • 早期绑定：被调用的目标方法如果在编译期可知，且运行期保持不变。
  • 晚期绑定：被调用的方法在编译期无法被确定，只能够在程序运行期根据实际的类型绑定相关的方法。
• 非虚方法：如果方法在编译期就确定了具体的调用版本，则这个版本在运行时是不可变的，这样的方法称为非虚方法静态方法。私有方法，final 方法，实例构造器，父类方法都是非虚方法，除了这些以外都是虚方法。
• 虚方法表：面向对象的编程中，会很频繁的使用动态分配，如果每次动态分配的过程都要重新在类的方法元数据中搜索合适的目标的话，就可能影响到执行效率，因此为了提高性能，JVM 采用在类的方法区建立一个虚方法表，使用索引表来代替查找。
  • 每个类都有一个虚方法表，表中存放着各个方法的实际入口。
  • 虚方法表会在类加载的链接阶段被创建，并开始初始化，类的变量初始值准备完成之后，JVM 会把该类的方法也初始化完毕。
• 方法重写的本质
  • 找到操作数栈顶的第一个元素所执行的对象的实际类型，记做 C。如果在类型 C 中找到与常量池中描述符和简单名称都相符的方法，则进行访问权限校验。
  • 如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回 java.lang.IllegalAccessError 异常。
  • 否则，按照继承关系从下往上依次对 C 的各个父类进行上一步的搜索和验证过程。
  • 如果始终没有找到合适的方法，则抛出 java.lang.AbstractMethodError 异常。

Java 中任何一个普通方法都具备虚函数的特征（运行期确认，具备晚期绑定的特点），C++ 中则使用关键字 virtual 来显式定义。如果在 Java 程序中，不希望某个方法拥有虚函数的特征，则可以使用关键字 final 来标记这个方法。

6. Java 虚拟机栈的特点

• 运行速度特别快，仅仅次于 PC 寄存器。
• 局部变量表随着栈帧的创建而创建，它的大小在编译时确定，创建时只需分配事先规定的大小即可。在方法运行过程中，局部变量表的大小不会发生改变。
• Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。
  • StackOverFlowError 若 Java 虚拟机栈的大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度时，抛出 StackOverFlowError 异常。
  • OutOfMemoryError 若允许动态扩展，那么当线程请求栈时内存用完了，无法再动态扩展时，抛出 OutOfMemoryError 异常。
• Java 虚拟机栈也是线程私有，随着线程创建而创建，随着线程的结束而销毁。
• 出现 StackOverFlowError 时，内存空间可能还有很多。

常见的运行时异常有：

• NullPointerException - 空指针引用异常
• ClassCastException - 类型强制转换异
• IllegalArgumentException - 传递非法参数异常
• ArithmeticException - 算术运算异常
• ArrayStoreException - 向数组中存放与声明类型不兼容对象异常
• IndexOutOfBoundsException - 下标越界异常
• NegativeArraySizeException - 创建一个大小为负数的数组错误异常
• NumberFormatException - 数字格式异常
• SecurityException - 安全异常
• UnsupportedOperationException - 不支持的操作异常

3、本地方法栈（C 栈）

1. 本地方法栈的定义

本地方法栈是为 JVM 运行 native 方法准备的空间，由于很多 native 方法都是用 C 语言实现的，所以它通常又叫 C 栈。它与 Java 虚拟机栈实现的功能类似，只不过本地方法栈是描述本地方法运行过程的内存模型。

2. 栈帧变化过程

本地方法被执行时，在本地方法栈也会创建一块栈帧，用于存放该方法的局部变量表、操作数栈、动态链接、方法出口信息等。

方法执行结束后，相应的栈帧也会出栈，并释放内存空间。也会抛出 StackOverFlowError 和 OutOfMemoryError 异常。

如果 Java 虚拟机本身不支持 native 方法，或是本身不依赖于传统栈，那么可以不提供本地方法栈。如果支持本地方法栈，那么这个栈一般会在线程创建的时候按线程分配。

4、堆

1. 堆的定义

堆是用来存放对象的内存空间，几乎所有的对象都存储在堆中。

2. 堆的特点

• 线程共享，整个 Java 虚拟机只有一个堆，所有的线程都访问同一个堆。而程序计数器、Java 虚拟机栈、本地方法栈都是一个线程对应一个。
• 在虚拟机启动时创建。
• 是垃圾回收的主要场所。
• 堆可分为新生代（Eden 区：From Survior，To Survivor）、老年代。
• Java 虚拟机规范规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
• 关于 From，To 区: 复制之后有交换，谁空谁是 To Survivor。

不同的区域存放不同生命周期的对象，这样可以根据不同的区域使用不同的垃圾回收算法，更具有针对性。

堆的大小既可以固定也可以扩展，但对于主流的虚拟机，堆的大小是可扩展的，因此当线程请求分配内存，但堆已满，且内存已无法再扩展时，就抛出 OutOfMemoryError 异常。

Java 堆所使用的内存不需要保证是连续的。而由于堆是被所有线程共享的，所以对它的访问需要注意同步问题，方法和对应的属性都需要保证一致性。

3. 新生代与老年代

• 老年代比新生代生命周期长。
• 新生代与老年代空间默认比例 1:2：JVM 调参数，XX:NewRatio=2，表示新生代占 1，老年代占 2，新生代占整个堆的 1/3。
• HotSpot 中，Eden 空间和另外两个 Survivor 空间缺省所占的比例是：8:1:1。
• 几乎所有的 Java 对象都是在 Eden 区被 new 出来的，Eden 放不了的大对象，就直接进入老年代了。

4. 对象分配过程

• new 的对象先放在 Eden 区，大小有限制
• 如果创建新对象时，Eden 空间填满了，就会触发 Minor GC，将 Eden 不再被其他对象引用的对象进行销毁，再加载新的对象放到 Eden 区，特别注意的是 Survivor 区满了是不会触发 Minor GC 的，而是 Eden 空间填满了，Minor GC 才顺便清理 Survivor 区
• 将 Eden 中剩余的对象移到 Survivor0 区
• 再次触发垃圾回收，此时上次 Survivor 下来的，放在 Survivor0 区的，如果没有回收，就会放到 Survivor1 区
• 再次经历垃圾回收，又会将幸存者重新放回 Survivor0 区，依次类推
• 默认是 15 次的循环，超过 15 次，则会将幸存者区幸存下来的转去老年区
  jvm 参数设置次数 : -XX:MaxTenuringThreshold=N 进行设置
• 频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间搜集

5. Full GC / Major GC 触发条件

• 显示调用System.gc()，老年代的空间不够，方法区的空间不够等都会触发 Full GC，同时对新生代和老年代回收，Full GC 的 STW 的时间最长，应该要避免
• 在出现 Major GC 之前，会先触发 Minor GC，如果老年代的空间还是不够就会触发 Major GC，STW 的时间长于 Minor GC

6. 逃逸分析

标量替换

• 标量不可在分解的量，java 的基本数据类型就是标量，标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在 JAVA 中对象就是可以被进一步分解的聚合量
• 替换过程，通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM 不会创建该对象，而会将该对象成员变量分解若干个被这个方法使用的成员变量所代替。这些代替的成员变量在栈帧或寄存器上分配空间。

对象和数组并非都是在堆上分配内存的

• 《深入理解 Java 虚拟机中》关于 Java 堆内存有这样一段描述：随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配,标量替换优化技术将会导致一些变化，所有的对象都分配到堆上也渐渐变得不那么"绝对"了。

• 这是一种可以有效减少 Java 内存堆分配压力的分析算法，通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

• 当一个对象在方法中被定义后，它可能被外部方法所引用，如作为调用参数传递到其他地方中，称为方法逃逸。

• 再如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸

• 使用逃逸分析，编译器可以对代码做如下优化：

  • 同步省略：如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。

  • 将堆分配转化为栈分配：如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。

  • 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在 CPU 寄存器中。

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer s = new StringBuffer();
    s.append(s1);
    s.append(s2);
    return s;
}

s 是一个方法内部变量，上边的代码中直接将 s 返回，这个 StringBuffer 的对象有可能被其他方法所改变，导致它的作用域就不只是在方法内部，即使它是一个局部变量，但还是逃逸到了方法外部，称为方法逃逸。

还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

• 在编译期间，如果 JIT 经过逃逸分析，发现有些对象没有逃逸出方法，那么有可能堆内存分配会被优化成栈内存分配。
• jvm 参数设置，-XX:+DoEscapeAnalysis ：开启逃逸分析 ，-XX:-DoEscapeAnalysis ： 关闭逃逸分析
• 从 jdk 1.7 开始已经默认开始逃逸分析。

7. TLAB

• TLAB 的全称是 Thread Local Allocation Buffer，即线程本地分配缓存区，是属于 Eden 区的，这是一个线程专用的内存分配区域，线程私有，默认开启的（当然也不是绝对的，也要看哪种类型的虚拟机）
• 堆是全局共享的，在同一时间，可能会有多个线程在堆上申请空间，但每次的对象分配需要同步的进行（虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性）但是效率却有点下降
• 所以用 TLAB 来避免多线程冲突，在给对象分配内存时，每个线程使用自己的 TLAB，这样可以使得线程同步，提高了对象分配的效率
• 当然并不是所有的对象都可以在 TLAB 中分配内存成功，如果失败了就会使用加锁的机制来保持操作的原子性
• -XX:+UseTLAB 使用 TLAB，-XX:+TLABSize 设置 TLAB 大小

8. 四种引用方式

• 强引用：创建一个对象并把这个对象赋给一个引用变量，普通 new 出来对象的变量引用都是强引用，有引用变量指向时永远不会被垃圾回收，jvm 即使抛出 OOM，可以将引用赋值为 null，那么它所指向的对象就会被垃圾回收。
• 软引用：如果一个对象具有软引用，内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
• 弱引用：非必需对象，当 JVM 进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。
• 虚引用：虚引用并不会决定对象的生命周期，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。

5、方法区

1. 方法区的定义

Java 虚拟机规范中定义方法区是堆的一个逻辑部分。方法区存放以下信息：

• 已经被虚拟机加载的类信息
• 常量
• 静态变量
• 即时编译器编译后的代码

2. 方法区的特点

• 线程共享。 方法区是堆的一个逻辑部分，因此和堆一样，都是线程共享的。整个虚拟机中只有一个方法区。
• 永久代。 方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，把方法区称为“永久代”。
• 内存回收效率低。 方法区中的信息一般需要长期存在，回收一遍之后可能只有少量信息无效。主要回收目标是：对常量池的回收；对类型的卸载。
• Java 虚拟机规范对方法区的要求比较宽松。 和堆一样，允许固定大小，也允许动态扩展，还允许不实现垃圾回收。

3. 运行时常量池

方法区中存放：类信息、常量、静态变量、即时编译器编译后的代码。常量就存放在运行时常量池中。

当类被 Java 虚拟机加载后， .class 文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如 String 类的 intern() 方法就能在运行期间向常量池中添加字符串常量。

6、直接内存（堆外内存）

直接内存是除 Java 虚拟机之外的内存，但也可能被 Java 使用。

1. 操作直接内存

在 NIO 中引入了一种基于通道和缓冲的 IO 方式。它可以通过调用本地方法直接分配 Java 虚拟机之外的内存，然后通过一个存储在堆中的DirectByteBuffer对象直接操作该内存，而无须先将外部内存中的数据复制到堆中再进行操作，从而提高了数据操作的效率。

直接内存的大小不受 Java 虚拟机控制，但既然是内存，当内存不足时就会抛出 OutOfMemoryError 异常。

2. 直接内存与堆内存比较

• 直接内存申请空间耗费更高的性能
• 直接内存读取 IO 的性能要优于普通的堆内存
• 直接内存作用链： 本地 IO -> 直接内存 -> 本地 IO
• 堆内存作用链：本地 IO -> 直接内存 -> 非直接内存 -> 直接内存 -> 本地 IO

服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制，从而导致动态扩展时出现OutOfMemoryError异常。

---

二、HotSpot 虚拟机对象探秘

1. 对象的内存布局

在 HotSpot 虚拟机中，对象的内存布局分为以下 3 块区域：

• 对象头（Header）
• 实例数据（Instance Data）
• 对齐填充（Padding）

1.1 对象头

对象头记录了对象在运行过程中所需要使用的一些数据：

• 哈希码
• GC 分代年龄
• 锁状态标志
• 线程持有的锁
• 偏向线程 ID
• 偏向时间戳

对象头可能包含类型指针，通过该指针能确定对象属于哪个类。如果对象是一个数组，那么对象头还会包括数组长度。

1.2 实例数据

实例数据部分就是成员变量的值，其中包括父类成员变量和本类成员变量。

1.3 对齐填充

用于确保对象的总长度为 8 字节的整数倍。

HotSpot VM 的自动内存管理系统要求对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

对齐填充并不是必然存在，也没有特别的含义，它仅仅起着占位符的作用。

2. 对象的创建过程

2.1 类加载检查

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

2.2 为新生对象分配内存

对象所需内存的大小在类加载完成后便可完全确定，接下来从堆中划分一块对应大小的内存空间给新的对象。分配堆中内存有两种方式：

• 指针碰撞
  如果 Java 堆中内存绝对规整（说明采用的是“复制算法”或“标记整理法”），空闲内存和已使用内存中间放着一个指针作为分界点指示器，那么分配内存时只需要把指针向空闲内存挪动一段与对象大小一样的距离，这种分配方式称为“指针碰撞”。

• 空闲列表
  如果 Java 堆中内存并不规整，已使用的内存和空闲内存交错（说明采用的是标记-清除法，有碎片），此时没法简单进行指针碰撞， VM 必须维护一个列表，记录其中哪些内存块空闲可用。分配之时从空闲列表中找到一块足够大的内存空间划分给对象实例。这种方式称为“空闲列表”。

2.3 初始化

分配完内存后，为对象中的成员变量赋上初始值，设置对象头信息，调用对象的构造函数方法进行初始化。

至此，整个对象的创建过程就完成了。

3. 对象的访问方式

所有对象的存储空间都是在堆中分配的，但是这个对象的引用却是在堆栈中分配的。也就是说在建立一个对象时两个地方都分配内存，在堆中分配的内存实际建立这个对象，而在堆栈中分配的内存只是一个指向这个堆对象的指针（引用）而已。 那么根据引用存放的地址类型的不同，对象有不同的访问方式。

3.1 句柄访问方式

堆中需要有一块叫做“句柄池”的内存空间，句柄中包含了对象实例数据与类型数据各自的具体地址信息。

引用类型的变量存放的是该对象的句柄地址（reference）。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址找到对象。

3.2 直接指针访问方式

引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间需要额外的策略存储对象所属的类信息的地址。

需要说明的是，HotSpot 采用第二种方式，即直接指针方式来访问对象，只需要一次寻址操作，所以在性能上比句柄访问方式快一倍。但像上面所说，它需要额外的策略来存储对象在方法区中类信息的地址。

---

三、垃圾收集策略与算法

程序计数器、虚拟机栈、本地方法栈随线程而生，也随线程而灭；栈帧随着方法的开始而入栈，随着方法的结束而出栈。这几个区域的内存分配和回收都具有确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

而对于 Java 堆和方法区，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的正是这部分内存。

1. 判定对象是否存活

若一个对象不被任何对象或变量引用，那么它就是无效对象，需要被回收。

1.1 引用计数法

在对象头维护着一个 counter 计数器，对象被引用一次则计数器 +1；若引用失效则计数器 -1。当计数器为 0 时，就认为该对象无效了。

引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。但是主流的 Java 虚拟机里没有选用引用计数算法来管理内存，主要是因为它很难解决对象之间循环引用的问题。（虽然循环引用的问题可通过 Recycler 算法解决，但是在多线程环境下，引用计数变更也要进行昂贵的同步操作，性能较低，早期的编程语言会采用此算法。）

举个栗子 👉 对象 objA 和 objB 都有字段 instance，令 objA.instance = objB 并且 objB.instance = objA，由于它们互相引用着对方，导致它们的引用计数都不为 0，于是引用计数算法无法通知 GC 收集器回收它们。

1.2 可达性分析法

所有和 GC Roots 直接或间接关联的对象都是有效对象，和 GC Roots 没有关联的对象就是无效对象。

GC Roots 是指：

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

GC Roots 并不包括堆中对象所引用的对象，这样就不会有循环引用的问题。

2. 引用的种类

判定对象是否存活与“引用”有关。在 JDK 1.2 以前，Java 中的引用定义很传统，一个对象只有被引用或者没有被引用两种状态，我们希望能描述这一类对象：当内存空间还足够时，则保留在内存中；如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。

在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为了以下四种。不同的引用类型，主要体现的是对象不同的可达性状态reachable和垃圾收集的影响。

2.1 强引用（Strong Reference）

类似 “Object obj = new Object()” 这类的引用，就是强引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象。但是，如果我们错误地保持了强引用，比如：赋值给了 static 变量，那么对象在很长一段时间内不会被回收，会产生内存泄漏。

2.2 软引用（Soft Reference）

软引用是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当 JVM 认为内存不足时，才会去试图回收软引用指向的对象。JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。软引用通常用来实现内存敏感的缓存，如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。

2.3 弱引用（Weak Reference）

弱引用的强度比软引用更弱一些。当 JVM 进行垃圾回收时，无论内存是否充足，都会回收只被弱引用关联的对象。

2.4 虚引用（Phantom Reference）

Java的虚引用（Phantom Reference）是最弱的一种引用类型，它在java.lang.ref包中定义。虚引用的主要作用是跟踪对象被垃圾回收的状态，但不能通过虚引用获取到对象的实例。当一个对象仅持有虚引用时，它和没有任何引用一样，在任何时候都可能被垃圾回收器回收。

虚引用的主要特点和作用如下：

1. 虚引用无法单独使用，也不能通过它访问对象。它必须和引用队列（ReferenceQueue）联合使用。当对象被垃圾回收时，会被加入到该队列中，从而可以跟踪对象的回收状态。
2. PhantomReference的get方法总是返回null，因此无法访问对应的引用对象。其意义在于说明一个对象已经进入finalization阶段，可以被垃圾回收器（GC）回收，用来实现比finalization机制更灵活的回收操作。
3. 一个对象是否有虚引用的存在，完全不会对其生命周期构成影响。也就是说，虚引用的存在并不会阻止垃圾回收器回收该对象。

总的来说，Java的虚引用主要用于在对象被垃圾回收时执行一些额外的操作，如资源清理、日志记录等。这些操作可以在对象被实际回收之前进行，从而避免了一些潜在的问题和错误。

3. 回收堆中无效对象

对于可达性分析中不可达的对象，也并不是没有存活的可能。

3.1 判定 finalize() 是否有必要执行

JVM 会判断此对象是否有必要执行 finalize() 方法，如果对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，那么视为“没有必要执行”。那么对象基本上就真的被回收了。

如果对象被判定为有必要执行 finalize() 方法，那么对象会被放入一个 F-Queue 队列中，虚拟机会以较低的优先级执行这些 finalize()方法，但不会确保所有的 finalize() 方法都会执行结束。如果 finalize() 方法出现耗时操作，虚拟机就直接停止指向该方法，将对象清除。

3.2 对象重生或死亡

如果在执行 finalize() 方法时，将 this 赋给了某一个引用，那么该对象就重生了。如果没有，那么就会被垃圾收集器清除。

任何一个对象的 finalize() 方法只会被系统自动调用一次，如果对象面临下一次回收，它的 finalize() 方法不会被再次执行，想继续在 finalize() 中自救就失效了。

4. 回收方法区内存

方法区中存放生命周期较长的类信息、常量、静态变量，每次垃圾收集只有少量的垃圾被清除。方法区中主要清除两种垃圾：

• 废弃常量
• 无用的类

4.1 判定废弃常量

只要常量池中的常量不被任何变量或对象引用，那么这些常量就会被清除掉。比如，一个字符串 “bingo” 进入了常量池，但是当前系统没有任何一个 String 对象引用常量池中的 “bingo” 常量，也没有其它地方引用这个字面量，必要的话，"bingo"常量会被清理出常量池。

4.2 判定无用的类

判定一个类是否是“无用的类”，条件较为苛刻。

• 该类的所有对象都已经被清除
• 加载该类的 ClassLoader 已经被回收
• 该类的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

一个类被虚拟机加载进方法区，那么在堆中就会有一个代表该类的对象：java.lang.Class。这个对象在类被加载进方法区时创建，在方法区该类被删除时清除。

5. 垃圾收集算法

学会了如何判定无效对象、无用类、废弃常量之后，剩余工作就是回收这些垃圾。常见的垃圾收集算法有以下几个：

5.1 标记-清除算法

标记的过程是：遍历所有的 GC Roots，然后将所有 GC Roots 可达的对象标记为存活的对象。

清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。与此同时，清除那些被标记过的对象的标记，以便下次的垃圾回收。

这种方法有两个不足：

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

5.2 复制算法（新生代）

为了解决效率问题，“复制”收集算法出现了。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完，需要进行垃圾收集时，就将存活者的对象复制到另一块上面，然后将第一块内存全部清除。这种算法有优有劣：

• 优点：不会有内存碎片的问题。
• 缺点：内存缩小为原来的一半，浪费空间。

为了解决空间利用率问题，可以将内存分为三块： Eden、From Survivor、To Survivor，比例是 8:1:1，每次使用 Eden 和其中一块 Survivor。回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才使用的 Survivor 空间。这样只有 10% 的内存被浪费。

但是我们无法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够，需要依赖其他内存（指老年代）进行分配担保。

5.3 标记-整理算法（老年代）

标记：它的第一个阶段与标记-清除算法是一模一样的，均是遍历 GC Roots，然后将存活的对象标记。

整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。

这是一种老年代的垃圾收集算法。老年代的对象一般寿命比较长，因此每次垃圾回收会有大量对象存活，如果采用复制算法，每次需要复制大量存活的对象，效率很低。

5.4 分代收集算法

根据对象存活周期的不同，将内存划分为几块。一般是把 Java 堆分为新生代和老年代，针对各个年代的特点采用最适当的收集算法。

• 新生代：复制算法
• 老年代：标记-清除算法、标记-整理算法

---

四、HotSpot 垃圾收集器

HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。

1. 新生代垃圾收集器

1.1 Serial 垃圾收集器（单线程）

只开启一条 GC 线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程，即 Stop The World。

一般客户端应用所需内存较小，不会创建太多对象，而且堆内存不大，因此垃圾收集器回收时间短，即使在这段时间停止一切用户线程，也不会感觉明显卡顿。因此 Serial 垃圾收集器适合客户端使用。

由于 Serial 收集器只使用一条 GC 线程，避免了线程切换的开销，从而简单高效。

1.2 ParNew 垃圾收集器（多线程）

ParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。

ParNew 追求“低停顿时间”,与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。

1.3 Parallel Scavenge 垃圾收集器（多线程）

Parallel Scavenge 和 ParNew 一样，都是多线程、新生代垃圾收集器。但是两者有巨大的不同点：

• Parallel Scavenge：追求 CPU 吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。
• ParNew：追求降低用户停顿时间，适合交互式应用。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

追求高吞吐量，可以通过减少 GC 执行实际工作的时间，然而，仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成，从而导致更高的暂停时间。而考虑到低暂停时间，最好频繁运行 GC 以便更快速完成，反过来又导致吞吐量下降。

• 通过参数 -XX:GCTimeRadio 设置垃圾回收时间占总 CPU 时间的百分比。
• 通过参数 -XX:MaxGCPauseMillis 设置垃圾处理过程最久停顿时间。
• 通过命令 -XX:+UseAdaptiveSizePolicy 开启自适应策略。我们只要设置好堆的大小和 MaxGCPauseMillis 或 GCTimeRadio，收集器会自动调整新生代的大小、Eden 和 Survivor 的比例、对象进入老年代的年龄，以最大程度上接近我们设置的 MaxGCPauseMillis 或 GCTimeRadio。

2. 老年代垃圾收集器

2.1 Serial Old 垃圾收集器（单线程）

Serial Old 收集器是 Serial 的老年代版本，都是单线程收集器，只启用一条 GC 线程，都适合客户端应用。它们唯一的区别就是：Serial Old 工作在老年代，使用“标记-整理”算法；Serial 工作在新生代，使用“复制”算法。

2.2 Parallel Old 垃圾收集器（多线程）

Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

2.3 CMS 垃圾收集器

CMS（Concurrent Mark Sweep，并发标记清除）收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。

• 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
• 并发标记：使用多条标记线程，与用户线程并发执行。此过程进行可达性分析，标记出所有废弃对象。速度很慢。
• 重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过程中新出现的废弃对象标记出来。
• 并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。这个过程非常耗时。

并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。

CMS 的缺点：

• 吞吐量低
• 无法处理浮动垃圾
• 使用“标记-清除”算法产生碎片空间，导致频繁 Full GC

对于产生碎片空间的问题，可以通过开启 -XX:+UseCMSCompactAtFullCollection，在每次 Full GC 完成后都会进行一次内存压缩整理，将零散在各处的对象整理到一块。设置参数 -XX:CMSFullGCsBeforeCompaction 告诉 CMS，经过了 N 次 Full GC 之后再进行一次内存整理。

3. G1 通用垃圾收集器

G1 收集器的工作原理

G1收集器是一种基于 “标记-整理” 算法和 “复制” 算法相结合的垃圾收集器。它将整个Java堆划分为多个大小相等的独立区域（Region），这些区域可以是新生代（Eden区、Survivor区）或老年代。但与传统收集器不同，G1并不要求新生代和老年代在物理上是连续的，它们只是由一组连续Region的集合组成。

1. 初始标记（Initial Marking）：暂停所有的应用线程（Stop-The-World，STW），并标记GC Roots能直接关联到的对象。

2. 并发标记（Concurrent Marking）：从GC Roots开始对堆中对象进行可达性分析，找出存活的对象。该阶段耗时较长，但可以与应用程序并发执行。

3. 最终标记（Final Marking）：再次暂停所有应用线程，进行最终的标记工作，修正因并发标记期间应用程序继续运行而导致标记产生变动的那一部分对象的标记记录。

4. 筛选回收（Live Data Counting and Evacuation）：

   • 对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。
   • 复制存活对象到新的Region中，然后清理掉整个旧Region的全部空间。这里的操作涉及到了内存空间的整合，所以G1收集器收集各个Region时仍然需要暂停所有应用线程（STW）。

G1 收集器的特点

1. 并行与并发：

   • G1能充分利用多CPU、多核环境下的硬件优势，使用多个GC线程（与用户线程并行）来缩短Stop-the-world停顿的时间。
   • 部分其他收集器原本需要停顿java线程执行的GC动作，G1收集器扔可通过并发的方式让java程序继续执行。

2. 分代收集：

   • G1依然保留了新生代和老年代的概念，但它不再坚持固定大小和固定数量的分代区域划分。
   • 它同时兼顾年轻代和老年代，通过优先级列表来决定GC需要收集的Region。

3. 可预测的停顿：

   • G1收集器建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

4. 空间整合：

   • G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“复制”算法实现，不会产生内存碎片。

5. 可设置的并行度：

   • G1允许用户设置并行度，来控制垃圾收集的线程数。

G1 收集器的使用建议

1. 对于需要控制停顿时间，并且希望避免内存碎片的Java应用，G1是一个很好的选择。
2. 在拥有多CPU和大内存的服务器环境中，G1的性能表现通常很好。
3. 通过调整G1的相关参数（如-XX:MaxGCPauseMillis、-XX:G1HeapRegionSize等），可以进一步优化其性能。

请注意，虽然G1收集器具有很多优点，但在某些特定场景下，其他收集器（如Parallel Scavenge、CMS或ZGC）可能更为适合。因此，在选择垃圾收集器时，需要根据具体的应用场景和需求来进行决策。

一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？
并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上 Remembered Set 即可防止对整个堆内存进行遍历。

4. CMS 与 G1 的区别

G1收集器和CMS收集器在Java虚拟机（JVM）中都是用于管理内存和进行垃圾回收的，但它们之间存在一些显著的差异。以下是两者之间的主要区别：

1. 算法和碎片处理：

   • CMS收集器：使用“标记-清除”算法进行垃圾回收，这意味着在垃圾回收过程中，CMS会标记出不再使用的对象，然后清除这些对象所占用的内存空间。然而，这种算法可能会产生内存碎片，因为被清除的对象可能分散在内存的各个角落，导致难以找到连续的大块内存空间供新对象使用。
   • G1收集器：则使用“标记-整理”算法，该算法在标记出不再使用的对象后，会将这些对象“整理”到内存的一端，从而消除内存碎片。这使得G1能够更有效地利用内存空间，对于长时间运行的应用系统来说非常重要。

2. 停顿时间控制：

   • CMS收集器：以最小的停顿时间为目标，但它并不能精确地预测和控制垃圾回收的停顿时间。在某些情况下，CMS可能会因为内存碎片过多而触发Full GC，导致长时间的停顿。
   • G1收集器：则具有可预测的停顿时间模型。它允许用户明确指定一个时间片段（如M毫秒），并在这个时间片段内，G1会尽量将垃圾回收的停顿时间控制在用户指定的范围内（如N毫秒）。这使得G1能够更好地满足实时性要求较高的应用系统的需求。

3. 内存管理策略：

   • CMS收集器：将内存分为新生代和老年代，并在新生代和老年代之间使用串行或并行的方式进行垃圾回收。然而，CMS在回收老年代时仍需要暂停所有的应用线程（Stop-The-World）。
   • G1收集器：则采用了不同的内存管理策略。它将整个Java堆划分为多个大小相等的独立区域（Region），并跟踪这些区域中的垃圾堆积程度。G1会优先回收垃圾最多的区域，以尽量降低垃圾回收的停顿时间。此外，G1还支持并发地进行新生代和老年代的垃圾回收，从而进一步减少了对应用线程的影响。

4. 适用场景：

   • CMS收集器：由于其以最小的停顿时间为目标，因此适用于那些对实时性要求较高的应用系统，如Web服务器等。但是，CMS可能会因为内存碎片过多而触发Full GC，导致性能下降。
   • G1收集器：则适用于那些需要长时间运行且对内存使用效率有较高要求的应用系统，如大型数据库、云计算平台等。G1能够有效地减少内存碎片，并提高内存使用效率，从而支持这些系统的长时间稳定运行。

总的来说，G1收集器和CMS收集器在算法、停顿时间控制、内存管理策略和适用场景等方面都存在显著的差异。在选择使用哪种收集器时，需要根据具体的应用场景和需求来进行决策。

5. CMS与G1的三色标记

JVM（Java Virtual Machine）中的 三色标记（Tri-color Marking） 是一种用于实现垃圾收集器（如CMS、G1等）中对象标记阶段的技术。在垃圾收集过程中，为了确定哪些对象是可以被回收的（即不再被引用），JVM需要对堆中的所有对象进行标记。三色标记法是一种高效的标记算法，它通过将对象分为三种颜色来追踪对象的可达性。

三色标记中的三种颜色分别是：

1. 白色（White）：表示对象尚未被垃圾收集器访问过。在初始阶段，所有的对象都是白色的，因为垃圾收集器还没有开始工作。在标记过程中，如果一个白色的对象被另一个对象引用，那么它会被涂成灰色。
2. 灰色（Gray）：表示对象已经被垃圾收集器访问过，但它的所有子对象（即它引用的对象）还没有完全被访问。垃圾收集器会继续追踪灰色对象的子对象，将它们从白色涂成灰色，直到所有子对象都被访问过。此时，灰色对象会变成黑色。
3. 黑色（Black）：表示对象已经被垃圾收集器访问过，且它的所有子对象也都被访问过（即已涂成黑色）。黑色对象不会被垃圾收集器再次访问，因为它们的可达性已经确定。

三色标记算法的基本流程是：

1. 从GC Roots（如静态变量、栈中的引用等）开始，将所有直接引用的对象涂成灰色。
2. 遍历灰色对象，将其子对象涂成灰色，并将自己涂成黑色。
3. 重复第2步，直到没有灰色对象为止。
4. 此时，所有白色对象都是不可达的，可以被垃圾收集器回收。

三色标记法的主要优点是其高效的并行性。在垃圾收集过程中，多个线程可以同时处理灰色对象，从而加速标记过程。但是，三色标记法也需要注意“浮动垃圾”（Floating Garbage）和“对象丢失”（Object Loss）的问题。浮动垃圾是指在标记过程中新产生的垃圾，它们不会被本次垃圾收集回收。对象丢失则是指由于并发标记过程中对象的引用关系发生变化，导致一些本应被回收的对象被错误地保留下来。为了避免这些问题，JVM中的垃圾收集器通常还需要采取其他策略，如增量更新（Incremental Update）和原始快照（Snapshot-At-The-Beginning, SATB）等。

---

五、内存分配与回收策略

对象的内存分配，就是在堆上分配（也可能经过 JIT 编译后被拆散为标量类型并间接在栈上分配），对象主要分配在新生代的 Eden 区上，少数情况下可能直接分配在老年代，分配规则不固定，取决于当前使用的垃圾收集器组合以及相关的参数配置。

以下列举几条最普遍的内存分配规则，供大家学习。

1. 对象优先在 Eden 分配

大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

Minor GC、Major GC、Full GC

Minor GC、Major GC 和 Full GC 是 Java 虚拟机（JVM）中的三种不同类型的垃圾回收（Garbage Collection，简称 GC）操作，它们各自针对 JVM 内存的不同区域进行垃圾回收。

1. Minor GC（新生代 GC）

   • Minor GC 是指对新生代（Young Generation）进行的垃圾回收。新生代是 JVM 内存中用于存放新创建对象的区域，这些对象在创建后很快可能会变得不可达并被回收，因此新生代的对象存活时间通常很短。
   • Minor GC 的主要目标是清理掉不再被引用的对象，并将存活的对象通过复制算法（Copying Algorithm）移到 Survivor 区或直接晋升到老年代（Old Generation）。
   • 当 Eden 区（新生代中的一个区域）内存满时，会触发 Minor GC。

2. Major GC（老年代 GC）

   • Major GC 是指对老年代（Old Generation）进行的垃圾回收。老年代用于存放存活时间较长的对象。
   • Major GC 的频率通常低于 Minor GC，因为老年代中的对象存活时间较长。
   • 当老年代空间不足时，可能会触发 Major GC，或者在某些垃圾回收器（如 CMS）中，Minor GC 后也可能触发 Major GC。

3. Full GC（完全垃圾回收）

   • Full GC 是指对整个 Java 堆（包括新生代和老年代）进行的垃圾回收。
   • Full GC 的开销通常较大，因为它需要扫描整个堆内存，并尝试回收所有不可达的对象。
   • Full GC 可能会导致程序暂停（Stop-The-World），因为垃圾回收器需要独占整个 JVM 进程，停止其他所有线程的执行。
   • Full GC 的触发条件可能包括：老年代空间不足、永生代（PermGen，在 Java 8 之后被元空间 Metaspace 替代）空间不足、显式调用 System.gc() 方法等。

2. 大对象直接进入老年代

大对象是指需要大量连续内存空间的 Java 对象，如很长的字符串或数据。

一个大对象能够存入 Eden 区的概率比较小，发生分配担保的概率比较大，而分配担保需要涉及大量的复制，就会造成效率低下。

虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制。（还记得吗，新生代采用复制算法回收垃圾）

3. 长期存活的对象将进入老年代

JVM 给每个对象定义了一个对象年龄计数器。当新生代发生一次 Minor GC 后，存活下来的对象年龄 +1，当年龄超过一定值时，就将超过该值的所有对象转移到老年代中去。

使用 -XXMaxTenuringThreshold 设置新生代的最大年龄，只要超过该参数的新生代对象都会被转移到老年代中去。

4. 动态对象年龄判定

如果当前新生代的 Survivor 中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。

5. 空间分配担保

JVM的分配担保，或称为空间分配担保机制，是Java虚拟机（JVM）内存管理中的一个关键组成部分，特别是在进行垃圾回收（GC）时。这个机制的核心在于确保在Minor GC（新生代垃圾回收）时，新生代中的存活对象能够成功晋升到老年代。

具体地说，当新生代（包括Eden区和两个Survivor区）中的对象无法全部存活时，JVM会进行Minor GC来回收Eden区和Survivor区的垃圾对象。但在进行Minor GC之前，JVM会先检查老年代中的剩余空间是否大于新生代所有对象的总空间。如果大于，则此次Minor GC是安全的；如果小于，则JVM会考虑几种策略：

1. 如果HandlePromotionFailure设置值为true，JVM会进一步检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于，则改为进行一次Full GC（全堆垃圾回收）。
2. 如果HandlePromotionFailure设置值为false，或者老年代空间不足以容纳新生代晋升的对象，JVM会直接触发一次Full GC。

这种分配担保机制的主要目的是确保JVM在进行垃圾回收时，能够有足够的内存空间来创建新对象，同时清理不再使用的对象，以保持内存的高效使用和程序的稳定运行。

---

六、JVM 性能调优

在高性能硬件上部署程序，目前主要有两种方式：

• 通过 64 位 JDK 来使用大内存；
• 使用若干个 32 位虚拟机建立逻辑集群来利用硬件资源。

1. 使用 64 位 JDK 管理大内存

堆内存变大后，虽然垃圾收集的频率减少了，但每次垃圾回收的时间变长。 如果堆内存为 14 G，那么每次 Full GC 将长达数十秒。如果 Full GC 频繁发生，那么对于一个网站来说是无法忍受的。

对于用户交互性强、对停顿时间敏感的系统，可以给 Java 虚拟机分配超大堆的前提是有把握把应用程序的 Full GC 频率控制得足够低，至少要低到不会影响用户使用。

可能面临的问题：

• 内存回收导致的长时间停顿；
• 现阶段，64 位 JDK 的性能普遍比 32 位 JDK 低；
• 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为要产生超过 10GB 的 Dump 文件），哪怕产生了快照也几乎无法进行分析；
• 相同程序在 64 位 JDK 消耗的内存一般比 32 位 JDK 大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的。

2. 使用 32 位 JVM 建立逻辑集群

在一台物理机器上启动多个应用服务器进程，每个服务器进程分配不同端口， 然后在前端搭建一个负载均衡器，以反向代理的方式来分配访问请求。

考虑到在一台物理机器上建立逻辑集群的目的仅仅是为了尽可能利用硬件资源，并不需要关心状态保留、热转移之类的高可用性能需求， 也不需要保证每个虚拟机进程有绝对的均衡负载，因此使用无 Session 复制的亲合式集群是一个不错的选择。 我们仅仅需要保障集群具备亲合性，也就是均衡器按一定的规则算法（一般根据 SessionID 分配） 将一个固定的用户请求永远分配到固定的一个集群节点进行处理即可。

可能遇到的问题：

• 尽量避免节点竞争全局资源，如磁盘竞争，各个节点如果同时访问某个磁盘文件的话，很可能导致 IO 异常；
• 很难高效利用资源池，如连接池，一般都是在节点建立自己独立的连接池，这样有可能导致一些节点池满了而另外一些节点仍有较多空余；
• 各个节点受到 32 位的内存限制；
• 大量使用本地缓存的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点都有一份缓存，这时候可以考虑把本地缓存改成集中式缓存。

3. 调优案例分析与实战

3.1 场景描述

一个小型系统，使用 32 位 JDK，4G 内存，测试期间发现服务端不定时抛出内存溢出异常。 加入 -XX:+HeapDumpOnOutOfMemoryError（添加这个参数后，堆内存溢出时就会输出异常日志）， 但再次发生内存溢出时，没有生成相关异常日志。

3.2 分析

在 32 位 JDK 上，1.6G 分配给堆，还有一部分分配给 JVM 的其他内存，直接内存最大也只能在剩余的 0.4G 空间中分出一部分， 如果使用了 NIO，JVM 会在 JVM 内存之外分配内存空间，那么就要小心“直接内存”不足时发生内存溢出异常了。

3.3 直接内存的回收过程

直接内存虽然不是 JVM 内存空间，但它的垃圾回收也由 JVM 负责。

垃圾收集进行时，虚拟机虽然会对直接内存进行回收， 但是直接内存却不能像新生代、老年代那样，发现空间不足了就通知收集器进行垃圾回收， 它只能等老年代满了后 Full GC，然后“顺便”帮它清理掉内存的废弃对象。 否则只能一直等到抛出内存溢出异常时，先 catch 掉，再在 catch 块里大喊 “System.gc()”。 要是虚拟机还是不听，那就只能眼睁睁看着堆中还有许多空闲内存，自己却不得不抛出内存溢出异常了。

---