个人笔记，深入理解 JVM，很全（终于有人把JVM说清楚了）

01、前言

刷豆瓣看到《深入理解 JVM》出第三版了，遂买之更新 JVM 知识，本文为笔记，仅供个人 Review

02、Java 内存区域与内存溢出

03、运行时数据区域

参考：JVM 规范，Memories of a Java Runtime

堆：JVM 启动时按-Xmx, -Xms大小创建的内存区域，用于分配对象、数组所需内存，由 GC 管理和回收

方法区：存储被 JVM 加载的类信息（字段、成员方法的字节码指令等）、运行时常量池（字面量、符号引用等）、JIT 编译后的 Code Cache 等信息；JDK8 前 Hotspot 将方法区存储于永久代堆内存，之后参考 JRockit 废弃了永久代，存储于本地内存的 Metaspace 区

直接内存：JDK1.4 引入 NIO 使用 Native/Unsafe 库直接分配系统内存，使用 Buffer,Channel 与其交互，避免在系统内存与 JVM 堆内存之间拷贝的开销

线程私有内存

• 程序计数器：记录当前线程待执行的下一条指令位置，上下文切换后恢复执行，由字节码解释器负责更新
• JVM 栈
• 描述 Java 方法执行的内存模型：执行新方法时创建栈帧，存储局部变量表、操作数栈等信息
• 存储单位：变量槽 slot，long, double占 2 个 slot，其他基本数据类型、引用类型占 1 个，故表的总长度在编译期可知
• 本地方法栈：执行本地 C/C++ 方法

---

04、JVM 对象

1. 创建对象

分配堆内存：类加载完毕后，其对象所需内存大小是确定的；堆内存由多线程共享，若并发创建对象都通过 CAS 乐观锁争夺内存，则效率低。故线程创建时在堆内存为其分配私有的分配缓冲区（TLAB：Thread Local Allocation Buffer）

• 内存模型

• 分配流程

注：当 TLAB 剩余空间不足以分配新对象，但又小于最大浪费空间阈值时，才会加锁创建新的 TLAB

零值初始化对象的堆内存、设置对象头信息、执行构造函数 ()V

2. 对象的内存布局

对象头

• Mark Word：记录对象的运行时信息，如 hashCode，GC 分代年龄，尾部 2 bit 用于标记锁状态

• Class Pointer：指向所属的类信息
• 数组长度（可选，对象为数组）：4 字节存储其长度

对象数据：各种字段的值，按宽度分类紧邻存储

对齐填充：内存对齐为 1 个字长整数倍，减少 CPU 总线周期

验证：openjdk/jol 检查对象内存布局

public class User {
private int age = -1;
private String name = "unknown";
}

// java -jar ~/Downloads/jol-cli-latest.jar internals -cp . com.jol.User
OFF  SZ               TYPE DESCRIPTION               VALUE
0   8                    (object header: mark)     0x0000000000000001 (non-biasable; age: 0)
8   4                    (object header: class)    0xf8021e85 // User.class 引用地址
 12   4                int User.age                  -1         // 基本类型则直接存储值
 16   4   java.lang.String User.name                 (object)   // 引用类型，指向运行时常量池中的 String 对象
 20   4                    (object alignment gap)               // 有 4 字节的内存填充
Instance size: 24 bytes

---

05、内存溢出

堆内存：-Xms指定堆初始大小，当大量无法被回收的对象所占内存超出-Xmx上限时，将发生内存溢出 OutOfMemoryError

• 排查：通过 Eclipse MAT 分析 -XX:+HeapDumpOnOutOfMemory生成的 *.hprof 堆转储文件，定位无法被回收的大对象，找出其 GC Root 引用路径
• 解决：若为内存泄露，则修改代码用null显式赋值、虚引用等方式及时回收大对象；若为内存溢出，大对象都是必须存活的，则调大-Xmx、减少大对象的生命周期、检查数据结构使用是否合理等

// -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
public class HeapOOM {
 static class OOMObject {}
 public static void main(String[] args) {
  List<OOMObject> vs = new ArrayList<>();
  while (true)
     vs.add(new OOMObject());
 }
}

分析 GC Root 发现com.ch02.HeapOOM对象间接引用了大量的OOMObject对象，共占用 15.4MB 堆内存，无法回收最终导致 OOM

栈内存：-Xss指定栈大小，当栈深度超阈值（比如未触发终止条件的递归调用）、本地方法变量表过大等，都可能导致内存溢出 StackOverflowError

方法区：-XX:MetaspaceSize指定元空间初始大小，-XX:MaxMetaspaceSize指定最大大小，默认 -1 无限制，若在运行时动态生成大量的类，则可能触发 OOM

运行时常量池：strObj.intern()动态地将首次出现的字符串对象放入字符串常量池并返回，JDK7 前会拷贝到永久代，之后则直接引用堆对象

String s1 = "java"; // 类加载时，从字节码常量池中拷贝符号到了运行时常量池，在解析阶段初始化的字符串对象
String s2 = "j";
String s3 = s2 + "ava"; // 堆上动态分配的字符串对象
println(s3 == s1);          // false
println(s3.intern() == s1); // true // 已在字符串常量池中存在

直接内存：-XX:MaxDirectMemorySize指定大小，默认与-Xmx一样大，不被 GC 管理，申请内存超阈值时 OOM

---

06、垃圾回收与内存分配

GC 可分解为 3 个子问题：which（哪些内存可被回收）、when（什么时候回收）、how（如何回收）

07、GC 条件

1. 引用计数算法（reference counting）

原理：每个对象都维护一个引用计数器rc，当通过赋值、传参等方式引用它时rc++，当引用变量修改指向、离开函数作用域等方式解除引用时rc--，递减到 0 时说明对象无法再被使用，可回收。伪代码：

assign(var, obj):
incr_ref(obj) # self = self # 先增再减，避免引用自身导致内存提前释放
decr_ref(var)
var = obj
 
incr(obj):
obj.rc++

decr(obj):
obj.rc--
if obj.rc == 0:
  remove_ref(obj) # 断开 obj 与其他对象的引用关系
  gc(obj)         # 回收 obj 内存

优点：思路简单，对象无用即回收，延迟低，适合内存少的场景

缺点：此算法中对象是孤立的，无法在全局视角检查对象的真实有效性，循环引用的双方对象需引入外部机制来检测和回收，如下图红色圈（图源：what-is-garbage-collection）

2. 可达性分析算法（reachability analysis）

原理：从肯定不会被回收的对象（GC Roots）出发，向外搜索全局对象图，不可达的对象即无法再被使用，可回收；常见可作为 GC Root 的对象有：

• 执行上下文：JVM 栈中参数、局部变量、临时变量等引用的堆对象
• 全局引用：方法区中类的静态引用、常量引用（如 StringTable 中的字符串对象）所指向的对象

优点：无需对象维护 GC 元信息，开销小；单次扫描即可批量识别、回收对象，吞吐高

缺点：多线程环境下对象间的引用关系随时在变化，为保证 GC Root 标记的准确性，需在不变化的 snapshot 中进行，会产生 Stop The World（以下简称 STW） 卡顿现象

3. 四种引用类型

引用类型类回收时机强引用-只要与 GC Root 存在引用链，则不被回收软引用SoftReference只被软引用所引用的对象，当 GC 后内存依然不足，才被回收弱引用WeakReference只被弱引用所引用的对象，无论内存是否足够，都将被回收虚引用PhantomReference被引用的对象无感知，进行正常 GC，仅在回收时通知虚引用（回调）

示例：限制堆內存 50MB，其中新生代 30MB，老年代 20MB；依次分配 5 次 10MB 的byte[]对象，仅使用软引用来引用，观察 GC 过程

public static void main(String[] args) {
// softRefList --> SoftReference --> 10MB byte[] 
List<SoftReference<byte[]>> softRefList = new ArrayList<>();
ReferenceQueue<byte[]> softRefQueue = new ReferenceQueue<>(); // 无效引用队列
for (int i = 0; i < 5; i++) {
  SoftReference<byte[]> softRef = new SoftReference<>(new byte[10*1024*1024], softRefQueue);
  softRefList.add(softRef);

  for (SoftReference<byte[]> ref : softRefList) // dump 所有软引用指向的对象，检查是否已被回收
      System.out.print(ref.get() == null ? "gced " : "ok ");
  System.out.println();
}
Reference<? extends byte[]> ref = softRefQueue.poll();
while (ref != null) {
  softRefList.remove(ref); // 解除对软引用对象本身的引用
  ref = softRefQueue.poll();
}
System.out.println("effective soft ref: " + softRefList.size()); // 2
}

// java -verbose:gc -XX:NewSize=30m -Xms50m -Xmx50m -XX:+PrintGCDetails com.ch02.DemoRef
ok 
ok ok 
// 分配第三个 []byte 时，Eden GC 无效，触发 Full GC 将一个 []byte 晋升到老年区
// 此时三个 byte[] 都只被软引用所引用，被标记为待二次回收（若为弱引用，此时 Eden 已被回收）
[GC (Allocation Failure) --[PSYoungGen: 21893K->21893K(27136K)] 21893K->32141K(47616K), 0.0046324 secs]
[Full GC (Ergonomics) [PSYoungGen: 21893K->10527K(27136K)] [ParOldGen: 10248K->10240K(20480K)] 32141K->20767K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.004 secs]
ok ok ok
// 再次 GC，前三个 byte[] 全部被回收
[GC (Allocation Failure) --[PSYoungGen: 20767K->20767K(27136K)] 31007K->31007K(47616K), 0.0007963 secs]
[Full GC (Ergonomics) [PSYoungGen: 20767K->20759K(27136K)] [ParOldGen: 10240K->10240K(20480K)] 31007K->30999K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.003 secs]
[GC (Allocation Failure) --[PSYoungGen: 20759K->20759K(27136K)] 30999K->30999K(47616K), 0.0007111 secs]
[Full GC (Allocation Failure) [PSYoungGen: 20759K->0K(27136K)] [ParOldGen: 10240K->267K(20480K)] 30999K->267K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.003 secs]
gced gced gced ok
gced gced gced ok ok

4. finalize

原理：若对象不可达，被标记为可回收后，会进行finalize()是否被重写、是否已执行过等条件筛选，若通过则对象会被放入 F-Queue 队列，等待低优先级的后台 Finalizer 线程触发其finallize() 的执行（不保证执行结束），对象可在finalize中建立与 GC Root 对象图上任一节点的引用关系，来逃脱 GC

使用：finalize 机制与 C++ 中的析构函数并不等价，其执行结果并不确定，不推荐使用，可用try-finally替代

---

08、GC 算法

分代收集理论

两个分代假说：符合大多数程序运行的实际情况

• 弱分代假说：绝大多数对象是朝生夕灭，生存时间极短
• 强分代假说：熬过越多次 GC 的对象，越可能被继续使用，越难以回收

对应地，JVM 堆被划分为 2 个不同区域，将对象按年龄分类，兼顾了 GC 耗时与内存利用率