WebAssembly 走进 JVM：从解释执行、JIT 到 Endive 的服务端演进

WebAssembly 已经不再只是浏览器中的编译目标。Andrea Peruffo 的讨论把视角转向服务端 JVM：Wasm 运行时正在从解释执行走向更高效的即时编译，并开始承担边缘计算、插件隔离和模块化扩展等生产任务。与此同时，向 Endive 的过渡也提醒 JVM 开发者，评估 Wasm 不能只看单次基准测试，还要看运行时架构、宿主边界和长期维护成本。

Wasm 为什么适合进入 JVM 服务

JVM 已经拥有成熟的类加载、垃圾回收、监控和部署体系，因此 Wasm 并不是要替换 Java 或 Kotlin。更现实的定位，是把它作为受约束的可移植模块格式嵌入现有服务。

这种组合在几类场景中尤其有价值：

• 插件架构：主服务保持稳定，把规则、转换器或用户扩展编译成 Wasm 模块。
• 边缘计算：同一个模块可以部署到不同节点，由宿主提供日志、网络或存储能力。
• 多语言扩展：Rust、C/C++ 等语言可以编译为统一的 Wasm 产物，JVM 只维护一套模块调用协议。
• 故障隔离：通过线性内存、显式导入和资源限额，缩小插件能够影响的范围。

但“运行在 Wasm 沙箱中”不等于天然安全。宿主开放的文件、网络、时钟和数据库接口，才真正决定模块拥有什么权限。一个允许任意 URL 请求的导入函数，足以破坏原本清晰的隔离边界。

从解释器到 JIT，性能问题发生了变化

解释器适合快速启动、调试和验证模块，但每条 Wasm 指令都需要经过分派。随着运行时采用更高效的 JIT 编译，热点代码能够转换为本机代码，稳态吞吐量通常更值得期待。代价则是编译时间、额外内存，以及更复杂的缓存和诊断机制。

因此，服务端评估不能只比较“执行一次函数需要多少微秒”。至少要拆开以下指标：

对于只执行几十条指令的插件，跨越宿主边界的成本可能高于计算本身。批量传输、复用线性内存缓冲区、减少细粒度回调，往往比继续优化模块内部循环更有效。

可以这样实践：定义一个最小插件契约

下面是一个可运行的通用 Wasm 示例，用来验证“宿主调用纯计算插件”的最小契约。它不依赖某个 JVM Wasm API，也不代表 Endive 的具体接口；接入 JVM 时，可以保留相同的导出函数，再用所选运行时的 Java 绑定完成实例化和调用。

先安装 WABT 与 Wasmtime，并创建 discount.wat：

(module
  (func (export "apply_discount")
    (param $price i32)
    (param $percent i32)
    (result i32)

    local.get $price
    i32.const 100
    local.get $percent
    i32.sub
    i32.mul
    i32.const 100
    i32.div_s))

在 macOS 上可以这样安装并执行；Linux 用户需要改用发行版包管理器或对应的官方安装方式：

brew install wabt wasmtime
wat2wasm discount.wat -o discount.wasm
wasmtime run --invoke apply_discount discount.wasm 2500 20

预期输出为 2000。这里约定金额使用最小货币单位，避免浮点误差；生产环境还应校验折扣范围和整数溢出。

在 JVM 服务中，可以把运行时差异封装到一个窄接口后面。下面是可直接编译的 Java 契约与业务层示例，其中适配器实现需要替换为实际选用的 Wasm 运行时 API：

public final class DiscountService {
    public interface WasmFunction {
        int call(int priceInCents, int percent);
    }

    private final WasmFunction function;

    public DiscountService(WasmFunction function) {
        this.function = function;
    }

    public int discountedPrice(int priceInCents, int percent) {
        if (priceInCents < 0) {
            throw new IllegalArgumentException("price must be non-negative");
        }
        if (percent < 0 || percent > 100) {
            throw new IllegalArgumentException("percent must be between 0 and 100");
        }
        return function.call(priceInCents, percent);
    }

    public static void main(String[] args) {
        // 本地测试替身；生产环境在这里注入 Endive 或其他运行时适配器。
        WasmFunction testAdapter = (price, percent) -> price * (100 - percent) / 100;
        System.out.println(new DiscountService(testAdapter).discountedPrice(2500, 20));
    }
}

保存为 DiscountService.java 后即可验证宿主侧契约：

javac DiscountService.java
java DiscountService

这层接口看似简单，却能把模块生命周期、运行时升级和业务代码分离。向 Endive 迁移时，团队可以替换适配器并运行契约测试，而不必让业务层直接依赖运行时的实例、内存或函数句柄类型。

迁移到 Endive 前应确认什么

讨论中的 Endive 过渡，值得被视为一次运行时边界调整，而不仅是依赖版本升级。由于来源摘要没有给出具体 API 和兼容性承诺，实际采用时应以项目文档和测试结果为准。

上线前建议确认：

• 模块使用的 Wasm 特性是否全部受支持，包括内存、表、引用类型及可能的扩展提案。
• 解释执行与 JIT 模式是否具有一致的整数、陷阱和导入函数语义。
• 模块能否被缓存和复用，实例是否线程安全，实例池应如何设置上限。
• 是否可以限制执行时间、线性内存、调用深度和宿主资源访问。
• 指标能否区分解析、编译、实例化、执行和宿主回调耗时。
• 旧运行时与 Endive 是否能短期并行，通过灰度流量比较结果和尾延迟。

Wasm 在 JVM 上最有价值的地方，不是把普通 Java 代码换一种格式运行，而是建立一个可移植、可限制、可替换的扩展边界。解释器降低了接入门槛，JIT 改善了稳态性能，Endive 的过渡则要求团队把兼容性和可观测性纳入设计。先从纯函数、小数据和低权限插件开始，通常比直接承载复杂网络服务更容易得到可信的生产结论。