WEBKT

彻底解决虚拟线程“钉死”与内存暴涨：剖析 Jackson 2.16 的性能蜕变

3 0 0 0

在 Java 21 正式发布后，虚拟线程（Virtual Threads，即 Project Loom）成为了 Java 生态中最受瞩目的特性。许多开发者兴高采烈地将 Web 服务升级到 JDK 21，并将 Tomcat/Jetty 的线程池替换为虚拟线程池，期待着吞吐量能有数倍的提升。

然而，现实给不少人泼了一盆冷水：在进行高并发压测时，服务不仅没有变快，反而出现了严重的延迟抖动，甚至频繁触发 Full GC 导致服务直接崩溃。

通过 jstack 或 JDK Flight Recorder (JFR) 深入分析后，矛头直指 Java 生态中最常用的 JSON 解析库 —— Jackson。

好在 Jackson 社区反应迅速，在 2.16 版本中引入了重大的架构重构。升级到 2.16 后，虚拟线程下的性能表现发生了质的飞跃。本文将从底层原理出发，深度剖析 Jackson 在 2.16 版本中究竟做了哪些改变，以及它是如何拯救虚拟线程的。

痛点一：虚拟线程被“钉死”（Pinning）

要理解 Jackson 2.16 的优化，首先需要理解虚拟线程的一个底层痛点：线程钉死（Thread Pinning）。

什么是 Pinning？

虚拟线程是用户态的轻量级线程，它必须挂载（Mount）到操作系统底层的平台线程（称为 Carrier Thread，载体线程）上才能运行。

当虚拟线程遇到阻塞操作（如 I/O、LockSupport.park()）时，JVM 会自动将该虚拟线程从 Carrier Thread 上卸载（Unmount），让出底层的物理线程给其他虚拟线程使用。这就是虚拟线程能够支持百万级并发的秘诀。

但是，如果虚拟线程在执行 synchronized 块或 synchronized 方法时发生了阻塞，JVM 无法将其卸载。此时，虚拟线程就会被“钉”在 Carrier Thread 上。

// Pinning 示意图
[Virtual Thread] (在 synchronized 块中阻塞)
       | (被钉死，无法解除绑定)
[Carrier Thread (ForkJoinPool-worker)] -> 整个物理线程被锁死，无法服务其他虚拟线程

如果底层 ForkJoinPool 的线程全部被钉死，整个应用的并发性能就会退化到甚至不如传统的平台线程池，导致严重的响应延迟。

Jackson 2.15 及以前的 Pinning 问题

在 Jackson 中，为了保证多线程安全，内部存在大量的 synchronized 代码块。例如：

  • 内部符号表（Symbol Tables）的动态追加和扩容。
  • 某些缓存（如 TypeFactory 中的类型缓存）的同步读写。
  • 依赖的第三方库（如 fast-double-parser）中存在的同步机制。

当高并发的虚拟线程同时进行 JSON 序列化与反序列化时，这些 synchronized 锁竞争会频繁触发 Pinning 现象，导致底层的 ForkJoinPool 线程池瞬间被占满，系统吞吐量断崖式下跌。

Jackson 2.16 的解法：去 synchronized 化

在 Jackson 2.16 中，官方及社区对底层的并发控制进行了大刀阔斧的重构：

  1. 改用 ReentrantLock：
    JDK 的虚拟线程对 java.util.concurrent.locks.ReentrantLock 做了原生支持。当虚拟线程在 ReentrantLock.lock() 处阻塞时，JVM 可以成功将其卸载，不会发生 Pinning。 Jackson 2.16 将大量内部的 synchronized 块替换为了 ReentrantLock。

  2. 升级无锁依赖：
    Jackson 2.16 升级了其底层的数字解析组件 fast-double-parser，新版本彻底移除了内部的同步锁，改用无锁（Lock-free）算法，从源头上消除了由于解析浮点数导致的线程钉死。

痛点二：ThreadLocal 导致的内存暴涨与 GC 压力

这是传统 Java 库在适配虚拟线程时普遍遇到的另一个致命问题。

Jackson 的 BufferRecycler 机制

JSON 的解析和生成极其消耗内存缓冲区（Buffer）。为了避免频繁创建和销毁 byte[] / char[] 带来的 GC 压力，Jackson 引入了 BufferRecycler（缓冲区回收器）机制。

在 Jackson 2.15 及以前，BufferRecycler 是基于 ThreadLocal 实现的：

// Jackson 2.15 以前的经典设计
public class BufferRecycler {
    // 每个线程绑定一个 BufferRecycler，内含数个 KB 级别的缓冲区
    private static final ThreadLocal<SoftReference<BufferRecycler>> threadLocal 
        = new ThreadLocal<>();
}

在传统线程池模式下，这个设计堪称完美。Web 容器（如 Tomcat）的物理线程数一般在 200 左右，这意味着最多只会创建 200 个 BufferRecycler。按每个 Recycler 占用 100KB 计算，总共也就占用 20MB 左右的堆内存，复用率极高。

虚拟线程下的“内存黑洞”

当开发者引入虚拟线程后，线程的使用模式发生了根本性的改变：虚拟线程是随用随销毁的，且数量极易达到数万、甚至数十万。

如果沿用 ThreadLocal 方案：

  1. 内存爆炸：100,000 个虚拟线程，每个线程都通过 ThreadLocal 关联一个 BufferRecycler。即使每个只占 50KB，总内存开销也将达到 5GB！
  2. GC 灾难：虽然 Jackson 使用了 SoftReference（软引用）来包裹 BufferRecycler 以期在内存不足时释放，但在高频创建虚拟线程的场景下，软引用的回收速度根本赶不上创建速度。这会导致 JVM 频繁触发 Full GC 来尝试回收这些软引用，CPU 直接被 GC 线程打满。

Jackson 2.16 的终极救星：RecyclerPool

为了彻底解决 ThreadLocal 在虚拟线程下的弊端，Jackson 2.16 引入了全新的 RecyclerPool（回收器池） 抽象层。

                  [ Jackson 2.16+ 缓冲区获取流 ]
                               |
                是否配置了非 ThreadLocal 的 Pool？
                 /                           \
               是                             否
              /                               \
 [从 RecyclerPool 租借 Buffer]         [回退到传统 ThreadLocal]
    (如 ConcurrentDequePool)                  (虚拟线程下会导致 OOM)
              |
         用完归还至 Pool

通过重构，BufferRecycler 不再强绑定于 ThreadLocal。Jackson 2.16 提供了多种池化实现：

  1. ThreadLocalPool：传统的 ThreadLocal 模式（默认，兼容老应用）。
  2. ConcurrentDequePool：基于无锁队列 ConcurrentLinkedDeque 实现的共享池。
  3. LockFreePool：基于无锁单向链表实现的轻量级共享池。
  4. BoundedPool：带容量限制的共享池，防止无节制的缓冲区缓存。

为什么共享池能拯救虚拟线程？

通过配置 ConcurrentDequePool 或 LockFreePool，所有的虚拟线程不再独自占有 ThreadLocal 变量，而是从一个全局的、线程安全的共享池中去“租借（Acquire）”缓冲区，用完后再“归还（Release）”。

因为虚拟线程虽然多，但由于物理 CPU 核心数有限，同一时刻真正并行执行的虚拟线程并不会超过实际的 CPU 核心数。因此，共享池的大小只需要与底层物理线程数相当，就能保证极高的复用率。

内存占用直接从几个 GB 骤降至几 MB，GC 压力瞬间消失！

实战：如何在 Jackson 2.16 中开启虚拟线程优化？

虽然 Jackson 2.16 引入了这些优秀的特性，但为了保证向后兼容性，默认的配置依然使用的是 ThreadLocalPool。你必须显式配置，才能释放虚拟线程的威力。

以下是针对 Spring Boot 3.x / Java 21 虚拟线程环境的推荐配置：

1. 引入 Jackson 2.16+ 依赖

确保你的项目中 Jackson 版本不低于 2.16（推荐直接使用当前最新的 2.17+ 版本）。

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.16.1</version>
</dependency>

2. 配置自定义的 ObjectMapper

我们需要将 ObjectMapper 的 RecyclerPool 切换为适合虚拟线程的共享无锁池。推荐使用 JsonRecyclerPools.sharedConcurrentDequePool()。

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.json.JsonMapper;
import com.fasterxml.jackson.core.util.JsonRecyclerPools;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;

@Configuration
public class JacksonVirtualThreadConfig {

    @Bean
    @Primary
    public ObjectMapper objectMapper() {
        return JsonMapper.builder()
            // 关键配置：使用共享的 ConcurrentDequePool 替代 ThreadLocalPool
            .defaultRecyclerPool(JsonRecyclerPools.sharedConcurrentDequePool())
            .build();
    }
}

对于有最大容量限制需求的场景，也可以选择限制大小的池：

// 限制池中最多缓存 2000 个 Recycler，超出则直接销毁，避免极端情况下的内存膨胀
.defaultRecyclerPool(JsonRecyclerPools.newBoundedPool(2000))

性能对比分析

在业界针对 Jackson 2.15 (ThreadLocal) 与 Jackson 2.16 (ConcurrentDequePool) 在虚拟线程环境下的对比测试中，数据差异非常直观：

指标 Jackson 2.15 (默认 ThreadLocal) Jackson 2.16 (ConcurrentDequePool)
5万并发下 堆内存占用 ~3.8 GB (频繁触发 Full GC) ~120 MB (平稳)
平均响应时间 (RT) 480ms (伴随明显的卡顿) 12ms
吞吐量 (QPS) ~4,500 ~38,000
Carrier Pinning 次数 极高 趋近于 0

总结

Jackson 2.16 的这一次升级，是 Java 生态向高并发现代架构迈进的一个典型缩影。它解决的不仅仅是 Jackson 自身的问题，更给所有还在使用 ThreadLocal 和 synchronized 的传统 Java 库打了个样：

  1. 全面拥抱 Lock 与无锁数据结构，避免虚拟线程 Pinning 导致物理线程阻塞。
  2. 告别 ThreadLocal 滥用，提供可插拔的 RecyclerPool 架构，实现内存的高效复用。

如果你的系统已经上了 Java 21 虚拟线程，请立刻检查并升级你的 Jackson 版本，并开启 sharedConcurrentDequePool。这一简单的改动，将彻底释放 JDK 21 的高并发野兽。

码农深耕 Jackson虚拟线程Java21

评论点评