8.0
热点
AI SCORE
技术实践2026-08-19 01:47
JVM内存管理与性能调优：GC算法、堆布局与JIT编译
dev.to · AI#JVM#GC#性能调优
Editor brief · 编辑速览
全面讲解Java对象在堆中的生命周期、分代回收、各类GC算法（Serial/Parallel/CMS/G1/ZGC）对比、STW停顿及内存泄漏排查方法。
解释 Java 堆（Heap）中对象的完整生命周期。从创建到垃圾回收，包括各代（Young Gen、Old Gen）、Eden、S0、S1。
什么是垃圾回收（GC）？解释主要算法（Mark-Sweep、Mark-Compact、Copying）及其取舍。
描述 Serial、Parallel、CMS、G1 和 ZGC 垃圾回收器的区别。各自适用于哪些场景？
什么是 Stop-The-World（STW）停顿？不同的 GC 如何影响其持续时间和频率？
解释 Java 中的"内存泄漏"是什么。提供实践中的具体例子（例如在静态集合、缓存、未关闭的资源中）。
什么是 Metaspace（Java 8+）？它与 PermGen 有何不同？什么会导致 OutOfMemoryError: Metaspace？
解释字符串池（String Table）。intern() 方法如何工作？什么时候使用它是合理的？
什么是逃逸分析（Escape Analysis）？它如何帮助优化？（与栈上分配和标量替换的关联）
描述 Java 线程的内存结构（栈内存）。方法帧中存储了什么（局部变量、操作数栈、运行时常量池引用）？
什么是 JIT 编译（C1、C2/C1 和 C2（分层编译））？什么是代码" profiling（性能分析）"和去优化？
解释 volatile 变量的操作原理。什么是" happens-before（happens-before 原则）"？它如何确保线程间变化的可见性？
什么是伪共享（false sharing）？如何避免？（例如使用 @Contended）。
本文包含简化说明
创建（Allocation）：
绝大多数对象分配在 Eden Space（年轻代，Young Generation）。分配通过指针碰撞机制（TLAB — Thread-Local Allocation Buffer）完成，这使得操作简化为指针递增——时间复杂度 O(1)，几乎不需要同步。
大对象（阈值取决于 JVM，通常 > 512KB-1MB）直接进入老年代（Old Generation）（G1 中为 Humongous Region），绕过年轻代，以避免昂贵的复制操作。
年轻代中的早期生命（短命对象）：
Eden：当 Eden 满时，会触发 Minor GC。Minor GC 是 Java 中一种快速的局部内存清理，只影响称为年轻代的区域。
复制算法：存活对象（从 GC Root 可达）从 Eden 和一个 Survivor Space（S0 或 S1）复制到另一个 Survivor Space。
Survivor Spaces（S0/S1，也称 From/To）：两个大小相等的空间，总有一个是空的。（如果两个 Survivor 都包含数据：就没有地方可以复制来自 Eden 的新存活对象。）每次 Minor GC 后，存活对象在两者之间复制，年龄（age）递增。这个空间以极低的开销过滤掉短命对象。
晋升（Promotion）： 当对象达到年龄阈值（MaxTenuringThreshold，通常为 15）时，认为它是长命对象，并被移动（晋升）到老年代。（简化说明）
老年代的成熟期（长命对象）：
对象存活很长时间。
当老年代填满（或达到某个阈值，InitiatingHeapOccupancyPercent）时，会触发 Major GC（或 Full GC，取决于收集器），它处理整个堆。
老年代的算法更复杂：Mark-Sweep-Compact（Serial、Parallel）、Concurrent Mark-Sweep（CMS），或 G1/ZGC/Shenandoah 中的混合算法。
死亡与回收（垃圾回收）：
当一个对象没有任何来自存活对象（GC Root）通过任何可达路径的引用时，它就变成了垃圾。
GC Roots：静态变量、活动栈帧、JNI 引用、已加载的系统类。
内存由收集器释放。在 Eden/ Survivor 中——通过复制存活对象实现（死亡对象被忽略）。在老年代中——通过"清除"和后续"压缩"来对抗碎片化。
垃圾回收是一种自动化的动态内存管理系统，它释放执行程序不可达的对象。
Mark-Sweep（标记-清除）： 阶段 1（标记）：从 GC Roots 开始遍历可达图。存活对象被标记。阶段 2（清除）：线性遍历整个内存。未标记的（死亡）块被标记为空闲。取舍：会导致碎片化。开销低，但会产生"千疮百孔"的堆，降低分配性能，并可能因缺乏连续空间而导致 OOM。
Copying（复制）： 将内存分为两个半空间（From 和 To）。存活对象从 From 复制到 To。复制完成后，整个 From 空间被视为空闲。取舍：需要两倍的内存（一半始终为空）。不会碎片化。如果大多数对象年轻时就死亡，效率极高。仅用于年轻代。
Mark-Compact（标记-压缩）： 阶段 1（标记）：与 Mark-Sweep 相同。阶段 2（压缩）：存活对象移动到该区域的开头，形成一个连续的内存块。所有对被移动对象的引用都会被更新。取舍：消除碎片化。由于移动和更新引用的成本，这是最昂贵的操作。主要用于老年代。
演进结论： 年轻代使用复制算法（高死亡率，效率高）。老年代使用 Mark-Sweep/Compact 的混合算法（低死亡率，对抗碎片化）。现代 GC（G1、ZGC）将堆划分为多个区域，精准应用算法。
Serial GC（-XX:+UseSerialGC）：单线程执行标记、清除、压缩。仅有 STW。场景：单线程应用、微控制器、资源极少的环境。
Parallel GC（Throughput Collector）（-XX:+UseParallelGC）：年轻代和老年代的多线程版 Serial。以更激进的 CPU 使用率为代价最大化吞吐量，STW 停顿时间更长。场景：批处理、计算类任务，可以接受数百毫秒到数秒的停顿。
CMS – Concurrent Mark Sweep（-XX:+UseConcMarkSweepGC）：通过收集器与应用并发工作来减少 STW 停顿时间。阶段：初始标记（STW，快速）、并发标记、并发预清理、重新标记（STW）、并发清除。取舍：默认不执行压缩 → 碎片化，可能出现 Concurrent Mode Failure（强制 Full GC）。后台 CPU 消耗高。
G1 – Garbage First（-XX:+UseG1GC，Java 9-11 起默认）：分区化（-XX:G1HeapRegionSize）、可预测。将堆分为约 2000 个区域。优先收集垃圾最多的区域（Garbage First）。具有软实时目标（-XX:MaxGCPauseMillis）。场景：在吞吐量和延迟之间取得通用平衡。是堆大小 >4-6GB 的应用的主要选择。
低延迟（亚毫秒级目标）垃圾收集器。核心特性：几乎所有阶段，包括对象重定位，都与应用程序并发执行。使用着色指针与读/写屏障（加载屏障）。
适用场景：延迟敏感型应用：金融交易、高负载 Web 服务、超大堆（TB 级）。
核心特性：几乎所有阶段，包括对象重定位，都与应用程序并发执行。
使用着色指针与读/写屏障（加载屏障）。
适用场景：延迟敏感型应用：金融交易、高负载 Web 服务、超大堆（TB 级）。
选型策略：可接受的延迟越低，就需要越先进、越并发的收集器。吞吐量 → 延迟梯度：Parallel → G1 → ZGC/Shenandoah。
STW —— 所有应用线程被暂停以执行 GC 操作的阶段，此时对象图是静态的、安全的。
触发原因：
GC 影响：
Serial/Parallel：占主导地位、STW 阶段长。停顿时间随堆大小增长。
CMS：显著减少 STW（Initial Mark、Remark），但存在 Concurrent Mode Failure（长时间 STW）的风险。
G1：可预测、可控的停顿（MaxGCPauseMillis）。STW 仅限于疏散选定的区域集合。
ZGC/Shenandoah：STW 缩短至微秒级根扫描（Root Scanning）。大部分工作是并发执行的。
内存泄漏 —— 应用程序不再使用的对象，因仍被存活数据结构中存储的错误引用持有而无法被 GC 回收。
这不是 JVM 的 bug，而是代码中的逻辑错误。
静态集合（经典模式）：
public class LeakyClass {
private static final List<byte[]> STATIC_CACHE = new ArrayList<>();
public void processData(byte[] data) {
STATIC_CACHE.add(data); // The data object is forever reachable via the static field
}
}
静态集合（经典模式）：
public class LeakyClass {
private static final List<byte[]> STATIC_CACHE = new ArrayList<>();
public void processData(byte[] data) {
STATIC_CACHE.add(data); // The data object is forever reachable via the static field
}
}
不受控制的缓存（Guava Cache、Caffeine 无驱逐策略）：
Cache<Key, Value> cache = Caffeine.newBuilder().build(); // No expireAfterWrite or maximumSize
// Cache grows indefinitely.
不受控制的缓存（Guava Cache、Caffeine 无驱逐策略）：
Cache<Key, Value> cache = Caffeine.newBuilder().build(); // No expireAfterWrite or maximumSize
// Cache grows indefinitely.
未关闭的资源（InputStream、Connection、Session）：资源通常持有对内部缓冲区或原生内存中对象的引用。解决方案：try-with-resources。
未关闭的资源（InputStream、Connection、Session）：资源通常持有对内部缓冲区或原生内存中对象的引用。解决方案：try-with-resources。
事件监听器（Listeners）与内部类：不从存储在全局上下文中的监听器退订，会保持对外部类的引用。
事件监听器（Listeners）与内部类：不从存储在全局上下文中的监听器退订，会保持对外部类的引用。
ThreadLocal 未清理（尤其在线程池中）：ThreadLocal 中的值与线程存活时间相同。在 Web 应用中，线程返回池中后可存活数年。
private static final ThreadLocal<HeavyContext> threadLocal = new ThreadLocal<>();
// After use, it is necessary to: threadLocal.remove();
ThreadLocal 未清理（尤其在线程池中）：ThreadLocal 中的值与线程存活时间相同。在 Web 应用中，线程返回池中后可存活数年。
private static final ThreadLocal<HeavyContext> threadLocal = new ThreadLocal<>();
// After use, it is necessary to: threadLocal.remove();
诊断：监控 Old Gen（持续增长）、分析堆转储（jmap -dump、MAT、VisualVM）、搜索保留大小最大的 java.lang.Object[]。
PermGen（直至 Java 7）—— 固定大小的堆段，用于存储类元数据，导致频繁的 OutOfMemoryError，需要手动调优大小。
Metaspace（Java 8 起）—— 原生内存中的动态区域，由操作系统自动管理，消除了 PermGen 问题，允许高效地加载和卸载类。
PermGen（≤ Java 7）：固定大小（-XX:MaxPermSize）。存储类元数据、驻留字符串（interned strings）、静态成员。频繁引发 OutOfMemoryError：PermGen space。
Metaspace（Java 8+）：
由操作系统管理，默认无限制（受物理内存/swap 限制）。
自动增长和清理。类加载器及其加载的类由 GC 回收。
分为：Klass Metaspace（非丢弃的元数据）、NoKlass Metaspace（其他内容）。
OutOfMemoryError: Metaspace 发生的条件：
达到限制（-XX:MaxMetaspaceSize）。
元数据泄漏（ClassLoader Leak）：常见于容器（Tomcat、OSGi）中应用被重新加载，但旧的 ClassLoader 仍被持有（例如通过线程或静态引用），导致其加载的类无法被卸载。
String Pool —— 堆中的哈希表（Hashtable）（早期在 PermGen 中），存储 String 的规范（驻留）实例。
规则：
字符串字面量（"text"）在类加载时被添加到池中。
String.intern()：允许将运行时创建的字符串添加到池中。返回规范表示。如果字符串已在池中——返回对它的引用。如果没有——将当前对象添加到池中并返回它。
如果字符串已在池中——返回对它的引用。
如果没有——将当前对象添加到池中并返回它。
何时使用 intern()：在典型应用代码中几乎从不使用。合理场景：处理海量数据且字符串重复度极高（解析 CSV、标签、类枚举值），需要：
危险：无限使用会导致池增长，在 Java 7 之前池永不清空。Java 7 起，驻留字符串存在于堆中，如果 ClassLoader 被卸载则可被 GC 回收。
几乎从不使用。
合理场景：处理海量数据且字符串重复度极高（解析 CSV、标签、类枚举值），需要：
显著节省内存（多个相同值共用一个字符串）。
通过 == 加速比较（替代 .equals()）。
危险：无限使用会导致池增长，在 Java 7 之前池永不清空。Java 7 起，驻留字符串存在于堆中，如果 ClassLoader 被卸载则可被 GC 回收。
Escape Analysis（EA）—— JIT 编译器（C2）分析，确定创建对象的可见性范围。
NoEscape：对象不超出方法或线程边界。
ArgEscape：对象被传递给另一个方法，但不"逃逸"线程。
GlobalEscape：对象被发布（保存到静态字段、传递给另一个线程）。
对象被发布（保存到静态字段，或传递到另一个线程）。
标量替换（Scalar Replacement）：如果对象是 NoEscape 状态，JIT 不会在堆上分配它，而是将它的字段转换为方法栈帧上的局部变量（基本类型/引用）。这是理想的优化：零分配开销，零 GC 开销。
// 优化前
Point p = new Point(x, y);
return p.x + p.y;
// 标量替换后
int p_x = x, p_y = y;
return p_x + p_y; // Point 对象未创建
栈上分配（Stack Allocation）：标量替换的一种特殊形式。理论上是栈上分配，但在 HotSpot 中的实现其实就是分解。
锁消除（Lock Elision）：如果对象的监视器是 NoEscape 状态（例如在局部对象上的 synchronized 块），锁会被移除，因为不可能在其他线程中产生争用。
激活条件：默认启用（-XX:+DoEscapeAnalysis）。对短生命周期、局部对象有效（DTO、迭代器、构建器）。
每个 JVM 线程拥有一个私有栈，在线程启动时创建。栈由栈帧组成，方法调用时压入，完成时弹出（正常或异常）。
局部变量数组（Local Variable Array, LVA）：方法变量的数组，从 0 开始索引。
LVA[0]LVA[1]、LVA[2]、……操作数栈（Operand Stack, OS）：计算的工作区（栈架构风格）。字节码指令（iload、iadd、invokevirtual）在这上面操作（push/pop 值）。
int a = 5; int b = 3; int c = a + b;
// 字节码：
iconst_5 // push 5 -> OS
istore_1 // pop OS -> LVA[1] (a)
iconst_3 // push 3 -> OS
istore_2 // pop OS -> LVA[2] (b)
iload_1 // push LVA[1] (a) -> OS
iload_2 // push LVA[2] (b) -> OS
iadd // pop 2 values, add, push result -> OS
istore_3 // pop OS -> LVA[3] (c)
运行时常量池引用（Reference to Runtime Constant Pool, RCP）：指向类的常量池的指针，用于在运行时解析符号引用（方法名、类、常量）。
大小：由 -Xss 参数设置（默认约 1MB）。溢出 → StackOverflowError。动态扩展 → OutOfMemoryError。
JIT（Just-In-Time）—— 在运行时将"热"字节码编译为原生机器码。
| 级别 | 特点 |
|---|---|
| Interpreter（解释器） | 执行字节码。零启动开销，但速度慢。 |
| C1（Client Compiler） | 快速、轻量级编译。应用基本优化（内联、简单数据流分析）。目标——快速获得可用的原生代码。 |
| C2（Server Compiler） | 激进、重型优化编译器。使用复杂静态分析（EA、标量替换、循环展开、宏融合和微融合、内存和屏障优化）。编译最热的方法。 |
JVM 在运行时收集代码执行数据：
invokevirtual）时具体是哪些类到达。这允许去虚拟化——用直接调用替换虚调用，然后再内联。逆向过程。如果优化器的假设被违反（例如出现了一个新类型，画像中未考虑），JVM 将编译好的原生代码回滚到解释执行的字节码。
触发条件：
（简化描述）