夢の終着駅

（1）局部变量表#

方法参数和方法体内定义的局部变量，数据类型包括基本类型、对象引用和返回地址。编译期确定大小，以变量槽（Slot） 为最小单位。

如果是非静态方法的话第0位slot存储的是this引用，然后存储参数，最后再存局部变量。静态方法的话就直接从存储参数开始即可。

如果一个变量的作用域结束后，后续的新变量可直接覆盖复用该变量使用的slot。

需要注意的一点时，当局部变量作用域结束后，只有该变量所占用的slot被复用后，该变量的强引用依旧有效，不会被识别为无用变量，因此就算手动执行GC也无法释放该变量引用。 也就是说，如果想要回收非作用域的变量时，需要声明新变量复用slot或者声明该变量为null。 可能有同学还没听懂，让我们引入一个案例： public static void main(String[] args) { { byte[] placeholder = new byte[64 * 1024 * 1024]; } // 此时placeholder的引用仍旧有效，不会被释放 System.gc(); }一键获取完整项目代码java运行 public static void main(String[] args) { { byte[] placeholder = new byte[64 * 1024 * 1024]; // 可以手动释放引用 //placeholder = null; } // 也可以复用slot表示placeholder的引用已无效让GC释放 int a = 0; System.gc();}一键获取完整项目代码java运行 还需要注意复用slot仅发生在同一方法作用域内，即同一个栈帧内。 这个比较好理解，因为每个栈帧的局部变量表独立。

（2）操作数栈#

每个栈帧都有一个独立的操作数栈，用于数据暂存，遵守先进后出原则。

让我们梳理一下关系：每个JVM都有一个虚拟机栈，每个虚拟机栈存放栈帧，每个栈帧又有一个操作数栈，而操作数栈存放的是数据。 虚拟机栈和操作数栈都是遵守先进后出原则的容器，因此二者都可能发生栈溢出问题。

关于操作数栈的执行流程，我们引入一个案例来进行讲解：

1
int c = a + b;

 这一行代码反编译成字节码指令的话一共分为4步：

1. iload_1: 把第1位的slot的变量a取出，压进操作数栈
2. iload_2: 把第2位的slot的变量b取出，压进操作数栈
3. iadd: 这一步里面又分成4步：
4. 将栈顶b弹出
5. 将栈顶a弹出
6. 让a和b在CPU的算术逻辑单元里计算
7. 将结果压进栈内
8. istore_3: 将栈顶的结果弹出，放入第3位的slot，也就是赋值给c

不难发现，操作数栈是用于字节码指令进行交互的核心容器，因此被称作为JVM执行引擎的“心脏”。

（1）StackOverflowError#

正如我们上面所说，导致StackOverflowError存在两种情况：

• 虚拟机栈空间溢出：未设置递归结束条件或过度递归导致过量的栈帧塞满了虚拟机栈
• 操作数栈空间溢出：一行语句中使用过多的变量参与计算导致需要存储的数据过量塞满了操作数栈

其中操作数栈空间溢出的概率很小，应该说几乎不可能发生。

而解决方案两者也不尽相同：

• 对操作进行拆分：虚拟机栈将递归拆解成循环来保证单栈帧；操作数栈则需要将一行语句使用多个局部变量进行拆解
• 扩大栈空间

（2）OutOfMemory#

这个异常主要是因为局部变量表的空间溢出问题，也就是我们使用了超大数组或者过多局部变量导致的。

解决方案也很简单：

• 用new关键字声明超大数组，将其存储在堆内存空间当中
• 扩大栈帧空间
• 减少局部变量个数，尽量合并作用域

需要注意的是，栈溢出所抛出的StackOverflowError是无法被try-catch代码块所捕获的，因为catch块执行是需要一个新的栈帧的，而此时虚拟机栈已经无法容纳新的栈帧，因此该异常无法被捕获。 所以我们尽量在开发阶段就避免该问题，不然在生产环境下可能会引发严重事故……

（1）TLAB分配#

当并发场景下，多线程共享堆内存并对Eden区进行操作，这必然是线程不安全的，但如果加锁的话会大幅度降低性能，因为对堆的操作是极其频繁的。

为解决该问题，JVM为每个线程分配独立的TLAB空间（默认占Eden 1%）。

每当线程要new一个新对象时，会先将对象实例存储在自己的TLAB空间中，倘若空间不足则会申请新的TLAB空间进行分配，如果无法分配新的TLAB空间，此时才会对Eden区进行加锁然后将对象实例存储在Eden区当中。

如果TLAB空间私有，那如何确保该对象多线程共享？ TLAB空间也是Eden区的一部分，私有表示只有持有线程可对其写入，但读权限依旧是所有线程共享。

（2）逃逸分析与标量替换#

三种逃逸状态：

关于逃逸分析的详细内容在之前的JUC篇有讲到，这里主要讲解栈上分配的优化。 带你轻松学习JUC-CSDN博客https://blog.csdn.net/2401_88959292/article/details/149500338?spm=1001.2014.3001.5501

当对象被逃逸分析判定为未逃逸时，JVM会触发标量替换：

将对象拆解为独立的基本类型变量，拆解后的变量直接压进栈帧的操作数栈中，而非局部变量表。然后擦除对象头指针类型信息，原对象不再以整体形式存在。

对于栈上分配策略，HotSpot虚拟机是没有实现的，因为局部变量表仅能存储标量，无法存储引用对象，而且对象包含对象头，所占用空间通常更大，容易无法存入碎片空间导致栈溢出。

因此HotSpot仅采用了标量替换策略。

引入案例来更直观的理解一下：

1
// 原始代码
2
Point p = new Point(1, 2);
3
return p.x + p.y;
4

5
// 标量替换后 → 直接使用基本变量
6
int x = 1, y = 2;
7
return x + y;

（1）运行时常量池 & 类文件常量池#

• **类文件常量池：**存在于编译后的字节码文件中，存储字面量（文本字符串、final常量等）和符号引用（类/接口全限定名、字段/方法描述符）。
• **运行时常量池：**类加载时，类文件常量池的内容存入方法区的运行时常量池。它存储符号引用解析后的直接引用，每个类独立拥有一个运行时常量池

（2）符号引用转直接引用#

符号引用其实指的是用文本形式描述引用地址，比如“java/lang/Object”，这种形式在编译阶段无法确定实际地址，因此在类加载阶段就会将符号引用解析成直接引用放入运行时常量池，而直接引用就是指向地址的指针或者内存地址偏移量。

（1）常见双等号判断问题#

注意以下场景JDK均为8及以后，即7+。

1
String s1 = "abc";          // 常量池引用
2
String s2 = new String("abc"); // 堆中新对象
3
System.out.println(s1 == s2); // false

一个引用在常量池一个在堆内存中，内存地址不一样结果肯定是false。

1
String s1 = new String("a") + new String("b"); // 堆中对象"ab"（常量池无"ab"）
2
s1.intern();  // 将堆中"ab"的引用存入常量池
3
String s2 = "ab";  // 指向常量池引用（即s1的堆地址）
4
System.out.println(s1 == s2); // true

 这里需要注意JDK7前后intern()的区别：

• JDK7之前，intern()是会深拷贝一个新的字符串，将其引用存入常量池
• JDK7+则是浅拷贝原字符串到常量池

因此该场景下如果是JDK7之前的话结果就会是false。

1
String s1 = "a" + "b";      // 编译期优化为 "ab"
2
String s2 = "ab";           // 常量池引用
3
System.out.println(s1 == s2); // true

编译期会将字面量拼接自动优化为拼接完成后的。

1
String s1 = "a";
2
String s2 = "b";
3
String s3 = s1 + s2;        // 等同于 new StringBuilder().append(s1).append(s2).toString()
4
String s4 = "ab";
5
System.out.println(s3 == s4); // false

 而变量拼接，由于编译期无法确定变量具体值，因此无法像字面量拼接那样直接优化，会使用StringBuilder直接动态拼接并存入堆内存中。

1
final String s1 = "a";
2
final String s2 = "b";
3
String s3 = s1 + s2;        // 编译期优化为 "ab"
4
String s4 = "ab";
5
System.out.println(s3 == s4); // true

但如果变量被final修饰的话，则会转化为常量，因此可以被直接优化。

1
String s1 = "ab";          // 常量池生成"ab"
2
String s2 = new String("ab");
3
String s3 = s2.intern();    // 返回常量池已有引用
4
System.out.println(s1 == s3); // true
5
System.out.println(s2 == s3); // false

 这个很简单，不做说明了。

1
String s1 = new String("a") + new String("b"); // 堆中对象"ab"（常量池无"ab"）
2
String s2 = "ab";          // 常量池新建"ab"
3
System.out.println(s1 == s2); // false

 一个堆内存一个常量池，结果肯定为false。

1
String s1 = "abc";      // 常量池对象
2
String s2 = s1.substring(0,3); // 堆中新对象
3
System.out.println(s1 == s2); // false

这里也跟JDK版本有关：

• JDK7之前，substring是会直接引用原字符串的char[]
• JDK7+则是深拷贝一份到堆内存中

因此如果在JDK7之前的话结果则为true。

1
String s1 = new String("abc");  // 堆对象
2
s3.intern();                    // 入池
3
String s2 = "abc";              // 常量池引用
4
System.out.println(s1 == s2);   // false
5

6
// 对比：未显式使用字面量
7
char[] c = {'a','b','c'};
8
String s3 = new String(c);      // 堆对象
9
s3.intern();                    // 入池
10
String s4 = "abc";              // 指向s3的堆地址
11
System.out.println(s3 == s4);   // true

 注意如果new的构造方法里用的是字面量，则会先将该字面量字符串引用存入常量池，但赋值的对象的引用仍在堆内存当中，因此此时就算入池也无法成功，因为常量池里已有该字符串的引用了，所以结果返回false。

（2）String去重#

A. intern()去重

在每次创建新字符串对象时都在后面调用intern()入池。

这样的话每次创建重复字符串时就会复用常量池中的引用。

B. G1去重

在Minor GC阶段中会扫描存活的String对象，并对年代已达一定数值的字符串对象哈希去重，其共享的是char[]，对象头是不会改变的。

需要配置-XX:+UseG1GC -XX:+UseStringDeduplication开启去重机制，去重年代阈值则需要通过-XX=3配置，默认为3。

（1）Serial收集器#

单线程串行收集，全程STW，采用复制算法。

是Client模式下的默认新生代收集器，适用于单核CPU或小内存场景。

简单高效，无线程交互竞争开销，但相对的执行效率低下，STW停顿时间长。

什么是Client模式？ Client模式是JVM的两种主要运行模式之一，另一种是Server模式。 特性Client模式Server模式启动速度快（轻量级编译） 慢（深度优化）长期性能较低 高（C2编译器深度优化）默认堆内存-Xms1M, -Xmx64M-Xms128M, -Xmx1024MGC策略串行GC（单线程）并行/并发GC（多线程）适用场景桌面应用、短任务服务器、大数据计算64位系统支持不支持默认 Client模式是JVM为快速启动和低内存场景设计的轻量级运行方案，但随着64位系统和云计算的普及，Server模式已成为主流。

（2）ParNew收集器#

Serial收集器的多线程并行版本，同样采用复制算法，需STW，是唯一能与收集器搭配的新生代回收器。

适合数据量不低的场景，需与CMS配合实现低停顿。

（3）Parallel Scavenge收集器#

吞吐量优先的多线程并行收集器，一样是复制算法。

可以动态调整新生代分区比例。

适合数据量大的对延迟不敏感场景。

（1）Serial Old收集器#

Serial的老年代版本，单线程串行，采用标记-整理算法。

是Client模式下的默认老生代收集器。

一般作为CMS失败的后备方案。

（2）Parallel Old收集器#

多线程并行，关注吞吐量，采用的也是标记-整理算法。

一般与Parallel Scavenge组合，适用于高吞吐需求的服务端。

（3）CMS收集器#

追求低延迟，采用标记-清除算法。

与ParNew搭配，适用于响应敏感系统。

回收一共有五个流程：

1. 初始标记（有STW）：
2. **任务：**标记所有GC Roots直接关联的对象，仅标记关联对象，不递归关联其引用链上的对象
3. **特点：**单线程执行，耗时极短
4. 并发标记（无STW）：
5. **任务：**从初始标记对象触发，递归关联其引用链上的所有对象，也就是整个老年代的对象。
6. **特点：**并发执行，耗时最长。通过三色标记法管理对象状态： 1. 黑色：对象及其引用已经被处理 2. 灰色：对象已被处理，但引用链还未被处理完全 3. 白色：未扫描对象
7. 可中断预清理（无STW）：
8. **任务：**等待一次Moinor GC以减少重新标记时的扫描量
9. 终止条件： 1. 执行超过5s 2. Eden区内存占用达50% 3. 发生了Minor GC
10. 重新标记（有STW）：
11. **任务：**重新扫描并发标记的对象，修正并发期间的引用变更
12. 并发清除（无STW）：
13. **任务：**释放标记对象引用

三大缺陷：

• CPU敏感：并发线程数公式(CPU+3)/4，可能抢占应用资源
• 浮动垃圾：需预留空间（默认老年代68%触发回收）
• 内存碎片：标记-清除算法导致，需Full GC整理

（1）G1收集器#

将堆划分为多个等大Region，物理不分代但逻辑保留分代。类似Kafka中一个Topic被划分为多个Partition，但不一样的是每个Region可以是Eden、Survivor、Old或Humongous角色。

Humongous区专门存储超过Region容量50%的大对象，若单个Region无法容纳，则分配连续多个Region存储。

每个Region维护了一个反向指针集合，叫做记忆集RSet，用于记录其他Region对本Region的引用，这样就无需递归遍历。

同时将Region划分为512字节的卡片，多个卡片的集合叫做卡表。通过字节数组记录脏卡（并发期间引用被修改），这样可快速进行重新标记。

G1的具体流程如下：

1. **初始标记（有STW）：**会趁着在Minor GC期间标记GC Roots直接关联对象
2. **并发标记（无STW）：**全局对象图遍历，使用SATB解决漏标

什么是SATB？ SATB（原始快照） 当用户线程删除灰色→白色对象的引用时，记录旧引用，最终标记阶段以旧引用为根扫描，保证白色对象不被误删。 而CMS采用的策略是增量更新：当用户线程新增黑色→白色对象的引用时，记录新引用，重新标记阶段以黑色对象为根重新扫描，避免漏标。 因此CMS每次更新标记都得全盘扫描，STW停顿时间随堆内存增大而增大；而G1只需要扫描已经变更的引用即可，停顿时间是可控的。

3. **最终标记（有STW）：**扫描SATB队列里的引用，进行变更
4. **筛选回收（有STW）：**按Region回收价值排序，选择收益高的Region复制清理
5. **复制收尾（有STW）：**复制存活对象到空闲Region，清空原Region

可以看到G1更适用于空间占用需求量较大、可控停顿要求的场景。

且相比CMS，G1不会产生内存碎片和浮动垃圾。

什么是浮动垃圾？  浮动垃圾指的是在并发标记阶段中用户线程产生的额外的可回收对象。 CMS中其并发标记与用户线程并行运行，增量更新仅解决漏标问题，无法处理引用断开后残留的无效对象，加之标记-清除算法不移动对象，导致浮动垃圾必然存在。 而G1通过SATB快照锁定标记开始时所有存活对象，写屏障拦截引用断开操作，复制算法隔离新旧对象，三者结合确保单次回收无残留。

（2）ZGC收集器#

ZGC抛弃了原有的分代垃圾回收算法，支持毫秒级可控停顿以及16TB超大堆内存，同时也吞吐量也十分可观。

其引入染色指针替代传统的对象头标记，一共有以下几种颜色：

优势：

• 省去对象头访问，GC 操作速度提升
• 对象转移后旧Region可立即释放，无需等待全局引用更新

除此之外还有读屏障自愈机制，当从堆内存中读取引用时，会先检查其染色指针颜色，如果是坏颜色就会通过转发表定位引用新地址并进行更新。

什么是坏颜色？ 指的是指针状态与当前GC周期不匹配的颜色状态。 比如说当前GC周期使用Marked0标记对象，则除了Marked0以外的颜色全是坏颜色。 例如如果指针颜色是Remapped，则代表该对象引用已经改变但是还未更新；是Marked1则代表该对象的染色指针已经过期，使用的还是上个周期的颜色。

其工作流程如下：

1. **初始标记（有STW）：**扫描GC Roots直接引用对象。
2. 并发标记（无STW）：
3. 遍历对象图标记存活对象，通过染色指针记录状态
4. SATB 优化
5. **重新标记（有STW）：**修正并发标记期间的引用变更，超时则退回并发标记
6. **并发转移准备（无STW）：**统计需回收的Region，组成重分配集
7. **初始转移（有STW）：**转移GC Roots直接引用的对象。
8. 并发转移（无STW）：
9. 核心阶段：将重分配集的存活对象复制到新 Region
10. 自愈机制：用户线程访问旧对象时，读屏障自愈
11. 立即释放：对象转移后，原Region可立刻重用
12. **并发重映射（无STW）：**修正堆中指向旧地址的引用（合并至下次标记阶段，减少遍历开销）。

因此ZGC的优点是超低可控停顿、无内存碎片，适用于高并发场景。

但是相对的ZGC的空间开销大，且无分代设计易产生浮动垃圾。

因此在JDK21+，引入了分代设计的ZGC，取消了多重映射，简化内存模型，解决了易产生浮动垃圾的问题。

（1）新生代优化#

新生代一般是频繁的Minor GC。

解决方法一般是增大Eden区占比、减少对象晋升老年代阈值，避免大对象写入。

（2）老年代优化#

而老年代则是影响更为严重的Full GC。

解决方法则是增大对象晋升老年代阈值、扩容堆内存以及增加预留空间预防复制转移失败导致OOM。

可以看到对于新生代需要减少对象晋升老年代阈值，而老年代则需要增大对象晋升老年代阈值，因此可以看到晋升阈值不能过大也不能过小，默认的15可谓是平衡了两个年代，但实际开发可以稍作调整，切忌过度调整。

（1）循环展开#

将循环体复制多份，减少循环的迭代次数，消除循环控制开销。

1
  // 原代码：循环4次
2
  for (int i=0; i<4; i++) {
3
      sum += arr[i];
4
  }
5

6
  // JIT优化后：循环展开（复制4次循环体）
7
  sum += arr[0];
8
  sum += arr[1];
9
  sum += arr[2];
10
  sum += arr[3];

这样就省去了i++以及条件判断的开销。 

（2）循环不变量提升#

将循环内不变的表达式移到循环外，避免重复计算。

1
  // 原代码：循环内的不变表达式（b*c）
2
  int a = 0;
3
  int b = 10;
4
  int c = 20;
5
  for (int i=0; i<1000; i++) {
6
      // b*c的值不变，每次循环都计算
7
      a += b * c;
8
  }
9

10
  // JIT优化后：将b*c移到循环外
11
  int a = 0;
12
  int b = 10;
13
  int c = 20;
14
  int bc = b * c;
15
  for (int i=0; i<1000; i++) {
16
      // 直接使用bc的值
17
      a += bc;
18
  }

（3）循环向量优化#

利用CPU的向量指令，将循环中的连续操作并行化，一次处理多个元素。

1
  // 原代码：遍历数组累加
2
  int[] arr = new int[1000];
3
  int sum = 0;
4
  for (int i=0; i<arr.length; i++) {
5
      sum += arr[i];
6
  }
7

8
  // JIT优化后：一次处理4个元素
9
  int sum = 0;
10
  int i=0;
11
  // 处理前996个元素（4的倍数）
12
  for (; i<=arr.length-4; i+=4) {
13
      // 使用AVX指令，一次读取arr[i]~arr[i+3]，累加为一个向量值
14
      sum += _mm256_add_epi32(arr[i], arr[i+1], arr[i+2], arr[i+3]);
15
  }
16
  // 处理剩余元素（0~3个）
17
  for (; i<arr.length; i++) {
18
      sum += arr[i];
19
  }

 向量优化可将循环性能提升2-4倍。