WEBKT

JDK 21虚拟线程：哪些Native方法会引发Carrier Thread Pinning？如何排查与平替？

5 0 0 0

在JDK 21中，虚拟线程（Virtual Threads）的引入极大地提升了Java在高并发I/O场景下的吞吐量。然而，虚拟线程并非万能药。当虚拟线程中执行某些特定操作时，它会“钉”在底层的平台线程（Carrier Thread）上，导致其无法被卸载（unmount）。这种现象被称为 Carrier Thread Pinning（载体线程固定）。

一旦发生Pinning，底层的ForkJoinPool线程池就无法释放该物理线程去执行其他虚拟线程，如果大量物理线程被卡住，整个虚拟线程调度器就会陷入饥饿状态，系统性能甚至会退化到不如传统线程池的程度。

本文将深入探讨哪些本地方法（Native Method / JNI）调用会触发这种物理阻塞，以及在生产中如何进行排查与避坑。

一、 为什么Native方法会导致物理线程阻塞？

虚拟线程的协作式调度依赖于JVM对阻塞点的感知。当Java代码调用 java.nio 进行网络I/O，或者调用 LockSupport.park() 时，JVM能够捕获到这个阻塞信号，将虚拟线程的栈帧保存到堆中，并将其从载体线程（Carrier Thread）上卸载。

但是，当进入Native方法（JNI调用）后，JVM失去了对执行上下文的绝对控制权：

  1. 栈帧无法转移：JNI调用使用的是C/C++的系统栈，JVM无法简单地将C语言的栈帧剥离并移动到Java堆中。
  2. JVM无法拦截OS级阻塞：如果在C/C++代码中执行了阻塞式的系统调用（如 read、write、recv 或等待互斥锁），操作系统的内核会直接将当前的物理线程（即Carrier Thread）挂起。JVM对此无能为力，无法在此时进行虚拟线程的切换。

二、 典型触发Pinning的Native/系统调用场景

并不是所有的Native方法都会导致灾难性的Pinning。如果一个Native方法只是纯粹的CPU密集型计算（例如快速的数学运算），它虽然会占用Carrier Thread，但执行完后会立刻返回。

最致命的是在Native方法内部进行阻塞式操作。以下几类场景在实际开发中最为常见：

1. 嵌入式/本地数据库的JNI驱动

典型的如 RocksDB、SQLite。
这类数据库通常通过JNI调用底层的C++动态链接库。当执行读写操作时，如果触发了底层的磁盘I/O、锁等待（Mutex）或合并写（Log Flush），Native代码会阻塞当前线程。

  • 后果：虚拟线程被Pin在Carrier Thread上，物理线程直接进入OS级别的BLOCKED/WAITING状态。

2. 非Java原生实现的加密与安全库

很多企业为了追求极致性能，会使用基于OpenSSL的JNI绑定（例如 Netty 的 netty-tcnative 或 Apache Tomcat 的 APR 库）。

  • 当这些库在Native层进行硬核的密钥生成、大文件加解密，或者等待硬件安全模块（HSM）返回时，会长时间霸占并阻塞物理线程。

3. 未托管的文件系统或网络操作

虽然JDK自身的 java.io.FileInputStream 和 Socket 在JDK 21中已经重构以适配虚拟线程，但很多第三方的C/C++库通过JNI自己实现了文件读写或网络收发。

  • 例如：某些商用中间件的私有传输协议SDK、GPU加速的本地网络套接字等。它们绕过了JDK的NIO通道，直接在C层调用 socket() 和 connect()。

4. JNI中的临界区锁定（Critical Sections）

在JNI规范中，为了防止GC移动内存，开发者会使用 GetPrimitiveArrayCritical 或 GetStringCritical 来获取指向Java堆中数组或字符串的直接指针。

  • 在这两个调用之间，JVM会禁止GC，并且当前的物理线程不能被挂起或切换。如果在临界区内执行了耗时操作或调用了其他阻塞式Native方法，将导致严重的Pinning，甚至引发整个JVM的GC停顿。

三、 如何在生产环境中精准排查？

要解决Pinning问题，首先需要知道它发生在哪里。JDK 21提供了两套非常有效的排查工具。

方法一：利用系统属性进行控制台诊断

在JVM启动参数中，加入以下参数。这可以在虚拟线程发生Pinning时，直接在标准输出中打印出其Java调用栈：

# 推荐使用 full，它会打印完整的Java堆栈信息
-Djdk.tracePinnedThreads=full
  • -Djdk.tracePinnedThreads=short：只打印受限的堆栈单行信息。
  • -Djdk.tracePinnedThreads=full：打印详细堆栈，精准定位到是哪个Java类、哪一行代码调用了导致Pinning的Native方法。

输出示例：

Thread[#21,ForkJoinPool-1-worker-1,5,CarrierThreads]
    java.base/java.lang.VirtualThread$PinnedThreadPrinter.printStackTrace(VirtualThread.java:2605)
    java.base/java.lang.VirtualThread.parkOnCarrierThread(VirtualThread.java:685)
    java.base/java.lang.VirtualThread.park(VirtualThread.java:596)
    ...
    com.example.db.NativeLib.fetchData(Native Method) <--- 罪魁祸首

方法二：使用JDK Flight Recorder (JFR)

在生产高并发环境下，控制台打印可能带来额外的性能开销。推荐使用JFR进行异步无感采样：

  1. 启动JFR监控：
    java -XX:StartFlightRecording=filename=recording.jfr,settings=default -jar app.jar
  2. 使用 JDK Mission Control (JMC) 打开生成的 recording.jfr 文件。
  3. 搜索 jdk.VirtualThreadPinned 事件。该事件会记录Pinning发生的持续时间（Duration）和具体的线程堆栈。通常，持续时间超过20ms的Pinning事件需要重点关注。

四、 规避与平替方案

既然Native方法阻塞无法避免，我们可以通过架构调整和代码重构来化解这种影响。

方案一：将Native阻塞任务隔离到传统的“平台线程池”

虚拟线程的设计初衷是处理“高并发、高I/O、轻量级”的Java任务。对于天然会阻塞物理线程的Native操作，不应该使用虚拟线程执行，而应该使用专门的传统线程池（Platform Threads）进行隔离。

public class NativeService {
    // 专门为Native/JNI阻塞任务预留的传统线程池
    private static final ExecutorService NATIVE_POOL = Executors.newFixedThreadPool(
        Runtime.getRuntime().availableProcessors() * 2,
        r -> {
            Thread t = new Thread(r);
            t.setName("native-worker");
            return t;
        }
    );

    public CompletableFuture<byte[]> decryptData(byte[] cipherData) {
        // 将JNI调用提交给传统的物理线程池，不占用虚拟线程的Carrier Thread
        return CompletableFuture.supplyAsync(() -> {
            return nativeDecrypt(cipherData); // 这是一个JNI阻塞方法
        }, NATIVE_POOL);
    }

    private native byte[] nativeDecrypt(byte[] data);
}

方案二：寻找纯Java实现的平替库（Pure Java Alternative）

由于JDK 21对重构后的Java标准I/O库（NIO）有着完美的虚拟线程支持，优先选择纯Java实现的第三方库往往能带来质的飞跃。

  • 加密库：如果使用OpenSSL（如 netty-tcnative）导致频繁Pinning，在并发要求极高且网络瓶颈大于CPU瓶颈的场景下，可以考虑回退到JDK自带的 JSSE (Java Secure Socket Extension)。
  • 数据库驱动：确保使用的JDBC驱动是纯Java实现（如官方的PgJDBC、MySQL Connector/J），避免使用依赖本地C连接（如OCI等）的驱动。
  • 压缩算法：使用纯Java移植版本的 Zstd-jni 或 LZ4（例如利用 Brotli4j 时注意其JNI阻塞表现，必要时寻找纯Java实现）。

方案三：利用 ReentrantLock 替代 synchronized（补充说明）

虽然这不是Native直接引起的，但很多开发者在编写JNI包装类时，习惯用 synchronized 包裹Native调用：

// 错误示范：synchronized + Native 会导致双重Pinning风险
public synchronized native void writeToDevice(byte[] data);

在JDK 21中，虚拟线程在 synchronized 块内阻塞同样会触发Pinning。因此，如果必须要对Native方法进行并发控制，必须将其重构为 ReentrantLock：

private final ReentrantLock lock = new ReentrantLock();

public void writeToDeviceSafe(byte[] data) {
    lock.lock();
    try {
        writeToDevice(data); // 即使JNI阻塞，至少去除了synchronized带来的Pinning副作用
    } finally {
        lock.unlock();
    }
}

总结

虚拟线程为Java带来了极佳的并发表现，但也对底层的调用栈提出了“纯净度”的要求。在迁移到JDK 21时，团队需要对底层依赖中的 JNI调用、本地C/C++动态链接库、非JVM托管的系统调用 进行全面体检。通过 -Djdk.tracePinnedThreads 尽早暴露风险，并采用“传统平台线程池隔离”或“纯Java平替”的策略，才能让虚拟线程真正发挥出高吞吐的威力。

码道探针 JDK21虚拟线程JNI

评论点评