使用JNI时能否保证每个进程恰好只有一个JavaVM？

原问题描述 #

• 基础开发场景：我有一个通过JNI供Java应用调用的C共享库，需要存储部分计算成本较高、有效期与JavaVM生命周期一致的数据，因此希望将其存储在C的static变量中，实现仅计算一次的效果。
• 已知的方案局限：如果同一进程中存在多个JavaVM调用该库，上述基于C层static变量的设计会失效，静态变量仅对第一个初始化它的JavaVM生效。
• 核心疑问：如果该库是通过Java类static代码块中的System.loadLibrary方法加载的，是否存在无需完全卸载该C共享库即可被多个JavaVM使用的情况？

对应解答 #

首先需要澄清几个JNI生态下的基础认知事实，避免基于错误前提做设计：

1. 主流JDK根本不支持单进程内创建多个JavaVM
   从JNI规范设计之初就明确约定，单个操作系统进程内最多只能存在一个有效的JavaVM实例。主流OpenJDK、Oracle JDK的实现中，进程内已经初始化过JavaVM的情况下，任何再次调用JNI_CreateJavaVM的尝试都会直接返回错误码，根本不可能创建出第二个独立的VM实例。
   开发者感知到的“多个JavaVM共享库”的场景，本质上是两类非预期情况：
   • 同一个JavaVM被多个独立的类加载器（ClassLoader）重复加载同一个原生库
   • 操作系统层面并行运行多个完全独立的Java进程，而非同一进程内的多个VM
2. System.loadLibrary加载逻辑的实际行为
   当通过类的静态块执行System.loadLibrary时，库的加载流程和类加载器深度绑定：
   • 同个类加载器在同个JavaVM生命周期内重复触发加载时，操作系统的动态链接器（Linux的ld.so、Windows的LoadLibrary）会直接返回已经映射到进程地址空间的库句柄，不会重复执行库的初始化逻辑，库中C层的static变量会被所有触发加载的调用方共享。这种情况下根本不存在“库被卸载后重新加载”的过程，所有对库的访问都会复用同一份内存映射。
   • 不同类加载器尝试加载同一个库时，Java 8及更早版本会直接抛出UnsatisfiedLinkError；从Java 9开始引入的原生库作用域隔离机制，才会允许不同类加载器加载的库拥有独立的原生状态，但这种隔离依然是JNI层面的逻辑隔离，操作系统层面不会重复映射同一个库文件——只是JNI层会给每个加载者关联独立的本地存储指针。
3. 适配高成本缓存数据的可靠实现方案
   如果要实现“缓存数据和JavaVM生命周期一致、仅计算一次”的目标，完全不需要依赖C层的裸static变量：
   • 可以在JNI_OnLoad回调（库被JVM加载时自动触发的入口方法）内，拿到传入的JavaVM指针，建立JavaVM*地址到对应缓存数据的哈希映射，后续每次原生方法被调用时，先从当前调用的JNI环境中提取对应的JavaVM指针，从映射中匹配对应的缓存即可。
   • 这种实现不会出现裸static变量被跨逻辑调用方污染的问题，也不需要关心库是否被重复加载、是否被显式卸载——哪怕库的C层全局static变量依然是同一份，通过显式的VM指针映射，就能把不同逻辑实例的状态做隔离。
   • 补充说明：所谓“同一进程内多个JavaVM复用库且不卸载”的场景，在主流JDK上根本不会发生，因为压根不存在单进程多VM的运行基础。如果是基于自定义类加载器做隔离的常规开发场景，上面提到的基于VM指针的映射方案已经可以覆盖绝大多数需求，不需要为了极端的、几乎不会出现的多VM场景过度设计。

内容的提问来源于stack exchange，提问作者Cort Ammon