当 JVM 的多线程并发模型遭遇 WebAssembly 的单线程事件循环，如何在保持零原生依赖的前提下实现高效的线程映射？Endive 作为 Bytecode Alliance 托管的纯 Java WebAssembly 运行时，通过协作式调度与状态机转换，给出了一个优雅的工程答案。
核心挑战：两种并发哲学的碰撞
JVM 的线程模型基于抢占式多任务调度，线程可以在任意指令边界被挂起，依赖操作系统提供的原生线程支持。而 WebAssembly 的 MVP（Minimum Viable Product）规范本质上是一个单线程执行模型，即便在 Threads 提案落地后，Wasm 模块本身仍然不直接创建线程，而是依赖宿主环境通过 Web Workers 或类似机制提供并发能力。
这种架构差异带来了三个核心挑战：
状态机语义不匹配。JVM 线程具有 NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED 等明确状态，而 Wasm 执行上下文只有运行与暂停两种基本状态。如何将 JVM 的复杂线程生命周期映射到 Wasm 的简化模型，同时保持语义等价，是首要难题。
调度策略的根本差异。JVM 采用抢占式调度，线程时间片到期即强制切换；Wasm 环境则天然适合协作式调度，执行单元需主动让出控制权。这种差异要求运行时必须在两种调度哲学之间建立转换层。
内存模型的兼容。JVM 的内存模型定义了 happens-before 关系、volatile 语义和监视器锁，而 Wasm 线程提案通过共享线性内存和原子操作（Atomic Operations）实现同步。如何在保持 JVM 内存语义的同时映射到 Wasm 的原子操作原语，是正确性保障的关键。
线程状态机映射方案
Endive 采用了一种分层的状态机映射策略，将 JVM 线程抽象为三个层级：
第一层：JVM 线程抽象。Endive 在 JVM 内部维护标准的 Thread 对象，这些线程对 Java 代码完全透明，可以使用 synchronized、wait/notify、ReentrantLock 等标准并发原语。这一层确保现有 Java 代码无需修改即可在 Wasm 运行时中执行。
第二层：执行上下文（Execution Context）。每个 JVM 线程在 Endive 内部对应一个执行上下文对象，该对象封装了 Wasm 实例的运行状态，包括操作数栈、局部变量、程序计数器和线性内存引用。执行上下文是状态映射的核心载体。
第三层：Wasm 实例。实际的 Wasm 模块实例运行在宿主提供的执行环境中，Endive 通过纯 Java 实现的解释器或 AOT 编译后的代码来执行 Wasm 指令。
状态转换的核心逻辑在于：当 JVM 线程进入 BLOCKED 或 WAITING 状态时，Endive 将对应的执行上下文标记为挂起状态，并保存当前执行栈的快照；当线程被唤醒时，执行上下文从挂起状态恢复，继续执行 Wasm 指令流。这种映射使得 JVM 线程的阻塞操作（如等待锁）可以转换为 Wasm 层面的内存等待（memory.atomic.wait），实现无锁化的线程同步。
协作式调度实现
Endive 的调度器采用协作式而非抢占式设计，这是由 Wasm 的执行模型决定的。协作式调度的核心在于 ** 显式让出点（Yield Points）** 的设计：
指令级让出。在解释器模式下，Endive 在特定 Wasm 指令边界检查调度标志。当检测到线程切换请求时，解释器保存当前执行上下文的状态，将控制权交还给 JVM 调度器。这种设计避免了在 Wasm 指令执行中途强制中断带来的状态不一致问题。
方法调用边界。对于 AOT 编译模式，Endive 在生成的 Java 字节码中插入协作式检查点。由于 Endive 的编译器将 Wasm 控制流（block、loop、br_if）映射为 Java 的 while、switch、break 结构，可以在这些控制流边界安全地插入让出逻辑。
I/O 与系统调用。当 Wasm 模块执行 WASI 系统调用（如文件读取、网络操作）时，Endive 利用 Java 的异步 I/O 能力（如 CompletableFuture 或虚拟线程）实现非阻塞执行。线程在等待 I/O 完成期间主动让出，其他就绪线程获得执行机会。
这种协作式调度的一个关键优势是零成本抽象：在没有线程竞争的情况下，Wasm 代码以原生速度执行，无需额外的同步开销。只有在真正需要线程协调时，才触发状态保存与恢复的逻辑。
线性内存访问序列化
Wasm 线程提案通过共享线性内存（Shared Linear Memory）实现多线程通信，但这引入了数据竞争风险。Endive 通过以下机制确保内存访问的序列化：
原子操作映射。Wasm 的 i32.atomic.rmw.add、memory.atomic.wait、memory.atomic.notify 等指令被映射到 Java 的 VarHandle 或 Unsafe 原子操作。Endive 的编译器在生成 Java 字节码时，识别这些原子指令并生成对应的 JVM 级原子操作，确保跨线程的内存可见性。
锁消除与无锁优化。对于高频访问的共享数据，Endive 利用 Wasm 的原子操作实现无锁数据结构。例如，Java 的 AtomicInteger 在 Wasm 层面对应 i32.atomic.rmw 指令序列，避免了传统监视器锁的开销。
内存屏障的精确放置。JVM 的内存模型要求特定的 happens-before 关系，Endive 在编译阶段分析 Wasm 代码的内存访问模式，在必要位置插入 fence 指令或利用 Java 的 volatile 语义，确保跨线程的内存一致性。
线程局部存储优化。对于不需要共享的数据，Endive 利用 Wasm 的多内存提案（Multi-Memory Support）为每个线程分配独立的线性内存区域，完全消除竞争条件，实现真正的无锁访问。
无锁并发原语设计
Endive 实现了一套映射到 Wasm 原子操作的无锁并发原语，为上层 Java 代码提供标准并发 API：
原子变量类。AtomicInteger、AtomicLong、AtomicReference 等类在 Wasm 层面对应 i32.atomic.rmw、i64.atomic.rmw 指令。Endive 的编译器识别这些类的使用模式，直接内联对应的 Wasm 原子指令，避免方法调用开销。
锁与条件变量。ReentrantLock 和 Condition 的实现基于 Wasm 的 memory.atomic.wait/notify 机制。当线程尝试获取已被占用的锁时，执行 memory.atomic.wait 进入等待状态；锁释放时，通过 memory.atomic.notify 唤醒等待线程。这种实现比传统的自旋锁更高效，因为等待线程不消耗 CPU 资源。
并发集合。ConcurrentHashMap、ConcurrentLinkedQueue 等无锁集合依赖原子操作和内存排序保证。Endive 确保这些集合的底层 CAS（Compare-And-Swap）操作映射到 Wasm 的 atomic.rmw.cmpxchg 指令，保持与 JVM 原生实现相同的语义和性能特征。
工程实践建议
基于 Endive 的线程模型映射实践，以下是针对 JVM-on-Wasm 运行时的工程建议：
避免过度同步。协作式调度意味着长时间不释放控制权的线程会阻塞其他线程。对于计算密集型任务，应在循环中显式插入让出点，或拆分为多个短任务提交给线程池。
优先使用原子操作。对于简单的计数器、标志位等场景，优先使用 AtomicInteger 等原子变量而非 synchronized 块。Endive 可以将原子操作内联为单条 Wasm 指令，而监视器锁需要额外的等待队列管理。
合理设置线程池大小。由于 Wasm 线程依赖宿主环境的并发能力，线程池大小应根据实际可用的并行资源设置，避免过度订阅导致的上下文切换开销。
监控线程状态转换。利用 JVM 的线程监控工具（如 JMX）观察线程状态分布，识别潜在的性能瓶颈。过多的 BLOCKED 或 WAITING 线程可能表明锁竞争过于激烈，需要重构并发策略。
总结
Endive 通过分层的状态机映射、协作式调度策略和 Wasm 原子操作的充分利用，成功将 JVM 的多线程并发模型桥接至 WebAssembly 的单线程事件循环。这种设计不仅保持了零原生依赖的纯粹性，还实现了接近原生性能的并发执行。
对于希望在 JVM 生态中利用 WebAssembly 的开发者而言，理解这一线程模型映射机制至关重要。它决定了并发代码的编写方式、性能特征以及调试策略。随着 WebAssembly 线程提案的成熟和 Endive 的持续演进，JVM 与 Wasm 之间的并发鸿沟正在被逐步填平。
参考资料
- Endive 官方文档与博客：https://endive.run/
- Endive GitHub 仓库：https://github.com/bytecodealliance/endive
- WebAssembly Threads 提案：https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md
- "Finding a JVM JIT Bug the Hard Way" — Endive 团队技术博客，2026 年 5 月
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。