>**摘要**：本文对 JDK 26 的核心性能增强提案 JEP 522 进行了全面、深入的剖析。文章首先回顾了 G1 GC 的架构演进与核心挑战，继而详细阐述了 JEP 522 的技术动机——应用线程与 GC 线程间高昂的同步开销。核心部分深入解析了其两大关键技术革新：“第二张卡表”（Second Card Table）和“精简写屏障”（Streamlined Write Barrier），并结合 HotSpot JVM 源码级别的实现细节，揭示了其如何将写屏障指令从约50条锐减至12条。通过理论分析与基准测试数据，本文量化了该优化带来的 5-15% 吞吐量提升，并探讨了其在高并发、低延迟场景下的巨大价值。最后，文章展望了 JEP 522 在 Project Leyden 和未来 Java LTS 版本中的战略意义，为开发者提供了升级决策与性能调优的实践指南。


----

## 引言：Java 性能优化的新战场


自 JDK 9 起，G1 (Garbage-First) 垃圾回收器便取代了 Parallel Scavenge + Parallel Old 组合，成为 Java 平台面向服务端应用的**默认垃圾回收器**。这一选择源于 G1 独特的设计哲学：**在可预测的停顿时间目标（MaxGCPauseMillis）内，实现尽可能高的吞吐量**。多年来，G1 凭借其 Region 化的堆布局、并发标记以及混合回收（Mixed GC）等机制，在众多企业级应用中证明了其卓越的综合性能。

然而，随着云原生、微服务架构的普及，以及对极致性能和成本效益的不懈追求，即使是 G1 这样的成熟 GC，也面临着新的挑战。其中，一个长期存在但未被彻底解决的痛点是：**应用线程（Mutator Threads）与 GC 线程（Collector Threads）之间的同步开销**。

在高并发、高吞吐的应用中，对象引用关系的频繁变更会触发大量的“写屏障”（Write Barrier）。传统的写屏障实现为了维护 GC 所需的数据结构（如卡表 Card Table），需要执行复杂的内存同步操作。这些看似微小的操作，在高频次下累积起来，会显著拖累应用的整体吞吐能力，形成一个难以察觉却影响深远的性能瓶颈。

正是在这样的背景下，**JEP 522: G1 GC: Improve Throughput by Reducing Synchronization** 应运而生。作为 JDK 26 的一项关键非预览特性，JEP 522 并非对 G1 进行颠覆性的重构，而是聚焦于一个具体的、高回报的优化点——**大幅降低应用线程与 GC 线程间的同步频率与开销**。其目标直指核心：**在不增加额外硬件成本的前提下，让 Java 应用处理更多的工作，从而提升效率、降低成本、改善用户体验**。

本文将带领读者深入 JEP 522 的技术腹地，从理论基础到实现细节，从性能收益到未来展望，全方位解读这一重要优化背后的故事。


----

## 第一章：G1 GC 架构基石与核心挑战


要理解 JEP 522 的价值，必须首先深刻理解 G1 GC 的工作原理及其固有的复杂性。

### 1.1 G1 的核心设计：Region 与 Remembered Sets


G1 将整个 Java 堆划分为数百甚至数千个大小相等的区域（Region），通常每个 Region 的大小在 1MB 到 32MB 之间。这种设计打破了传统分代收集器中新生代和老年代物理隔离的界限。每个 Region 在逻辑上可以扮演 Eden、Survivor 或 Old 的角色，并且可以根据回收效率动态调整。

G1 的核心优势在于其“增量式”的回收策略。它并不一次性回收整个堆，而是优先选择回收那些**垃圾对象比例最高**的 Region（即“Garbage-First”名称的由来）。这种策略使得 G1 能够在满足停顿时间目标的同时，高效地释放内存。

然而，这种跨 Region 的回收方式带来了一个关键挑战：**如何高效地追踪跨 Region 的引用？**

### 1.2 写屏障与卡表（Card Table）：维护引用关系的代价


为了解决跨 Region 引用的问题，G1 采用了“记忆集”（Remembered Set, RSet）的概念。每个 Region 都有一个对应的 RSet，用于记录**指向该 Region 内对象的所有外部引用**。这样，在回收某个 Region 时，GC 只需扫描该 Region 本身以及其 RSet 中记录的引用，而无需扫描整个堆，极大地提高了回收效率。

那么，RSet 是如何构建和维护的呢？答案就是**写屏障（Write Barrier）**。

每当应用线程执行一个赋值操作（例如 `obj.field = anotherObj`），如果这个操作创建了一个从一个 Region 指向另一个 Region 的新引用，JVM 就会在该赋值操作之后**自动插入一小段代码**，这就是写屏障。写屏障的主要职责是：


1. **检测**：判断这次赋值是否产生了跨 Region 的引用。

2. **记录**：如果产生了跨 Region 引用，则更新相应 Region 的 RSet。


为了高效地检测跨 Region 引用，G1 使用了**卡表（Card Table）**。卡表是一个字节数组，堆内存被划分为固定大小的“卡片”（Card），通常是 512 字节。卡表中的每个字节对应堆中的一个卡片。当一个卡片内的对象引用被修改时，该卡片在卡表中对应的字节就会被标记为“脏”（Dirty）。

写屏障的工作流程通常是：


1. 根据被修改的对象地址，计算出其所在的卡片索引。

2. 将卡表中对应位置的字节标记为脏。

3. **（关键步骤）** 通知 GC 线程，有新的脏卡片需要处理，以便后续更新 RSet。


### 1.3 同步开销：性能瓶颈的根源


问题就出在第 3 步。为了确保 GC 线程能够及时、准确地感知到卡表的变化，应用线程在标记卡表后，往往需要执行昂贵的**内存屏障（Memory Barrier）** 或**原子操作（Atomic Operation）** 来与 GC 线程进行同步。这些操作会强制刷新 CPU 缓存，确保内存状态的一致性，但同时也带来了显著的性能开销。

在高并发场景下，成千上万的应用线程同时进行对象赋值，会触发海量的写屏障调用。每一次调用都伴随着潜在的同步开销，这些开销累积起来，会严重侵蚀应用的吞吐量。这便是 JEP 522 旨在解决的核心问题。


----

## 第二章：JEP 522 的技术方案：解耦与精简


JEP 522 的核心思想是**解耦**（Decoupling）——将应用线程的快速路径（Fast Path）与 GC 线程的慢速路径（Slow Path）尽可能地分离，让应用线程在绝大多数情况下无需与 GC 线程进行同步。

### 2.1 “第二张卡表”（Second Card Table）：异步缓冲区


这是 JEP 522 最具创新性的设计。方案引入了一个全新的、专属于应用线程的数据结构——**第二张卡表**（有时也被称为“Dirty Card Queue”或“Log Buffer”）。

**工作原理如下**：


1. **应用线程的快速路径**：当应用线程执行写屏障时，它不再直接去修改全局的、共享的主卡表（Main Card Table）。相反，它会将“卡片变脏”这一事件**记录到自己线程本地的第二张卡表**（或一个线程本地的队列）中。

2. **无同步操作**：由于这个第二张卡表是线程本地的，应用线程对其进行写入操作是完全无锁、无同步的，速度极快。

3. **GC 线程的异步处理**：GC 线程（或一个专门的并发线程）会定期或在特定时机（如安全点 Safepoint）**批量地**从所有应用线程的第二张卡表中收集“脏卡片”信息，并将这些信息**合并**（Merge）到全局的主卡表中，进而更新相应的 RSet。


通过这种方式，高昂的同步开销从高频的应用线程侧，转移到了低频的 GC 线程侧。应用线程的写屏障变得异常轻量，而 GC 线程则承担了批量处理的聚合开销，整体效率得到显著提升。

### 2.2 精简写屏障（Streamlined Write Barrier）


除了引入第二张卡表，JEP 522 还对写屏障本身的逻辑进行了深度优化和精简。

在旧的实现中，写屏障包含了大量的条件判断、边界检查和复杂的内存操作，汇编指令数量可能高达 **50 条左右**。JEP 522 通过以下方式对其进行瘦身：


- **简化逻辑**：移除不必要的检查，假设大多数写操作都是安全的。

- **利用硬件特性**：更高效地使用现代 CPU 的缓存行（Cache Line）和预取（Prefetching）指令。

- **内联优化**：确保写屏障代码能够被 JIT 编译器高效地内联到应用代码中，减少函数调用开销。


经过优化后，新的写屏障在“快速路径”上的汇编指令数量锐减至 **12 条左右**。这是一个数量级的性能飞跃，意味着每次对象引用修改的开销大大降低。

### 2.3 内存开销分析


任何优化都需要权衡。引入第二张卡表是否会带来过大的内存开销？

答案是否定的。根据官方文档和社区实测，第二张卡表的内存占用非常克制。其大小与堆内存成正比，但比例极小。一个普遍接受的估算是：**每 1GB 的 Java 堆内存，第二张卡表仅需额外消耗约 2MB 的原生内存**。

对于一个拥有数十GB堆内存的典型服务端应用来说，增加几十MB的原生内存开销，换来 5-15% 的吞吐量提升，这笔交易无疑是极其划算的。


----

## 第三章：实现细节与源码探秘


为了更直观地理解 JEP 522，我们可以从 HotSpot JVM 的源码层面窥探其奥秘（基于 OpenJDK 的概念性描述）。

### 3.1 写屏障的变迁


在 JEP 522 之前，G1 的写屏障入口点大致如下（伪代码）：

```
void g1_write_barrier_post(oop* field, oop new_val) {
    // 1. 检查是否需要处理
    if (is_in_young(new_val)) return;
    // 2. 计算卡片地址
    jbyte* card_addr = byte_for((address)field);
    // 3. 如果卡片未被标记，则标记它
    if (*card_addr != G1CardTable::dirty_card) {
        *card_addr = G1CardTable::dirty_card;
        // 4. 【昂贵的同步】通知 GC 线程
        enqueue_card_for_gc(card_addr); // 这里包含内存屏障和原子操作
    }
}
```
JEP 522 之后，写屏障被重构成两个路径：

```
// 快速路径：应用线程执行
void g1_write_barrier_post_fast(oop* field, oop new_val) {
    if (is_in_young(new_val)) return;
    jbyte* card_addr = byte_for((address)field);
    if (*card_addr != G1CardTable::dirty_card) {
        *card_addr = G1CardTable::dirty_card;
        // 将卡片地址添加到线程本地的缓冲区
        thread_local_dirty_card_queue()->enqueue(card_addr);
        // 【无同步！】
    }
}

// 慢速路径：当本地缓冲区满时触发
void g1_write_barrier_post_slow() {
    // 将本地缓冲区的内容 flush 到全局结构
    flush_dirty_card_queue();
    // 这里才会有必要的同步，但频率极低
}
```
可以看到，快速路径中完全移除了与 GC 线程的直接交互，使其成为一个纯粹的、无锁的本地操作。

### 3.2 GC 线程的协同


GC 线程（或并发 Refine 线程）现在多了一项任务：处理来自所有应用线程的“脏卡片队列”。这部分逻辑在 `G1RemSet.cpp` 和相关的并发处理模块中实现。它会周期性地遍历这些队列，将卡片信息合并到主卡表，并最终更新 RSet。这个过程虽然也有开销，但由于是批量处理，其单位开销远低于逐个处理。


----

## 第四章：性能评估与实战价值


理论再完美，也需要实践的检验。JEP 522 带来的性能提升是实实在在的。

### 4.1 基准测试结果


根据 OpenJDK 社区和各大厂商（如 Oracle, Red Hat）发布的基准测试报告，JEP 522 在多种 workload 下均表现出色：


- **SPECjbb2015**（衡量 Java 服务器吞吐量的标准基准）：吞吐量提升 **8-12%**。

- **DaCapo Benchmark**（包含多种真实世界应用的套件）：在 `tradebeans`, `tradesoap` 等高并发场景下，吞吐量提升 **5-15%**。

- **内部微服务负载**：对于对象引用修改极其频繁的服务（如复杂的领域模型、高频消息处理），提升效果最为显著，部分场景可达 **15% 以上**。


这些提升是在**不改变任何应用代码、不增加任何硬件资源**的情况下获得的，纯粹源于 JVM 内部的优化。

### 4.2 对业务指标的影响


吞吐量的提升直接转化为业务价值：


- **更高的用户承载能力**：单台服务器可以处理更多的请求，延缓了扩容需求，**直接降低了基础设施成本**。

- **更低的响应延迟**：由于应用线程被 GC 同步阻塞的时间减少，请求的平均响应时间和尾部延迟（P99, P999）得到改善，**提供了更流畅的用户体验**。

- **更高的资源利用率**：CPU 资源更多地用于业务逻辑，而非 GC 开销，使得计算资源的利用更加高效。


### 4.3 适用场景分析


JEP 522 的收益并非在所有场景下都均等。其优化效果与应用的特性密切相关：


- **高收益场景**：
	- 对象图结构复杂，引用关系变更频繁的应用（如 ORM 框架、复杂业务逻辑）。
	- 高并发、高吞吐的 Web 服务和微服务。
	- 大堆内存（>16GB）应用，因为卡表本身较大，同步开销更为显著。

- **低收益场景**：
	- 计算密集型、内存分配少的应用。
	- 小堆内存应用，卡表同步开销本身占比不高。
	- 已经使用 ZGC 或 Shenandoah 等超低延迟 GC 的应用（但 JEP 522 的理念未来可能会被借鉴）。


----

## 第五章：JEP 522 的战略意义与未来展望


JEP 522 的意义远不止于一次性能优化，它体现了 Java 平台未来发展的几个重要方向。

### 5.1 Project Leyden 的重要拼图


Project Leyden 的目标是解决 Java “启动慢、占用大”的传统痛点，使其更适合现代云原生和 Serverless 环境。JEP 522 虽然主要针对运行时吞吐量，但其“降低开销、提升效率”的思想与 Leyden 完全一致。更重要的是，JEP 522 为其他 Leyden 相关的 JEP（如 AOT 编译）铺平了道路。一个更高效的 G1 GC，能让 AOT 优化后的应用发挥出更大的潜力。

### 5.2 推动 G1 成为“全能”默认 GC


Oracle 已经提出了 **JEP 523: Make G1 the Default Garbage Collector in All Environments**。这意味着未来 G1 不仅是服务端的默认 GC，还可能成为客户端甚至小型设备上的默认选择。要实现这一目标，G1 必须在各种规模和类型的 workload 下都表现出色。JEP 522 通过提升吞吐量、降低小堆下的相对开销，极大地增强了 G1 的普适性和竞争力。

### 5.3 对开发者的影响


对于广大 Java 开发者而言，JEP 522 是一个“免费的午餐”。升级到 JDK 26 或更高版本后，无需任何代码改动，就能享受到性能红利。这降低了性能优化的门槛，让开发者可以将更多精力集中在业务逻辑本身。

当然，理解其背后的原理，有助于开发者更好地进行 JVM 调优。例如，在 JDK 26+ 上，可以更有信心地将 `-XX:MaxGCPauseMillis` 设置得更低，因为 G1 的基础吞吐能力已经更强，能够在更短的停顿时间内完成更多的回收工作。


----

## 结论


JEP 522 是一次教科书级别的 JVM 性能优化。它没有追求宏大的架构变革，而是精准地定位到一个具体的、高价值的性能瓶颈——应用线程与 GC 线程间的同步开销。通过引入“第二张卡表”和精简写屏障这两大核心技术，JEP 522 成功地将这一开销降至最低，为 G1 GC 带来了 5-15% 的显著吞吐量提升。

这项优化不仅是 JDK 26 的一大亮点，更是 Java 平台持续演进、拥抱现代计算需求的有力证明。它在不增加开发者负担、不牺牲应用稳定性的前提下，直接提升了应用的性能和效率，降低了企业的运营成本。

随着 JDK 26 的发布和未来 LTS 版本（如 JDK 29）对其特性的吸收，JEP 522 的影响力将不断扩大。对于任何运行在 G1 GC 上的 Java 应用，升级到支持 JEP 522 的 JDK 版本，都是一项高 ROI（投资回报率）的技术决策。在未来，我们有理由相信，Java 将继续以其稳健、高效和现代化的姿态，支撑起全球最复杂、最关键的业务系统。

摘要：本文对 JDK 26 的核心性能增强提案 JEP 522 进行了全面、深入的剖析。文章首先回顾了 G1 GC 的架构演进与核心挑战，继而详细阐述了 JEP 522 的技术动机——应用线程与 GC 线程间高昂的同步开销。核心部分深入解析了其两大关键技术革新：“第二张卡表”（Second Card Table）和“精简写屏障”（Streamlined Write Barrier），并结合 HotSpot JVM 源码级别的实现细节，揭示了其如何将写屏障指令从约50条锐减至12条。通过理论分析与基准测试数据，本文量化了该优化带来的 5-15% 吞吐量提升，并探讨了其在高并发、低延迟场景下的巨大价值。最后，文章展望了 JEP 522 在 Project Leyden 和未来 Java LTS 版本中的战略意义，为开发者提供了升级决策与性能调优的实践指南。

Java|JDK 26 新特性之性能核弹：JEP 522 如何让 G1 GC 吞吐量飙升 15%？ ——万字深度解析 HotSpot JVM 降低同步开销的技术

摘要：本文对 JDK 26 的核心性能增强提案 JEP 522 进行了全面、深入的剖析。文章首先回顾了 G1 GC 的架构演进与核心挑战，继而详细阐述了 JEP 522 的技术动机——应用线程与 GC 线程间高昂的同步开销。核心部分深入解析了其两大关键技术革新：“第二张卡表”（Second Card Table）和“精简写屏障”（Streamlined Write Barrier）。

后端

编程语言

架构设计

JDK26的JEP522提案通过引入"第二张卡表"和精简写屏障技术，将G1GC写屏障指令从50条减至12条，显著降低应用线程与GC线程的同步开销。基准测试显示吞吐量提升5-15%，特别适合高并发、大堆内存场景。该优化无需代码改动即可获得性能提升，是Java性能优化的重要突破。

微服务架构

数据结构

服务器

云原生

编译器

Java

4核4G3M云服务器 新用户低至38元/年！

2026采购季 | AI焕新·智启新局

serverless-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Java|JDK 26 新特性之性能核弹：JEP 522 如何让 G1 GC 吞吐量飙升 15%？ ——万字深度解析 HotSpot JVM 降低同步开销的技术-腾讯云开发者社区-腾讯云

Java|JDK 26 新特性之性能核弹：JEP 522 如何让 G1 GC 吞吐量飙升 15%？ ——万字深度解析 HotSpot JVM 降低同步开销的技术

Java|JDK 26 新特性之性能核弹：JEP 522 如何让 G1 GC 吞吐量飙升 15%？ ——万字深度解析 HotSpot JVM 降低同步开销的技术

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐