JDK21中虚拟线程和FFM协同实现高并发源码剖析

虚拟线程和FFM协同实现高并发

• 前言
• 虚拟线程和FFM协同实现高并发
• • [线程身份模型与内存约束：`ConfinedSession` 的底层协同](#线程身份模型与内存约束：ConfinedSession 的底层协同)
  • • [JDK 源码级剖析：`jdk.internal.foreign.ConfinedSession`](#JDK 源码级剖析：jdk.internal.foreign.ConfinedSession)
    • [虚拟线程跨 Carrier 调度时的 CPU 栈与内存校验序列图](#虚拟线程跨 Carrier 调度时的 CPU 栈与内存校验序列图)
  • [Downcall Stub 汇编生成与 Continuation Freeze 引擎深解析](#Downcall Stub 汇编生成与 Continuation Freeze 引擎深解析)
  • • [HotSpot C++ 源码剖析：Downcall Stub 状态转换](#HotSpot C++ 源码剖析：Downcall Stub 状态转换)
    • [HotSpot Continuation 冻结引擎对 Native 栈帧的拦截机制](#HotSpot Continuation 冻结引擎对 Native 栈帧的拦截机制)
    • [`Linker.Option.isTrivial()` 的汇编级绕过与协作](#Linker.Option.isTrivial() 的汇编级绕过与协作)
  • [状态隔离与捕获：`captureCallState` 消除 TLS 踩内存](#状态隔离与捕获：captureCallState 消除 TLS 踩内存)
  • • [物理 TLS 踩内存灾难分析](#物理 TLS 踩内存灾难分析)
    • [Panama `captureCallState` 底层汇编注入源码分析](#Panama captureCallState 底层汇编注入源码分析)
  • [深度实战：结合 io_uring、Panama FFM 与 Loom 的端到端非阻塞 Pipeline](#深度实战：结合 io_uring、Panama FFM 与 Loom 的端到端非阻塞 Pipeline)
  • 协同机制演进对比矩阵

---

前言

本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。

虚拟线程和FFM协同实现高并发

Project Panama（Foreign Function & Memory API, FFM）与 Project Loom（Virtual Threads & Continuations）的协同，是 OpenJDK 在内核级（JVM HotSpot + Java Runtime）对 "高并发并发吞吐" 与 "Native 互操作" 进行的一场深度重构。

线程身份模型与内存约束：ConfinedSession 的底层协同

在 Java 21+ 的外层接口（FFM API）中，Arena.ofConfined() 提供了无锁（Zero-Lock）的堆外内存生命周期管理。要理清 Panama 与 Loom 的协同，首先需要从 HotSpot JVM 的线程模型与 JDK 内部 MemorySessionImpl 源码切入。

虚拟线程（VirtualThread）的本质是由 ForkJoinPool 管理的 Continuation 任务。当虚拟线程挂起或恢复时，它会被同一个或不同的底层载体线程（Carrier Thread, 即 ForkJoinWorkerThread）调度。Panama 的 ConfinedSession 必须确保：内存段的属主判定依赖于逻辑上的 VirtualThread 实例，而非物理上的 Carrier Thread。

JDK 源码级剖析：jdk.internal.foreign.ConfinedSession

以下为 ConfinedSession 的核心实现机制（基于 OpenJDK 21 源码抽象与拓展分析）：

package jdk.internal.foreign;

import java.lang.foreign.MemorySegment;
import jdk.internal.vm.annotation.ForceInline;

/**
 * 线程限定的内存会话实现（Confined Memory Session）
 * 专为单线程/单虚拟线程的高性能堆外访问设计，剥离所有 CAS 与 Synchronized 锁开销。
 */
public final class ConfinedSession extends MemorySessionImpl {

    // 【关键字段】记录当前 Session 的逻辑属主线程 (Owner Thread)
    // 在 Loom 架构下，此字段指向 java.lang.VirtualThread 实例，而非物理 Carrier Thread
    private final Thread owner;

    public ConfinedSession(Thread owner, ResourceCleaner cleaner) {
        super(cleaner);
        this.owner = owner;
    }

    /**
     * 每次 MemorySegment 进行 Get/Set 读写时，HotSpot C2 编译器都会将此校验内联到最前端。
     * 校验逻辑：当前执行代码的逻辑线程句柄是否与创建 Session 时的句柄一致。
     */
    @Override
    @ForceInline
    public void checkValidState() {
        // 1. 检查 Session 是否已被 Close
        checkValidStateRaw();
        
        // 2. 线程安全性校验：Thread.currentThread() 返回当前挂载的 VirtualThread 实例
        // 即使当前 VirtualThread 刚刚从 Carrier-A 发生 Context Switch 挂载到 Carrier-B，
        // Thread.currentThread() 依然恒等于 this.owner (即 VirtualThread-1)。
        // 因此不会抛出 WrongThreadException，完美契合物理线程流转。
        if (Thread.currentThread() != owner) {
            throw new WrongThreadException("Memory session is confined to thread " +
                owner.getName() + " but accessed from " + Thread.currentThread().getName());
        }
    }

    /**
     * 极轻量级的 Raw 状态检查，C2 编译器会将其优化为单条 CPU 比较指令（cmp + jne）
     */
    @ForceInline
    private void checkValidStateRaw() {
        if (state <= CLOSED) {
            throw new IllegalStateException("Session is closed");
        }
    }
}

虚拟线程跨 Carrier 调度时的 CPU 栈与内存校验序列图

当虚拟线程在操作 ConfinedArena 时发生 I/O 并挂起，HotSpot 内部的 Thread Identity 绑定逻辑如下：

+---------------------------------------------------------------------------------------------------+
| [VirtualThread-1 (java.lang.Thread 实例, ID: 101)]                                                 |
|  ├── MemorySegment-A (ConfinedSession.owner = VirtualThread-1)                                    |
|                                                                                                   |
| [Phase 1: 运行在 Carrier-A (ForkJoinWorkerThread-1) 上]                                            |
|   └── MemorySegment.get(JAVA_INT, 0L)                                                             |
|       └── checkValidState(): Thread.currentThread() [VirtualThread-1] == owner [VirtualThread-1] |
|       └── SUCCESS                                                                                 |
|                                                                                                   |
| ─────────────────────────────── [发生 I/O, Park 挂起, Unmount] ───────────────────────────────── |
|                                                                                                   |
|  1. Continuation.yield() 触发 Stack Freeze                                                       |
|  2. VirtualThread-1 的 Java 栈帧打包保存至 Heap (stackChunkOop)                                     |
|  3. Carrier-A 物理线程归还 ForkJoinPool，继续处理其他 VirtualThread                                  |
|                                                                                                   |
| ─────────────────────────────── [I/O 完成, Unpark 唤醒, Remount] ─────────────────────────────── |
|                                                                                                   |
| [Phase 2: 被调度至 Carrier-B (ForkJoinWorkerThread-2) 恢复运行]                                     |
|  1. Continuation.thaw() 从 Heap 还原栈帧至 Carrier-B 的 OS Stack                                     |
|  2. 恢复代码执行点: MemorySegment.get(JAVA_INT, 0L)                                                |
|  3. checkValidState(): Thread.currentThread() 依然返回 [VirtualThread-1]                            |
|       └── checkValidState(): Thread.currentThread() [VirtualThread-1] == owner [VirtualThread-1] |
|       └── SUCCESS (无锁零摩擦过渡)                                                                |
+---------------------------------------------------------------------------------------------------+

---

Downcall Stub 汇编生成与 Continuation Freeze 引擎深解析

Project Panama 抛弃了传统 JNI 的硬编码 C 函数转换表，改由 C2 编译器在运行时动态生成汇编适配器（Downcall Stub）。了解 Downcall Stub 的生成逻辑以及 HotSpot 引擎如何检查 Native 栈帧，是理解 Loom 预防 Carrier Pinning（物理线程固定）的关键。

HotSpot C++ 源码剖析：Downcall Stub 状态转换

当通过 Panama 的 Linker.downcallHandle() 调用 Native 代码时，JVM 会动态生成一段汇编 Stub。以下为 HotSpot VM 中 Downcall Stub 生成逻辑的简化 C++ 实现（逻辑对应 src/hotspot/cpu/x86/foreign_globals_x86.cpp 与 SharedRuntime）：

// hotspot/src/share/vm/runtime/sharedRuntime.cpp (Downcall Stub 状态切换逻辑)

void ForeignDowncallLinker::generate_downcall_stub(MacroAssembler* masm, const CallMethodSizes& sizes) {
    // 1. 保存 Java 侧线程上下文（RBP, Register Arguments 等）
    __ push(rbp);
    __ mov(rbp, rsp);
    
    // 2. 将当前 JavaThread 状态从 _thread_in_Java 切换为 _thread_in_native
    // 这是 Safepoint 机制的核心：标记当前线程已进入 Native，GC 无需等待该线程到达 Safepoint
    __ movl(Address(r15_thread, JavaThread::thread_state_offset()), _thread_in_native);

    // 3. 跨越 C ABI 边界：执行真正的 Native C 函数调用
    // RAX 存有目标 C 函数的绝对内存地址
    __ call(rax);

    // 4. 从 Native 返回后，必须优先检查全局 Safepoint 状态！
    // 将线程状态重新切换回 _thread_in_Java
    __ movl(Address(r15_thread, JavaThread::thread_state_offset()), _thread_in_Java);

    // 5. 检查 Safepoint Poll 标记 (SafepointMechanism)
    Label L_safepoint;
    __ testl(rax, Address(r15_thread, JavaThread::polling_word_offset()));
    __ jcc(Assembler::notZero, L_safepoint);

    __ leave();
    __ ret(0);

    // 迟滞处理 Safepoint / Suspend 请求
    __ bind(L_safepoint);
    __ call(RuntimeAddress(StubRoutines::forward_exception_entry()));
}

HotSpot Continuation 冻结引擎对 Native 栈帧的拦截机制

当虚拟线程在运行过程中尝试挂起（如调用 LockSupport.park()）时，Loom 的 Continuation.yield() 会调用 HotSpot 的 C++ 冻结引擎 Continuation::freeze（位于 src/hotspot/share/runtime/continuationFreezeThaw.cpp）。

冻结引擎会自顶向下扫描当前 Carrier 物理栈上的每一个栈帧。如果发现栈帧中包含 Native C 帧 或 Panama Standard Downcall Stub 帧 ，就会将当前虚拟线程标记为 Pinned。

// hotspot/src/share/runtime/continuationFreezeThaw.cpp

template<typename Config>
FreezeBase::result ContinuationFreeze::recurse_freeze(frame& f, frame& caller) {
    // 循环遍历物理 OS 栈上的每个 Stack Frame
    while (!is_last_frame(f)) {
        
        // 1. 检查当前栈帧类型
        if (f.is_interpreted_frame()) {
            freeze_interpreted_frame(f);
        } else if (f.is_compiled_frame()) {
            freeze_compiled_frame(f);
        } else if (f.is_native_frame() || f.is_safepoint_blob_frame()) {
             // 2. 【核心 Pinning 触发点】
             // 如果在 Continuation 作用域内部扫描到了 Native 栈帧（例如正处于 Panama Standard Downcall 调用中），
             // HotSpot 无法将 C/C++ 的物理 RSP/RBP 栈帧结构安全的序列化至 Java 堆 (stackChunkOop)。
             // 此时将返回 freeze_pinned 状态！
             return freeze_pinned; 
        }

        f = sender(f); // 移动至前一个调用者栈帧
    }
    return freeze_ok;
}

Linker.Option.isTrivial() 的汇编级绕过与协作

如果 Native 函数极其短暂且绝对不包含阻塞操作（如 C 标准库 getpid、clock_gettime），Panama 提供了 isTrivial() = true 选项。它在汇编层面剥离了线程状态切换，彻底优化了与 Loom 的协同摩擦：

===================================================================================================
Standard Downcall vs Trivial Downcall 汇编级指令序列对比
===================================================================================================

Standard Downcall Stub (无 isTrivial)               Trivial Downcall Stub (指定 isTrivial)
------------------------------------               ---------------------------------------
1. Push/Save Java Registers                        1. Push/Save Minimal Registers
2. Atomic Store: _thread_in_native (内存屏障)       2. CALL [Native C Function Address] (直接调用)
3. CALL [Native C Function Address]                3. Pop/Restore Registers
4. Atomic Store: _thread_in_java                   4. RET (直接返回，无 Safepoint Check，无 Pinning 风险)
5. Test Safepoint Poll Flag & Conditional Branch
6. Pop/Restore Java Registers
7. RET

isTrivial() 去掉了对 JavaThread::thread_state_offset() 的状态修改。对于 JVM 而言，整个过程线程始终处于 _thread_in_Java 状态。由于执行时间极短（纳秒级），它绝不会成为 Block 节点，从而消除了运行期触碰 SafePoint 以及对 Loom 栈帧扫描的干扰。

---

状态隔离与捕获：captureCallState 消除 TLS 踩内存

在传统 JNI 架构中，Native C/C++ 库通常依赖操作系统的 Thread Local Storage (TLS) 存储全局错误状态（例如 Linux 的 errno 或 Windows 的 GetLastError()）。

物理 TLS 踩内存灾难分析

在 Loom 架构下，多个 Virtual Thread 会高频轮流复用同一个 Carrier OS Thread。如果 Native 库使用全局 TLS 保存状态，会导致严重的并发竞态条件（Data Race）：

[ Carrier OS Thread (POSIX Thread ID: 0x7FFF1000) - TLS errno 地址: 0x7FFF1008 ]

  VirtualThread-1 (运行于 Carrier 上)
      │
      ├──> 调用 Panama Downcall: open("/invalid_path", O_RDONLY)
      ├──> Linux 内核设置 OS TLS: [0x7FFF1008] = ENOENT (2)
      │
      ├──> 【上下文切换】 VirtualThread-1 被 Park 挂起 (Unmount)
      │
  VirtualThread-2 (被调度至同一个 Carrier 上)
      │
      ├──> 调用 Panama Downcall: read(-1, buf, 100)
      ├──> Linux 内核覆盖 OS TLS: [0x7FFF1008] = EBADF (9)
      │
      ├──> 【上下文切换】 VirtualThread-2 被 Park 挂起
      │
  VirtualThread-1 (重新被 Unpark 恢复至该 Carrier 上)
      │
      └──> 读取 Native errno ──► 读到了 VirtualThread-2 残留的 EBADF (9)！【数据污染/崩溃】

Panama captureCallState 底层汇编注入源码分析

为了解决该协同漏洞，Panama 在 Downcall Stub 生成阶段直接将 Native errno 从 CPU 寄存器/OS TLS 快速转存至当前 Virtual Thread 独占的堆外内存 MemorySegment 中。

以下为 HotSpot 生成带有 captureCallState 的 Downcall Stub 源码逻辑解析（简化自 jdk.internal.foreign.abi.NativeEntryPoint 与 JIT Stub 逻辑）：

package jdk.internal.foreign.abi;

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.VarHandle;

/**
 * Panama 状态捕获机制示范：将 OS Thread-Local 状态打散并绑定到 Java MemorySegment
 */
public final class CallStateCapturer {

    // 1. 映射内核 state 结构体 (包含 errno 和 GetLastError)
    public static final StructLayout CAPTURED_STATE_LAYOUT = StructLayout.enumLayout(
        ValueLayout.JAVA_INT.withName("errno"),
        ValueLayout.JAVA_INT.withName("win_error")
    );

    private static final VarHandle ERRNO_HANDLE = CAPTURED_STATE_LAYOUT.varHandle(
        MemoryLayout.PathElement.groupElement("errno")
    );

    /**
     * 构建一个具备上下文隔离的 Downcall MethodHandle
     */
    public static MethodHandle makeCapturedDowncall(SymbolLookup lookup, String functionName, FunctionDescriptor fd) {
        Linker linker = Linker.nativeLinker();
        MemorySegment nativeSymbol = lookup.find(functionName).orElseThrow();

        // 2. 通过 Linker.Option.captureCallState 指定需要捕获的状态名称
        Linker.Option option = Linker.Option.captureCallState("errno");

        // 3. 生成 Downcall MethodHandle
        // 生成的 Stub 签名会在原始参数列表的第一位强行注入一个 Destination MemorySegment 引用
        return linker.downcallHandle(nativeSymbol, fd, option);
    }

    /*
     * 下面是 Downcall Stub 被调用时的 HotSpot 内部汇编执行伪流程：
     * 
     * [ Assembly Generated by HotSpot DowncallStub ]
     * 1. MOV RDI, [Address of Captured MemorySegment]  ; 获取 Java 传入的 MemorySegment 物理地址
     * 2. CALL Native_Function                           ; 执行 C 语言库函数 (例如 open)
     * 3. MOV R10, RAX                                   ; 暂存 C 函数返回值
     * 4. CALL tls_address_lookup_errno                  ; 快速获取当前 OS TLS 中 errno 的指针 (e.g., %fs:0)
     * 5. MOV EAX, DWORD PTR [RAX]                       ; 读取 CPU 刚才设置的 errno 值
     * 6. MOV DWORD PTR [RDI + 0], EAX                   ; 【关键】直接写入 MemorySegment 偏移量 0 处！
     * 7. MOV RAX, R10                                   ; 恢复 C 函数返回值到 RAX
     * 8. RET                                            ; 返回 Java
     */

    public static void executeIsolatedCall(MethodHandle downcallHandle, Arena confinedArena) throws Throwable {
        // 为当前 Virtual Thread 分配专属的捕获段
        MemorySegment capturedState = confinedArena.allocate(CAPTURED_STATE_LAYOUT);

        // 调用 Downcall：Downcall Stub 在 C 函数返回的 1 个 CPU 指令周期内，
        // 立即将 errno 写入 capturedState，完全脱离了对 OS Thread TLS 的长期依赖。
        int res = (int) downcallHandle.invokeExact(capturedState, /* arg1 */ 0);

        if (res < 0) {
            // 安全地提取属于当前 Virtual Thread 的 errno，绝不会被其他 Carrier 上的 Virtual Thread 污染
            int errorCode = (int) ERRNO_HANDLE.get(capturedState, 0L);
            System.err.println("VirtualThread " + Thread.currentThread() + " failed with errno: " + errorCode);
        }
    }
}

---

深度实战：结合 io_uring、Panama FFM 与 Loom 的端到端非阻塞 Pipeline

要实现百万级高并发且彻底避免 Carrier Thread Pinning，架构模式必须是：Panama 负责纯非阻塞 Native 指令提交/内存映射 + Loom 负责线程挂起与事件驱动调度。

以下展示一个完整的、具备生产级注释的端到端异步文件 I/O 引擎。代码演示了 Panama FFM 调用 Linux io_uring 系统调用提交异步 SQE，并借助 LockSupport.park() 将 Virtual Thread 挂起，由统一的 CQE Reaper Poller 唤醒的全过程。

package com.concurrency.panama.loom;

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.VarHandle;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.LockSupport;

import static java.lang.foreign.ValueLayout.*;

/**
 * 结合 Panama FFM, Linux io_uring 与 Project Loom 的极致高并发 I/O 引擎
 */
public final class IoUringLoomEngine implements AutoCloseable {

    // ==================== 1. Panama C ABI 结构体与系统调用定义 ====================

    // struct io_uring_sqe (Submission Queue Entry) - 64 字节
    private static final GroupLayout SQE_LAYOUT = MemoryLayout.structLayout(
        JAVA_BYTE.withName("opcode"),
        JAVA_BYTE.withName("flags"),
        JAVA_SHORT.withName("ioprio"),
        JAVA_INT.withName("fd"),
        JAVA_LONG.withName("off"),
        JAVA_LONG.withName("addr"),
        JAVA_INT.withName("len"),
        JAVA_INT.withName("op_flags"),
        JAVA_LONG.withName("user_data"), // 核心：保存 Java IOOpContext 内存句柄/ID
        JAVA_SHORT.withName("buf_index"),
        JAVA_SHORT.withName("personality"),
        JAVA_INT.withName("file_index"),
        MemoryLayout.paddingLayout(16)
    );

    // struct io_uring_cqe (Completion Queue Entry) - 16 字节
    private static final GroupLayout CQE_LAYOUT = MemoryLayout.structLayout(
        JAVA_LONG.withName("user_data"), // 对应 SQE 传入的 user_data
        JAVA_INT.withName("res"),        // 异步操作返回值 (e.g. 读取到的字节数)
        JAVA_INT.withName("flags")
    );

    private static final byte IORING_OP_READ = 22;
    private static final byte IORING_OP_WRITE = 23;

    private static final MethodHandle SYS_IO_URING_SETUP;
    private static final MethodHandle SYS_IO_URING_ENTER;

    static {
        Linker linker = Linker.nativeLinker();
        SymbolLookup lookup = linker.defaultLookup();

        // 绑定 sys_io_uring_setup(entries, params)
        SYS_IO_URING_SETUP = lookup.find("io_uring_setup")
            .map(sym -> linker.downcallHandle(sym, FunctionDescriptor.of(JAVA_INT, JAVA_INT, ADDRESS)))
            .orElseThrow();

        // 绑定 sys_io_uring_enter(fd, to_submit, min_complete, flags, sig)
        // 注意：此处无 isTrivial，因为进入内核可能会有轻微延时，但由于是异步提交，它迅速返回，不会长时间卡死
        SYS_IO_URING_ENTER = lookup.find("io_uring_enter")
            .map(sym -> linker.downcallHandle(sym, FunctionDescriptor.of(JAVA_INT, JAVA_INT, JAVA_INT, JAVA_INT, JAVA_INT, ADDRESS)))
            .orElseThrow();
    }

    // ==================== 2. Loom 异步挂起桥接数据结构 ====================

    /**
     * 挂起请求上下文：连接 Virtual Thread 挂起状态与 Native CQE 异步回调
     */
    private static final class IOOpContext {
        // 记录发起请求的 VirtualThread 引用
        final Thread virtualThread = Thread.currentThread();
        // Native 操作结果
        volatile int result;
    }

    private final int ringFd;
    private final Arena sharedArena;
    private final MemorySegment sqRingSegment;
    private final MemorySegment cqRingSegment;
    
    // 全局请求 Register 表：user_data_id -> IOOpContext
    private final ConcurrentHashMap<Long, IOOpContext> pendingOps = new ConcurrentHashMap<>();
    private final AtomicLong userDataSequencer = new AtomicLong(1);
    
    private final Thread reaperThread;
    private volatile boolean running = true;

    public IoUringLoomEngine(int queueDepth) throws Throwable {
        this.sharedArena = Arena.ofShared(); // 跨 Reaper 平台线程与 Virtual Thread 共享
        
        // 1. 调用 io_uring_setup 初始化 Ring Buffer
        MemorySegment params = sharedArena.allocate(120); // sizeof(struct io_uring_params)
        params.fill((byte) 0);
        
        this.ringFd = (int) SYS_IO_URING_SETUP.invokeExact(queueDepth, params);
        if (this.ringFd < 0) {
            throw new RuntimeException("io_uring_setup failed: " + this.ringFd);
        }

        // 2. 映射 SQ 与 CQ 物理 Segment (简化演示，直接分配 Shared 内存切片)
        this.sqRingSegment = sharedArena.allocate(SQE_LAYOUT.byteSize() * queueDepth);
        this.cqRingSegment = sharedArena.allocate(CQE_LAYOUT.byteSize() * queueDepth);

        // 3. 启动后台 CQE Reaper 轮询线程 (使用专职平台线程，负责批量 Unpark 虚拟线程)
        this.reaperThread = Thread.ofPlatform().daemon().name("io_uring-cqe-reaper").start(this::reapCompletionLoop);
    }

    // ==================== 3. 面向 Virtual Thread 的高并发非阻塞 API ====================

    /**
     * 异步读取接口 (虚拟线程调用此方法时呈现"同步"阻塞编码风格，底层完全非阻塞)
     */
    public int readAsync(int fileFd, MemorySegment targetBuffer, long offset) throws Throwable {
        long userData = userDataSequencer.getAndIncrement();
        IOOpContext context = new IOOpContext();
        
        // 在 Map 中注册当前上下文
        pendingOps.put(userData, context);

        // 1. 构建 Panama SQE 结构体并写入内存
        MemorySegment sqe = sqRingSegment.asSlice(0, SQE_LAYOUT.byteSize());
        sqe.fill((byte) 0);
        sqe.set(JAVA_BYTE, 0, IORING_OP_READ);                   // opcode
        sqe.set(JAVA_INT, 4, fileFd);                             // fd
        sqe.set(JAVA_LONG, 8, offset);                            // off
        sqe.set(ADDRESS, 16, targetBuffer);                       // addr
        sqe.set(JAVA_INT, 24, (int) targetBuffer.byteSize());     // len
        sqe.set(JAVA_LONG, 32, userData);                         // user_data

        // 2. 发起 Native 系统调用提交 SQE (非阻塞提交)
        // to_submit = 1, min_complete = 0 (立刻返回，不阻塞 Carrier)
        SYS_IO_URING_ENTER.invokeExact(ringFd, 1, 0, 0, 0, MemorySegment.NULL);

        // 3. 【核心协同点】：挂起当前 Virtual Thread！
        // Continuation 引擎扫描当前栈，发现全是纯净 Java 编译帧 (Compiled Frame)，
        // 成功将 Virtual Thread 解绑定，Carrier 线程被立即释放回 ForkJoinPool！
        LockSupport.park();

        // 4. 当 CQE Reaper 收到内核完成通知并唤醒当前 Virtual Thread 后，从此处恢复执行
        return context.result;
    }

    // ==================== 4. Background Reaper 线程与 Unpark 唤醒机制 ====================

    private void reapCompletionLoop() {
        MemorySegment cqeSlice = cqRingSegment.asSlice(0, CQE_LAYOUT.byteSize());
        
        while (running) {
            try {
                // 阻塞式等待内核 CQE 事件到来 (min_complete = 1)
                // 此处运行在专职 Platform Thread，绝不占用 ForkJoinPool Carrier 资源
                int ret = (int) SYS_IO_URING_ENTER.invokeExact(ringFd, 0, 1, 1, 0, MemorySegment.NULL);
                if (ret < 0) continue;

                // 解析 CQE 结构体数据
                long userData = cqeSlice.get(JAVA_LONG, 0);
                int res = cqeSlice.get(JAVA_INT, 8); // 读取到的结果字节数

                if (userData != 0) {
                    // 弹出关联的上下文
                    IOOpContext context = pendingOps.remove(userData);
                    if (context != null) {
                        context.result = res;
                        
                        // 【核心协同点】：精准唤醒对应的 Virtual Thread
                        // 将该 Virtual Thread 重新放入 ForkJoinPool 的 Task Queue 中，
                        // 准备在某个空闲 Carrier 线程上恢复执行（Thaw）
                        LockSupport.unpark(context.virtualThread);
                    }
                }
            } catch (Throwable t) {
                if (!running) break;
            }
        }
    }

    @Override
    public void close() {
        this.running = false;
        this.reaperThread.interrupt();
        if (sharedArena.scope().isAlive()) {
            sharedArena.close();
        }
    }
}

---

协同机制演进对比矩阵

系统维度	传统 JNI + 平台线程 (Platform Thread)	传统 JNI + 虚拟线程 (Loom)	Project Panama (FFM) + Project Loom (最佳实践)
并发容量上限	受限于 OS 线程数 ( ≈ 1 , 000 ∼ 10 , 000 \approx 1,000 \sim 10,000 ≈1,000∼10,000)	受限于内存，但 JNI 阻塞会导致 Carrier Pinning，并发急剧下降	百万级 (1,000,000+) 无压力
内存访问安全	无校验，指针越界直接导致 JVM 崩溃（Segmentation Fault）	同左	MemorySegment + ConfinedSession 提供边界检查与线程所有权校验
物理线程固定 (Carrier Pinning)	N/A (使用原生 OS 线程)	高风险：JNI 栈帧在 Continuation::freeze 时强制触发 Pinning	零 Pinning ：通过非阻塞提交 + LockSupport.park() 解耦
Thread Local 数据污染	OS TLS 绑定物理线程，安全	高风险 ：多个 Virtual Thread 复用 Carrier，导致 errno 等被污染	完全隔离 ：通过 captureCallState 写入 Virtual Thread 专享 Segment
C2 JIT 编译器优化	黑盒（Inliner 无法跨越 JNI 边界）	黑盒	极致优化 ：C2 动态内联 Downcall Stub，isTrivial 模式消除 Safepoint Check
堆外内存 GC 压力	高（依赖 DirectByteBuffer 清洁器与 GC 标记）	高	零 GC 压力 ：Arena 手动/Scoped 显式释放，不占用 Eden/Old 区