小红书 JDK 升级带来 10%整体性能提升，这份升级指南收好了！

1.0 总体背景

《TIOBE 编程语言排行》2025 年 6 月报告出炉，Python、C/C++、Java 仍然稳居前列，它们特点不同，在各自最适合的使用场景难以替代——例如 Python 在 AI 领域及 C/C++ 在游戏开发场景的地位。Java 依靠其丰富的生态和强大的 JVM 支持，成为了企业级后端应用和大数据处理的绝佳选择。同时，Java 在小红书后端技术体系中扮演重要支撑角色。

近年来，小红书增长迅猛，搜索、推荐、广告、电商等核心业务负载居高不下，对 JVM 稳定性、服务运行效率和 GC 卡顿时长提出严格要求——JVM Crash 和 GC 秒级卡顿行为足以威胁生产；同时，Spring、Flink、Spark等框架陆续弃用 Java8。在社区大发展环境下，JDK8 的性能、稳定性和对业务的支撑已难以满足小红书当前阶段诉求，貌似必须掌控 JDK 灵活升级的办法，才能在未来高速变化的环境中更好地支持业务迭代。

1.1 价值驱动

伴随着小红书业务来到更高的发展阶段，对后端服务的性能与稳定性提出了严格要求，然而 JDK 作为 Java 服务的底座，却暴露出很多问题与风险，需要系统性解决。小红书通过统一管控JDK产品生态并升级到 JDK11，可以从成本、稳定和标准化多方面直接或间接获得巨大的收益。

• 直接成本收益：承接同等的请求需要的CPU降低，进一步可以进行缩容和退机，转换成直接成本收益

• 间接成本受益：随着业务不断发展，未来增长的 cpu 申请quota也会随着优化变少

• 业务发展需要：众多新一代主流开源项目（如 Spring Boot 3.x、Kafka 4.0 等）已陆续停止 JDK8 支持

• 稳定性收益：高版本 JDK 修复了诸多 GC、JIT、Corelibs 中的 Bugs，消除潜在稳定性风险

• 运维收益：统一使用独立开发维护的JDK版本，灵活根据业务需要提供适配支持；标准化使用姿势减少业务运维负担

1.2 价值体现

1.2.1 G1GC 优化提高性能 & 稳定性

G1GC 于 JDK7 开始被支持，随后在 JDK9 中才成为默认的 GC 算法，其算法核心特点是分代、基于预测单次停顿时长控制 GC 行为。小红书的在线应用注重用户及时交互体验，因此对响应延时指标极其看重，在这样的业务场景下，G1GC 成为了小红书的首选 GC 算法。

然而，我们发现 JDK8 中实现的 G1GC 仍存在不少缺陷，其不准确的预测模型和并发回收特性造成了额外的资源开销，甚至对生产稳定性产生威胁。通过升级 JDK，可以显著提高 GC 吞吐，降低 RT。

G1GC 优化 —— 并行 FullGC

在小红书很多核心场景都会偶发 FullGC 问题，尤其是在大型活动时问题更为频繁，FullGC 通常导致秒级以上的卡顿。如果是JDK8，不论CPU资源多充足，FullGC 都只能通过单线程串行完成。G1GC 在JDK10（JEP-307）中提出通过多线程并行完成 FullGC，大大降低 FullGC 造成的负面影响。

G1GC 优化 —— 静态的 IHOP

IHOP 全称 InitiatingHeapOccupancyPercent，是控制 G1GC 触发并发标记的关键参数。默认情况下，当 Old 区大小超过全堆内存的 45%，G1 会开启一个与 Mutators 并发进行的标记阶段，用来回收老年代内存。如图所示，当开始并发回收的时候 （Concurrent Start），mutator 行为并不会停止——这避免了长时间的停顿，但要求 G1GC 尽快完成 GC，避免堆内存打满导致的 FullGC 行为。

1. 并发标记开始于老年代内存占用 45% 时（参数InitiatingHeapOccupancyPercent）

2. Young 区内存占比最高可以达到全堆的 60%（参数G1MaxNewSizePercent）；

3. 并发标记阶段，应用仍在持续分配新内存，部分晋升到老年代（实际promotion_rate)；

4. 为了处理晋升毛刺，G1 应预留 10% 的内存（参数G1ReservePercent）；

由此计算，堆内存总是不够的！实际上，未经调优的 JDK8 G1GC 长期暴露在 FullGC 的风险下。

G1GC 优化 —— 提前回收大对象（Humongous）

G1 是一种 Region-Based GC 算法，将整个 Heap 分为若干等大的内存块。如果一个 Java 对象，占用内存超过 G1 Region Size的一半，那么他将会独占一个或若干连续的 G1 Region，这种对象叫做大对象（Humongous）。大对象具备以下特点：

• 大对象直接分配在 Empty Region，不会被 Copy，GC 回收一个大对象基本没有开销；

• 大对象每个 Region 只有一个对象，Rset 维护代价极低；

• 回收一个大对象可以直接清理出若干完整的 G1 Region，ROI 高！

因此，在 JDK9+ 版本，G1GC 选择在 Young-Only GCs 中直接回收大对象，大大减轻了 GC 的开销和内存压力！

G1GC Bug —— 错误的 rs_length 预估

G1 的算法核心是：通过调节各分区内存大小，控制GC触发时机，保障STW时间控制在一定时间内（默认200ms）。那么G1如何预测接下来的 GC 卡顿时长呢？

答案就是将历史的 GC 情况代入一个衰减偏差模型中，判断在规定时间内能完成多少内存的回收工作，衰减模型会综合考虑过去一段时间区间内的数据。具体路径为：

1. 根据历史数据得到预测数据；

2. 根据预测数据和目标停顿时长，决策GC触发时机；

在预测的过程中，RSet 大小的记录与预测非常关键，该 Bug 是 GC 根据历史数据预测不准确，导致影响 GC 行为的一个典例，可以看看 JDK 部分源码：

预测的base_time_ms强依赖于 predict_rs_lengths。于是问题就发生了，实际情况如图所示：

1. 在Mixed GC开始时，下图蓝线所示 Mixed GC 期间 Rset 的大小会突然增加（t1时），红线所示对RSet大小预测值开始逐渐上升，但由于历史值影响，预测仍小于实际值，这导致 GC stw 时长超过目标值；

2. MixedGC 结束后，Rset 突然变小，预测值又会高于实际 Rset length。G1 没有考虑 MixedGC 的发生，单纯基于自己预测数据仍然认为 rset 很大，因此根据算法保持 Eden 区在很小的空间，从而带来了GC次数的陡增。

1.2.2 JVM Bug 在高版本修复

Bug——ReentrantLock 在遇到 StackOverflowError 时无法释放

ReentrantLock 是 Java 并发包中提供的显式锁机制，使用 ReentrantLock 时，需要在 finally 块中主动 unlock，避免死锁。然而，如果这里因为递归等原因导致 StackOverflowError，则 finally { lock.unlock(); } 无法正常执行，最终可能致使整个 Java 进程死锁。

Bug —— Heapdump / AGCT 等行为导致 Crash

火焰图和 Heapdump 是分析 Java 线上问题的常用工具，然而在我们实际使用过程中，类似工具会有较大概率导致 JVM Crash，对线上服务产生影响。其中原因种种，大多可以在 JBS（OpenJDK Bug System）中找到对应缺陷，需要通过升级 JDK 解决。

1.2.3 更强大的 VM 特性

Pauseless GC 家族 —— ZGC 与 ShenandoahGC

G1GC 通过并发标记和 SATB 算法，大幅降低了 GC 造成的卡顿，但 Java 应用仍然需要等待数十至数百毫秒的卡顿。新一代的 Pauseless GC 通过将更多 GC 工作放在并发阶段完成，成功进一步降低了 GC 卡顿时间。Pauseless GC 最早是由 Azul 公司实现的 C4GC，在商业版JDK产品——Zing 中提供支持。随后 Oracle 和 Redhat 分别实现了 ZGC 和 ShenandoahGC，OpenJDK 中支持使用。

支持 String Compact(JEP-254)

在 Java 的世界中，一个 'char' 需要占用两个字节，即 16 bits，而 ASCII 字符的编码位于 0-127 之间，即仅需要 8 bits，通过 'char[]' 类型存储英文字符串将会导致一倍的内存浪费。JDK9+ 默认开启 String Compact，对 java.lang.string 类添加了一个 coder 字段，快速判断该 String 是否被 Compact。其作用是为了在部分场景降低一倍的 String 内存占用（及对应 String 操作开销），如下图所示：

1.3 挑战与风险

上文提到的各种优化特性预期为 Java 应用带来巨大优化，但要将小红书几千个 Java 服务统一完成 JDK 升级仍有不小难度，需要妥善考虑各种情况。

兼容性风险

• Project Jigsaw 模块化与权限管控：由于 Project jigsaw 引入了模块系统重构并收紧了访问权限，很多被JDK8允许的Java代码并不能直接运行在更高版本的JDK上；

• Compact String 导致 String 结构变化：String Compact 是 JDK9 引入的一个非常好的优化特性，但使用不当可能导致序列化/反序列化失败，或序列化库开销暴增；

• JDK 默认行为变化：高版本 JDK 在TLS 协议、Locale 支持等行为默认发生了变化，可能产生兼容性问题。另外，部分标准库的行为发生了改变（比如之后 Hashmap.computeIfAbsent() 可能抛出 ConcurrentModificationException），影响并改变原本业务处理逻辑；

• JVM运行参数变化：GC 参数、容器化参数、日志配置方式均发生变化，错误配置可能导致内存上涨、性能回退，甚至导致 JVM 退出；

• 依赖复杂：上述兼容性问题同样可能发生在依赖的二方/三方包中，使用高版本 JDK 运行需要替换升级到支持高版本 JDK 的依赖包，或通过其他手段克服解决。

升级推进风险

• 需要配套流程支持：在数千Java应用升级JDK，需要考虑底层镜像、容器环境异构，和构建/部署流程与 JDK 升级带来的冲突；

• 需多团队配合完成：JDK 升级过程需要基础平台、构建/部署/测试平台、Java业务方等多团队共同参与，对组织横向协同和流程治理能力是一个巨大挑战。；

• 部分边缘Case排查：遇到业务行为不符合预期或性能退化的情况，需要对问题有清晰的排查和解释，避免盲目升级带来的额外风险。

1.4 项目目标

性能收益

推动小红书 Java RPC 服务、大数据业务、中台服务统一升级到 RedJDK11/RedJDK17，取得平均 10% 的性能提高与成本收益。

清除历史债务

通过升级项目，完成小红书Java服务的环境治理，管控并统一底层镜像、JDK 产品、构建流程和 Java 运行参数；

解决当前频发的 （因JDK引起的）OOM、GC抖动、CPU 异常，Java服务稳定性有明显提高；

通过能力建设解决 GC 毛刺、Native 内存泄露等棘手问题无趁手工具排查的窘境。

稳定保障

升级过程中，不出现P3以上的稳定性问题。

为了解决在复杂生产环境升级 JDK 产生的诸多难点，小红书通过 JDK 源码改造和环境/流程标准化等手段，屏蔽掉了JDK 底层行为变化带来的风险，对于 Java 开发同学无需关注 JDK 内部过多细节，即可享受最新的语言特性和运行时能力！为业务同学节省大量操作成本和心理负担。

小红书中间件团队采用“JDK 兼容性改造——标准化执行——特例针对性升级”的模式，即将风险控制在上线前，快速完成大部分场景的迁移升级工作，筛查出特殊场景并通过技术手段收口，最终实现全业务升级迁移到 JDK11 / 17 / 21 的技术目标。

2.1 具体问题与策略

可以在JDK侧统一解决的兼容问题

Compact String 导致 String 结构变化

String Compact 是 JDK9 引入的一个非常好的优化特性，但使用不当可能导致最危险的 Bad Case。从JDK8或更低版本升级，需要谨慎考虑：

• 如果采用无 IDL 的序列化算法处理 String（如 protostuff），并使用普通的 RuntimeSchema 序列化 String 对象，会因为 String 结构变化导致序列化/反序列化结果不一致。需注意：务必规范使用 String 专用的 Schema；

• Compacted String 如果需要拼接非 Latin 字符，则整个 String 需要膨胀回 UTF-16 格式存储，在中/英字符串拼接场景可能开销更大；

2.2 优化改造

在高并发、高负载的生产环境中，JVM 的 GC 表现往往成为系统稳定性的"阿喀琉斯之踵"。我们发现小红书存在以下三类典型问题亟需系统性解决：

• GC卡顿毛刺：YoungGC表现不稳定，在晚高峰可能迎来 GC 开销陡增。

• 定时炸弹FullGC：即使是低负载实例，也可能偶发 FullGC 造成严重可用性问题。

• 内存失控：Java 服务普遍面临着 native 内存分配器的内存泄漏问题与高 OOM 风险，依赖定期重启缓解。

2.2.1参数优化

• 通过 G1GC 参数调优，解决 G1 在复杂场景下造成的抖动问题：

MaxGCPauseMillis / G1NewSizePercent / InitiatingHeapOccupancyPercent / G1UseAdaptiveIHOP / G1ReservePercent

• 标准化内存分配参数，统一Java运行规格，便利运维工作：

InitialRAMPercentage / MaxRAMPercentage / ReservedCodeCacheSize / MaxDirectMemorySize

• 基于历史经验，选择性打开或关闭部分运行时特性，得到最佳性能表现：

打开 ParallelRefProcEnabled，关闭 UseStringDeduplication 与 UseBiasedLocking；

2.2.2 深度源码改造

FullGC 引发剧烈 GC 抖动

小红书普遍使用 G1 GC 算法，G1 会在 Full GC 后，以当前内存使用量为基准重新计算 Heap 大小，这个行为往往会造成堆大小减少以及 Young 区减少，进一步造成 GC 频率加快、开销陡增。由于小红书业务普遍对 RT 敏感，且 Shrink 掉的 Memory 实际上并不能得到利用，因此 RedJDK 默认使用稳定的 Java Heap，减少不必要的内存分配/归还。

JEP-358 helpful NPE

通常我们遇到空指针异常，会得到一条非常简单的NPE报错，它表示访问了某个对象为空：

Exception in thread "main" 

java.lang.NullPointerException

通过在 RedJDK11 支持 JEP-358，NPE 将直接告诉你，哪一行、哪个引用为空！是否只有开发同学才能理解，看到报错信息后立刻恍然大悟的那种救赎感。

StringBuilder性能优化

在升级 JDK11 时，发现部分中英文混杂场景下 StringBuilder 字符串处理能力存在性能劣化，原因可归结为以下几点：

• JDK11 StringBuilder 在 append 中英文混合字符串时存在性能瓶颈。默认 Latin 编码遇到非 Latin 字符需要判断和扩容，且通过 putChars 逐字符拷贝效率较低。RedJDK11 通过 backport JDK-8224986，JDK-8273100 等 patch，实现基于 System.arraycopy 的高性能 append(String s, int start, int end) 方法，可提升非 Latin 字符 append 性能。

• StringBuilder 的 UTF16 的 toStirng() 等方法需要通过遍历检查 byte[] 数组中是否存在非 Latin 字符，来判断是否可以处理为 UTF8。RedJDK11 通过 backport JDK-8282429 等 patch，在 AbstractStringBuilder 增删改的时候提前记录是否可能存在非 Latin 字符，避免后续对 byte[] 重复遍历扫描。

例如，在 GSON.toJson() 时，会调用 StringBuilder.append() 与 StringBuilder.toString() 方法，通过上述优化，可提高此方法在中英文混杂场景下的性能。

Scoped Heapdump

Java 大多数对象是符合“朝生夕死”的分代假说原理，G1GC 将长期存活的对象放在 Old 区，将短期存活的对象放在 Eden 区，仅有少部分对象需要实际在 STW 中拷贝。这部分对象的大小直接影响了 G1 YoungGC 的耗时，然而在传统 Heapdump 手段中，Eden、Old 区的对象将对我们的分析产生极大干扰，影响我们找到影响 YGC 的元凶。

RedJDK11 对 Jmap 进行了改造，可以指定 Dump 任意分区的对象 ，例如 scope=g1_survivor，再通过 MAT、Jifa 等工具分析即可。

2.2.3 Native内存治理

作为新一代 Malloc 实现，Jemalloc 完成了虚拟地址空间和物理内存的解构设计，持有大量的虚拟内存空间，减少系统调用的同时，Jemalloc 通过一系列设计防止物理内存的浪费，定期向操作系统归还过多缓存的物理内存：

• Jemalloc 以 4K 为内存管理的基本单元（Extent）——远小于Glibc 的 64M，与OS Page 大小保持一致；

• 所有用户分配会被向上取整到最接近的 alloc SizeClass，这些预设的 SizeClass 可以大幅减少内存块碎片化程度；

• 当一个 Extent 的内存全部被用户释放，将 Extent 放入缓存区，等待归还；

• Extent 的内存全部被用户释放会进入缓存区，在还给操作系统前，可以直接用来满足新的分配（减少进入内核态的频率）；

• 经过一段时间仍未重复利用的Extent将归还其物理内存，缓存其虚拟内存（减少系统调用频率）；这个频率可以通过参数 dirty_decay_ms 和 muzzy_decay_ms 配置，默认为10s；

采用 Jemalloc 替代 Ptmalloc 后实现：

• 内存碎片化控制：每个内核页（4K Bytes）只用于分配固定 Size 的内存，内存碎片问题得到解决。

• 内存回收机制：通过定时器和 malloc 活跃度及时将内存归还给 OS，控制 RSS 水位贴合应用实际需求。

• 泄漏诊断能力：支持 jeprof、malloc_stat_print、mallctl 等工具，可以分析 JVM 可见或不可见的 Native 内存，比 NMT 工具更全面、轻量。

• 低线程竞争开销：在 Jemalloc Arena 内，支持 Size Bin 粒度锁，多线程并发分配效率大大提高。

2.3 依赖版本升级

对于升级 JDK 的 Java 应用，需要筛查下依赖版本能否兼容 JDK11。Java 生态丰富，难以列举所有依赖版本。根据小红书的经验，这些依赖需要重点关注：

2.4 打包、测试、上线

完成上述工作，就可以打包上线了。在平台组支持下，小红书得以实现一整套构建、部署标准化流程，支持从 JDK8 的构建部署流程“一键切换”到 JDK11，并完成镜像、制品、JDK参数的管控。升级过程中业务团队仅需要少数操作与观察，即可平稳完成 JDK 升级。

3.1 RT变化

部分服务使用 JDK8 时 GC 卡顿严重，升级到 RedJDK11 后能看到 P99RT 明显下降，毛刺基本消除。下图为某核心场景晚高峰 RT 指标，黄线代表使用 JDK8 时晚高峰时段的 P99 RT，绿线为升级 RedJDK11 后的指标：

3.2 CPU使用率变化

CPU水位同样变化明显，通过升级 RedJDK11，许多服务能明显观测到 CPU 使用率水位下降，根据数百服务指标分析，全局平均可以取得 10% 的性能收益。

3.3 内存使用率变化

通过切换使用 Jemalloc Native 内存分配器，部分服务可以得到显著降低。且不再出现内存持续爬升上涨的问题。

3.4 总体成果

在各合作团队的支持与紧密配合下，我们成功支持推动小红书百万 CPU 规模的 Java 服务升级迁移到 RedJDK11，并支持大数据业务接入使用RedJDK17，规模可达数十万。取得多方面收益：

• CPU：

• 在保证性能没有下降的情况下，平均降低峰值 CPU 利用率 10%。

• 在 Flink 样本作业与 Spark 任务上，分别取得 15%  和 8.6% 的算力提升。

• 稳定性：

• GC STW 卡顿降低50%，显著减少P99 RT；

• 解决GC异常、进程内存爬升，OOM问题基本消除；

• 暴露出的 JVM Crash 问题基本解决；

• 架构提升：

• 完成JDK产品管控，在中间件服务框架和工程效率、发布平台团队的支持下，业务可以一键升级到JDK17、JDK21乃至更高版本JDK。

今年 AI 无疑是技术圈最火的话题之一了，Java 业务通常通过 SpringAI 框架快速打通 Spring 生态和 AI 技术生态。一方面，为了满足 Spring Framework 6+ 对 JDK 版本的要求（最低 JDK17），另一方面，我们十分看重 JDK 性能进一步提升，以及 Java 虚拟线程（JEP-444）、分代 ZGC（JEP-439）等高级运行时特性。

为此，小红书未来计划以 OpenJDK21 为新的支持底座，持续投入建设小红书的 RedJDK21 产品，支持 RedJDK21 产品和虚拟线程等技术在小红书生产环境落地，我们期待与业界分享技术红利，共同见证 Java 在当前时代下的机遇与挑战。

JDK21 性能测试

在 SPECjbb2015 基准测试中，根据 JDK21 vs JDK11 测试结果分析：

• Max-JOPS 指标：无延迟限制下的最大吞吐量，用于评估系统极限性能

• Critical-JOPS 指标：10ms、25ms、50ms、75ms、100ms下的综合吞吐量，反应生产环境实际吞吐性能

• P99 指标：在指定固定 P99 latency指标下的吞吐量

Java 虚拟线程

从 JDK21 开始 Java 虚拟线程特性宣布生产可用，这也是我们升级 JDK21 的一大动力。使用虚拟线程可以达到简化编程并提高应用吞吐的效果，小红书的 Java 服务具有请求耗时较短、网络I/O高的特点，使用虚拟线程预期能大幅提高服务吞吐，更充分得利用 CPU、内存等物理资源。

下图是 Java 虚拟线程调度示意图，相比于传统线程模型中，通过内核的调度能力处理阻塞于运行，Java 虚拟线程将任务的调度和执行放在 JVM 中完成，实现了 Java 逻辑和 OS 线程的结耦。当任务发生阻塞后，JVM 会妥善保存执行上下文，并选择可运行的 Java 任务开始或恢复运行。在这样的设计下，JVM 只需要创建少量的线程，就可以支持百万级并发任务的运行。

JVM 无法处理部分由平台 API 导致的阻塞 ，例如文件 I/O、JNI 阻塞以及 Synchronized，可能导致 JVM 处理能力下降。其中 Synchronized 运用最为广泛，从老架构迁移基本难以避开。在 OpenJDK24 之后的版本，社区通过底层重构（JEP-491）实现了虚拟线程对 Synchronized 关键字的支持，JDK24 并非 LTS版本，难以达到生产环境使用标准。因此，小红书决定跟随社区的步伐，基于 JDK21 彻底重构 Synchronized 和 ObjectMonitor的底层实现，支持虚拟线程下的任务挂起、切换，满足线上场景应用的需要。

继才（杨道谈）

小红书中间件负责人，曾就职于快手基础架构团队，目前整体负责小红书中间件的规划、研发和日常维护工作，负责微服务中间件（RPC、注册中心、配置中心、任务调度、服务治理）、消息中间件、JDK Runtime 三个领域方向工作。

凶真（刘侠麟）

小红书JDK研发负责人，毕业于华中科技大学，曾就职于快手JVM团队，目前是小红书 JDK 团队负责人，负责 RedJDK 的日常规划、研发 和 迭代工作，推进 JDK21、ZGC、多租户、虚拟线程在小红书落地。

沈浪（吕洪武）

小红书JDK研发工程师，毕业于北京理工大学，校招进入小红书 JDK 团队，目前主要从事 RedJDK17 在 Flink/Spark 的升级工作，同时推动 ZGC 在小红书的落地。

伊澄（易谦）

小红书JDK研发工程师，毕业于北京大学，校招进入小红书 JDK 团队，目前主要从事 JVM 多租户在热部署场景的落地、以及虚拟线程的工作。