WebAssembly与JVM有何区别？

F5生态系统 | 2025年6月11日

敏锐的开发者初次接触WebAssembly（简称Wasm）时，通常会问：WebAssembly与Java虚拟机（JVM）有何不同？这是一个很好的问题，因为这两种技术都基于同一项基本承诺：通过可移植字节码实现“一次编写，随处运行”。虽然二者有着共同的基础，但实现方式和目标却大相径庭。了解这些差异，有助于理解为什么二者仍是各自拥有独立生态系统的重要项目。

概念差异

从根本上说，JVM和WebAssembly的设计目标都是让编译后的代码几乎可以在任何地方运行。对JVM而言，这意味着代码可以在采用不同操作系统或CPU架构的计算机上运行，这在当时前所未有；对WebAssembly而言，这意味着代码可以始终在任何地方、任何计算机上的任何Web浏览器中运行。

JVM于20世纪90年代中期随Java一同推出，后来逐步发展为一个成熟的平台，提供丰富的运行时支持，包括垃圾回收、庞大的标准库以及用于托管执行的工具。不过，也有人认为，这些功能让JVM显得较为臃肿，内存占用较大，启动速度也较慢。JVM虽然功能非常强大，但因此不太适合轻量级应用。

相比之下，WebAssembly在设计之初就面向Web，专门用于在浏览器中运行代码。因此，其架构优先考虑轻量级运行时和极快的启动速度，但不具备丰富的运行时支持。如果只能在浏览器中运行，Wasm的可移植性会低于Java字节码。不过，如今独立的Wasm运行时已可在Web环境之外运行，为服务器端应用、嵌入式系统和边缘计算带来了新的可能。此外，WebAssembly还将获得一些有限的额外运行时支持，例如垃圾回收，但它不太可能具备JVM所提供的全方位运行时支持。

互操作性

JVM仅适用于其语言家族，包括Java、Kotlin、Scala及其他少数几种语言，这些语言都是专为在JVM上运行而设计的。虽然Java生态系统拥有丰富的库和框架，但互操作仅限于这些JVM语言之间。基于JVM的应用程序可以调用原生代码，但需要投入大量精力并谨慎处理。

WebAssembly的设计并非只支持一种编程语言，也不偏向某种特定的语言类型，无论是函数式语言、采用垃圾回收机制的语言，还是解释型语言。任何语言，如Rust、JavaScript、Python和C++，都可以编译后在Wasm运行时上运行。虽然这并不意味着这些语言编写的代码目前就能相互通信，但借助正在形成的组件模型标准，开发者可以将使用不同语言编写的多个Wasm模块无缝连接起来。WebAssembly很快就能实现便捷的链接和互操作。

可嵌入性

您上一次听说有人将JVM嵌入应用程序以运行插件或自定义逻辑是什么时候？即使有过，恐怕也不是最近，对吧？JVM虽然功能强大，但众所周知，将其嵌入其他应用程序非常困难。过去也有过一些备受关注的嵌入案例（例如浏览器中的Java小程序），但由于使用不便或难以维护，这些方案大多已被弃用。

相比之下，WebAssembly在设计上就支持嵌入。将Wasm运行时嵌入应用程序，通常就像引入一个新库一样简单。完成后，应用程序便可运行Wasm代码，用于扩展游戏引擎、修改算法、响应事件，或实现任何可以设想的功能。Wasm在嵌入方面具有灵活性，而JVM既不具备这种能力（事实上，它可能也无意提供）。

安全性

可以说，安全性正是WebAssembly尤为出色之处。JVM有自己的安全模型，但其设计基于一个假设：执行的代码是可信的。WebAssembly从根本上否定了这一前提。Wasm诞生于浏览器环境，在该环境中，访问网站必然会下载并运行不受信任的代码，因此Wasm采用严格的默认拒绝沙箱模型。除非获得明确授权，否则不会允许代码访问系统资源、内存或其他功能。这种方法从根本上缩小了攻击面，使Wasm非常适合需要关注不受信任代码执行风险的环境。

JVM的安全模型可以正常发挥作用，但其设计初衷并不是提供Wasm所具备的安全级别。