它是如何跨越 JVM 与系统 C 库进行交互的

跨越边界：JVM与C库的受控对话

在Ja va的世界里，与系统底层C库的交互并非一场“越狱”或“逃离”，而是一场精心安排的正式会晤。Ja va通过JNI（Ja va Native Interface）建立起的，是一个明确、受控的双向通道。整个过程并非绕过JVM，恰恰相反，是由JVM主动提供接口、全程管理生命周期并严格约束行为。理解这场对话的核心，关键在于把握三个环环相扣的环节：契约约定、运行时桥接、资源隔离。

Ja va通过JNI建立JVM与C库的受控双向通道，核心是契约约定（签名对齐与符号匹配）、运行时桥接（JNIEnv线程独有翻译官）和资源隔离（内存独立、引用需显式管理）。

契约约定：Ja va 与 C 的签名对齐

一切合作始于一份清晰的“合同”。Ja va端用native关键字声明方法，只提需求，不写实现。C端则必须严格按照固定的命名规则（例如JNIEnv *env, jobject thisObj）来实现函数，并包含jni.h头文件。编译生成动态库（.so或.dll）后，Ja va通过System.loadLibrary(“xxx”)发出加载指令。这时，JVM会在运行时根据方法签名，自动查找并绑定对应的C函数。这个过程依赖的是编译时确定的符号表匹配，而非运行时的反射或动态解析，确保了效率和确定性。

运行时桥接：JNIEnv 是唯一合法“翻译官”

当Ja va代码真正调用native方法时，JVM会派出一位关键角色——JNIEnv*指针。这位“翻译官”身份特殊，它并非全局通用，而是当前线程独有的结构体指针。其内部封装了丰富的函数表（例如NewStringUTF、GetIntField、ThrowNew）。

这意味着，所有对Ja va对象的访问、数据类型的转换、异常的抛出乃至数组的操作，都必须通过这个指针调用对应的JNI函数来完成。任何试图直接操作Ja va对象内存地址、缓存jstring原生指针、或者跨线程复用JNIEnv*的行为，都等同于破坏沟通规则，最终必然导致程序崩溃或产生未定义行为。

资源隔离：内存与生命周期各自负责

这是最容易产生混乱的领域，必须划清界限。Ja va堆内存由GC（垃圾回收器）管理，而C侧通过malloc等分配的内存则完全独立，JVM对此既不感知，也不负责回收。

因此，当C函数需要返回字符串、数组等数据给Ja va时，必须使用JNI提供的函数对（如GetStringUTFChars与ReleaseStringUTFChars）进行显式的拷贝或引用管理。同样，Ja va对象传入C端后，其局部引用（LocalRef）默认仅在本次native方法调用期间有效。若需长期持有，必须主动调用NewGlobalRef将其提升为全局引用，并在未来某个时刻显式调用DeleteGlobalRef来释放，否则会造成内存泄漏。

这里有个特例：DirectByteBuffer。它的底层native内存由JVM统一管理，GC可以触发其释放，因此特别适合进行大块数据的交换，算是双方资源管理的一个默契交集。

启动与初始化：JNI_OnLoad 是可信入口

对话的起点在哪里？就在JNI_OnLoad函数中。当System.loadLibrary执行时，JVM会主动在C库中查找并调用这个函数。它的作用至关重要：

• 向JVM声明所需的JNI版本（例如JNI_VERSION_1_8），以确保功能兼容。
• 注册本地方法表，提前建立映射关系，从而避免运行时符号查找的开销。
• 执行C侧一次性的初始化工作，比如打开设备句柄、初始化线程池等。

如果库中没有提供JNI_OnLoad，JVM将默认使用最老的版本，许多新特性将无法使用。与之对应，JNI_OnUnload函数则用于在JVM卸载该库时（通常发生在应用关闭阶段）执行清理工作。这些机制不复杂，却常常是稳定性的关键所在。