引言：JNI 的核心价值与应用场景
Java Native Interface（JNI）作为 Java 平台的核心特性之一，自 JDK 1.1 起便成为连接 Java 虚拟机与原生代码（C/C++、汇编等）的桥梁。在 Java 以 “一次编写，到处运行” 的跨平台特性风靡业界的同时，JNI 为其弥补了三大关键短板：一是访问底层系统资源，如操作系统 API、硬件驱动等 Java 无法直接触及的层面；二是复用现有原生代码库，避免重复开发成熟的 C/C++ 组件；三是优化性能瓶颈，将计算密集型任务（如图像处理、加密解密）交由原生代码执行，突破 Java 虚拟机的性能限制。
如今，JNI 的应用已渗透到各类软件系统中：Android 开发中通过 JNI 调用 C/C++ 实现音视频编解码、游戏引擎；大数据领域利用 JNI 整合 Hadoop 生态中的 C 语言计算模块；金融系统借助 JNI 调用底层加密库保障数据安全。但 JNI 的强大背后也暗藏风险 —— 内存泄漏、线程安全问题、跨平台兼容性故障等，往往让开发者望而却步。本文将从基础原理出发，逐步深入 JNI 的开发全流程，结合实战案例与避坑指南，帮助开发者真正掌握这门 “Java 与原生世界的通信艺术”。
一、JNI 核心概念与架构原理
1.1 JNI 的定义与设计目标
JNI 是 Java 虚拟机规范定义的一套编程接口，其核心目标是实现 “双向交互”：Java 代码可以调用原生代码，原生代码也能反向访问 Java 虚拟机中的对象、方法和字段。与其他跨语言方案（如 JNA、SWIG）相比，JNI 的优势在于直接与虚拟机底层交互，性能损耗最小，但代价是需要手动管理跨语言调用的细节。
JNI 的设计遵循三大原则：
- 二进制兼容性：原生库编译后生成的二进制文件（.so/.dll/.dylib）可在不同 Java 虚拟机实现中运行，无需重新编译；
- 平台无关性：JNI 接口本身不依赖特定操作系统，原生代码的跨平台性需由开发者自行保障；
- 最小侵入性：JNI 不改变 Java 语言的语义，仅通过特定语法和 API 实现与原生代码的交互。
1.2 JNI 的架构层次
JNI 的交互过程涉及三个核心层次，从上层到下层依次为：
Java 应用层：包含声明 native 方法的 Java 类，作为调用原生代码的入口；
JNI 桥接层：由 JNI 头文件（.h）、原生实现文件（.c/.cpp）组成，负责解析 Java 虚拟机传递的参数、调用原生逻辑、返回结果给 Java 层；
原生代码层：既可以是自定义的 C/C++ 代码，也可以是第三方原生库（如 OpenCV、FFmpeg），实现核心业务逻辑。
其底层通信原理是：Java 虚拟机通过 JNI 接口加载原生库（.so/.dll），当 Java 代码调用 native 方法时，虚拟机通过方法名映射找到对应的原生函数，将 Java 对象、参数转换为原生代码可识别的格式（如 jobject、jint），执行原生函数后，再将返回值转换为 Java 类型并返回给 Java 层。
1.3 JNI 关键数据类型
JNI 定义了一套与 Java 类型对应的原生数据类型，分为基本类型和引用类型两类，确保跨语言数据传递的一致性。
1.3.1 基本数据类型
JNI 的基本类型直接映射 Java 的基本类型，无额外开销，具体对应关系如下：
Java 类型 | JNI 类型 | 原生 C/C++ 类型 | 占用字节数 |
boolean | jboolean | unsigned char | 1 |
byte | jbyte | signed char | 1 |
char | jchar | unsigned short | 2 |
short | jshort | short | 2 |
int | jint | int | 4 |
long | jlong | long long | 8 |
float | jfloat | float | 4 |
double | jdouble | double | 8 |
其中，JNI 还定义了jsize类型（等价于jint），用于表示数组长度等计数场景。
1.3.2 引用类型
JNI 的引用类型对应 Java 的引用类型（对象、数组等），本质是指向 Java 虚拟机内部对象的指针，不能直接在原生代码中操作，需通过 JNI 提供的 API 进行访问。核心引用类型包括：
JNI 引用类型 | 对应 Java 类型 | 用途 |
jobject | Object | 所有 Java 对象的基类 |
jclass | Class | Java 类对象 |
jstring | String | 字符串对象 |
jarray | 所有数组的基类 | 数组通用类型 |
jobjectArray | Object[] | 对象数组 |
jbooleanArray | boolean[] | 布尔数组 |
jbyteArray | byte[] | 字节数组 |
... | ... | 其他基本类型数组 |
jthrowable | Throwable | 异常对象 |
需要注意的是，引用类型在原生代码中需严格遵循 JNI 的内存管理规则，否则会导致内存泄漏或虚拟机崩溃。
二、JNI 开发全流程实战（以 C 语言为例）
2.1 开发环境准备
2.1.1 基础环境
- JDK：推荐 JDK 8 及以上（需配置 JAVA_HOME 环境变量）；
- 原生编译器：Windows 平台使用 MinGW 或 MSVC，Linux 平台使用 GCC，MacOS 平台使用 Clang；
- 开发工具：Java 代码可使用 IDEA/Eclipse，原生代码可使用 VS Code、CLion 等。
2.1.2 环境验证
在命令行中执行以下命令，验证环境是否配置成功：
2.2 第一步：编写声明 native 方法的 Java 类
native 方法是 Java 调用原生代码的入口，需使用native关键字声明，且不能包含方法体。同时，需通过System.loadLibrary()或System.load()方法加载原生库。
示例：JavaNativeDemo.java
关键说明：
- System.loadLibrary()：加载系统默认库路径下的原生库，库名无需带前缀（如lib）和后缀（如.so）；
- System.load()：加载指定路径的原生库，需传入完整路径（如D:/libs/JavaNativeDemo.dll）；
- native 方法的访问修饰符可以是public、protected或默认，但通常声明为public以便外部调用。
2.3 第二步：生成 JNI 头文件（.h）
JNI 头文件由javac命令自动生成，包含原生函数的声明，其文件名格式为包名+类名.h（包名中的.替换为_）。生成头文件的核心是让javac识别 native 方法，并按照 JNI 规范生成对应的原生函数签名。
生成步骤：
进入 Java 类的源文件所在目录（假设 Java 文件在src/main/java目录下，包名为com.example.jni）；
执行以下命令生成 class 文件和头文件：
# -d：指定class文件输出目录（需与包结构一致）
# -h：指定头文件输出目录（通常为jni目录）
javac -d target/classes -h jni src/main/java/com/example/jni/JavaNativeDemo.java
生成的头文件：com_example_jni_JavaNativeDemo.h
头文件关键解析：
预处理指令：#ifndef _Included_xxx避免头文件重复包含；
extern "C"：确保 C++ 编译器按 C 语言规则编译函数（避免函数名被篡改）；
函数声明格式：JNIEXPORT 返回类型 JNICALL 函数名(JNIEnv *, jobject, 其他参数)；
- JNIEXPORT：标记函数为 JNI 导出函数，允许 Java 虚拟机调用；
- JNICALL：指定函数调用约定（如栈帧布局、参数传递顺序），确保跨平台兼容性；
- JNIEnv *：JNI 环境指针，包含所有 JNI 核心 API（如创建对象、访问字段、调用方法）；
- jobject：对应 Java 中的this对象（非静态 native 方法），若为静态 native 方法则为jclass（对应 Java 类对象）；
- 后续参数：与 Java native 方法的参数一一对应，类型为 JNI 数据类型。
Signature：方法签名，用于 Java 虚拟机区分重载方法，格式规则如下：
- 基本类型：用单个字符表示（如Z=boolean、I=int、J=long）；
- 引用类型：用L全类名;表示（如Ljava/lang/String;）；
- 数组类型：用[类型表示（如[I=int[]、[[Ljava/lang/Object;=Object[][]）；
- 方法签名：(参数类型列表)返回类型（如(II)I表示接收两个 int 参数，返回 int）。
2.4 第三步：编写原生实现代码（.c/.cpp）
原生实现代码需包含生成的 JNI 头文件，按照头文件中的函数声明实现具体逻辑，核心是通过JNIEnv指针调用 JNI API，完成与 Java 层的数据交互。
示例：JavaNativeDemo.c
核心 API 解析：
字符串处理 API：
- GetStringUTFChars(env, jstr, isCopy)：将 jstring 转换为 UTF-8 编码的 C 字符串，isCopy表示是否返回副本（通常传 NULL）；
- ReleaseStringUTFChars(env, jstr, cstr)：释放GetStringUTFChars分配的内存，必须调用，否则内存泄漏；
- NewStringUTF(env, cstr)：将 UTF-8 编码的 C 字符串转换为 jstring（Java 字符串）。
数组处理 API：
- GetArrayLength(env, jarr)：获取 Java 数组的长度；
- GetIntArrayElements(env, jarr, isCopy)：获取 int 数组的原生指针（jint*），其他类型数组对应GetXxxArrayElements；
- ReleaseIntArrayElements(env, jarr, carr, mode)：释放数组资源，mode参数：
- 0：将原生数组的修改复制回 Java 数组，并释放原生数组；
- JNI_ABORT：不复制修改，直接释放原生数组；
- JNI_COMMIT：复制修改，但不释放原生数组（需后续再次调用释放）。
资源释放原则：
- 凡是通过 JNI API 获取的原生资源（如 C 字符串、数组指针、对象引用），必须在使用完毕后调用对应的释放 API；
- 释放顺序与获取顺序相反（如先获取字符串，再获取数组，则先释放数组，再释放字符串）；
- 若中间步骤出错（如数组获取失败），需先释放已获取的资源，再返回错误。
2.5 第四步：编译原生代码为动态链接库
将原生代码（.c/.cpp）编译为目标平台的动态链接库（Windows：.dll，Linux：.so，MacOS：.dylib），供 Java 虚拟机加载。编译时需指定 JNI 头文件路径、目标平台架构等参数。
2.5.1 Linux 平台（GCC）
# 编译命令：生成libJavaNativeDemo.so
gcc -fPIC -shared -o libJavaNativeDemo.so \
-I$JAVA_HOME/include \
-I$JAVA_HOME/include/linux \
JavaNativeDemo.c
参数说明：
- -fPIC：生成位置无关代码（Position Independent Code），确保库可被多个进程共享；
- -shared：生成动态链接库（而非可执行文件）；
- -o：指定输出库文件名（必须以 lib 开头，后缀为.so）；
- -I：指定头文件搜索路径（需包含 JNI 头文件所在目录，$JAVA_HOME 为 JDK 安装目录）。
2.5.2 Windows 平台（MinGW）
# 编译命令：生成JavaNativeDemo.dll
gcc -shared -o JavaNativeDemo.dll \
-I%JAVA_HOME%\include \
-I%JAVA_HOME%\include\win32 \
JavaNativeDemo.c -Wl,--add-stdcall-alias
参数说明：
- -Wl,--add-stdcall-alias：为函数添加 stdcall 调用约定的别名，确保 Java 虚拟机能找到函数；
- 库文件名无需带 lib 前缀，后缀为.dll。
2.5.3 MacOS 平台（Clang）
# 编译命令：生成libJavaNativeDemo.dylib
clang -fPIC -shared -o libJavaNativeDemo.dylib \
-I$JAVA_HOME/include \
-I$JAVA_HOME/include/darwin \
JavaNativeDemo.c
2.6 第五步：运行 Java 程序测试
编译生成动态链接库后，需将库文件所在路径添加到 Java 虚拟机的库搜索路径中，然后运行 Java 程序。
运行步骤：
- 将动态链接库复制到 Java 程序的运行目录，或指定库路径；
- 执行 Java 程序：
# Linux/MacOS：通过-Djava.library.path指定库路径（当前目录用.表示） java -Djava.library.path=. com.example.jni.JavaNativeDemo # Windows： java -Djava.library.path=. com.example.jni.JavaNativeDemo 预期输出： 原生代码返回的消息：Hello from C Native Code! 10 + 20 = 30 处理后的结果：Input String: Hello JNI Array Elements: 1 2 3 4 5 Array Sum: 15 若运行成功，说明 JNI 调用正常；若出现UnsatisfiedLinkError（找不到库或方法），需检查以下问题：
- 库文件名是否与System.loadLibrary()中的名称一致；
- 库路径是否正确（通过-Djava.library.path指定）；
- 原生函数名是否与头文件中的声明完全一致（包括包名、类名、方法名）；
- 编译时的 JDK 版本与运行时的 JDK 版本是否一致。
三、JNI 进阶特性：对象操作、异常处理与线程管理
3.1 访问 Java 对象的字段与方法
原生代码不仅能接收 Java 传递的参数，还能主动访问 Java 对象的字段（成员变量）和调用 Java 对象的方法，这是 JNI 双向交互的核心能力。
3.1.1 访问 Java 字段
访问 Java 字段的步骤：
- 通过FindClass()获取 Java 类对象（jclass）；
- 通过GetFieldID()获取字段 ID（jfieldID），需指定字段名和字段签名；
- 通过GetXxxField()/SetXxxField()获取 / 修改字段值（Xxx 对应字段类型）。
示例：访问 Java 对象的字段
假设 Java 类中添加字段：
public class JavaNativeDemo { // 实例字段（非静态） private String name = "默认名称"; // 静态字段 private static int count = 0; // native方法：修改实例字段和静态字段 public native void modifyFields(); // getter方法：用于验证字段是否被修改 public String getName() { return name; } public static int getCount() { return count; } }原生实现代码：
3.1.2 调用 Java 方法
调用 Java 方法的步骤：
- 获取 Java 类对象（jclass）；
- 通过GetMethodID()/GetStaticMethodID()获取方法 ID（jmethodID），需指定方法名和方法签名；
- 通过CallXxxMethod()/CallStaticXxxMethod()调用方法（Xxx 对应返回值类型）。
示例：调用 Java 对象的方法
假设 Java 类中添加方法：
public class JavaNativeDemo { // 实例方法：接收字符串参数，返回拼接结果 public String appendString(String suffix) { return "Java方法返回：" + suffix; } // 静态方法：接收两个int参数，返回乘积 public static int multiply(int a, int b) { return a * b; } // native方法：调用Java实例方法和静态方法 public native void callJavaMethods(); }原生实现代码：
#include "com_example_jni_JavaNativeDemo.h" JNIEXPORT void JNICALL Java_com_example_jni_JavaNativeDemo_callJavaMethods (JNIEnv *env, jobject thiz) { jclass clazz = (*env)->GetObjectClass(env, thiz); if (clazz == NULL) { return; } // 1. 调用实例方法appendString(String)：String appendString(String) // 方法签名：(Ljava/lang/String;)Ljava/lang/String; jmethodID appendMethodId = (*env)->GetMethodID(env, clazz, "appendString", "(Ljava/lang/String;)Ljava/lang/String;"); if (appendMethodId == NULL) { (*env)->DeleteLocalRef(env, clazz); return; } jstring suffix = (*env)->NewStringUTF(env, "来自原生代码的参数"); // 调用实例方法：CallObjectMethod（返回值为对象类型） jstring appendResult = (*env)->CallObjectMethod(env, thiz, appendMethodId, suffix);关键注意事项：
- 字段 / 方法签名必须准确，否则GetFieldID()/GetMethodID()会返回 NULL；
- 访问私有字段 / 方法时，无需额外权限（JNI 可绕过 Java 的访问控制）；
- 若 Java 方法抛出异常，CallXxxMethod()会返回默认值（如 0、NULL），需通过ExceptionCheck()检查异常。
3.2 JNI 异常处理
Java 层的异常会传递到原生层，原生层也可能产生异常（如数组越界、空指针），需通过 JNI 的异常处理 API 进行捕获和处理，避免程序崩溃。
JNI 异常处理核心 API：
- ExceptionCheck(env)：检查是否有未处理的异常，返回 JNI_TRUE/JNI_FALSE；
- ExceptionOccurred(env)：获取当前异常对象（jthrowable），若无不返回 NULL；
- ExceptionDescribe(env)：打印异常堆栈信息（类似 Java 的 printStackTrace ()）；
- ExceptionClear(env)：清除当前异常，使程序可继续执行；
- Throw(env, exc)：抛出已存在的异常对象；
- ThrowNew(env, clazzName, msg)：创建并抛出新的异常（需指定异常类名，如 "java/lang/NullPointerException"）。
示例：原生代码中的异常处理
#include "com_example_jni_JavaNativeDemo.h" JNIEXPORT jint JNICALL Java_com_example_jni_JavaNativeDemo_divide (JNIEnv *env, jobject thiz, jint a, jint b) { // 检查除数为0的情况，主动抛出异常 if (b == 0) { // 创建并抛出ArithmeticException异常 (*env)->ThrowNew(env, (*env)->FindClass(env, "java/lang/ArithmeticException"), "除数不能为0"); return 0; // 返回默认值 } jint result = a / b; // 模拟Java方法调用可能抛出的异常
jclass clazz = (*env)->GetObjectClass(env, thiz); jmethodID testMethodId = (*env)->GetMethodID(env, clazz, "testException", "()V");异常处理原则：
- 原生代码中检测到非法条件时，应主动抛出 Java 异常（而非直接崩溃），使 Java 层能捕获处理；
- 调用 JNI API 或 Java 方法后，需检查是否产生异常，及时处理（清除或抛出）；
- 异常未清除前，除异常处理相关 API 外，不应调用其他 JNI API（否则行为未定义）。
3.3 JNI 线程管理
Java 虚拟机中的线程（Java 线程）与原生代码中的线程（原生线程）可通过 JNI 进行交互：Java 线程可调用原生代码，原生线程也可附着到 Java 虚拟机，调用 Java 方法。
3.3.1 原生线程附着到 Java 虚拟机
原生线程（如 C 语言创建的 pthread 线程）默认未附着到 Java 虚拟机，无法调用 JNI API，需通过AttachCurrentThread()将其附着到虚拟机，使用完毕后通过DetachCurrentThread()分离。
示例：原生线程附着到 Java 虚拟机
Java 类中添加回调方法：
public class JavaNativeDemo { // 静态回调方法：供原生线程调用 public static void onNativeThreadCallback(String message) { System.out.println("Java收到原生线程的消息：" + message); System.out.println("当前线程：" + Thread.currentThread().getName()); } // native方法：创建原生线程 public native void createNativeThread(); }线程管理关键要点：
- JavaVM指针：全局唯一，可在多个线程间共享，用于获取当前线程的JNIEnv指针；
- JNIEnv指针：线程私有，每个线程的JNIEnv指针不同，不能跨线程使用；
- 全局引用：需手动释放（DeleteGlobalRef），否则内存泄漏；局部引用：在方法返回时自动释放，但建议手动释放以节省内存；
- 原生线程附着后必须分离（DetachCurrentThread），否则会导致 Java 虚拟机无法正常退出。
四、JNI 性能优化与避坑指南
4.1 性能优化技巧
JNI 调用本身存在一定的性能开销（如参数转换、虚拟机上下文切换），尤其是高频调用场景，需通过以下技巧优化性能：
4.1.1 减少 JNI 调用次数
JNI 调用的开销远大于 Java 方法调用，应尽量将多个小操作合并为一个原生函数调用，减少跨语言交互次数。例如，若需多次读取 Java 数组元素，不应每次读取都调用GetIntArrayElements，而应一次性获取数组指针，批量处理后再释放。
4.1.2 缓存全局引用
频繁调用FindClass、GetMethodID、GetFieldID等 API 会产生较大开销，因为这些 API 需要在 Java 虚拟机的元数据中查找信息。建议在JNI_OnLoad中初始化这些 ID，并保存为全局变量（如全局类引用、全局方法 ID），避免每次调用都重复查找。
4.1.3 优化数据拷贝
Java 数组与原生数组之间的转换会涉及数据拷贝（GetXxxArrayElements默认会复制数组数据），可通过以下方式减少拷贝：
- 使用GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical：获取数组的直接指针（避免拷贝），但调用期间会暂停 Java 虚拟机的垃圾回收（GC），需尽快释放，且不能调用其他 JNI API；
- 对于大量数据传输，使用java.nio缓冲区（如DirectByteBuffer），直接在原生代码中操作缓冲区的内存，无需数据拷贝。
4.1.4 避免在原生代码中长时间阻塞
原生代码中的长时间阻塞（如睡眠、IO 等待）会导致 Java 线程阻塞，若持有 JNI 锁或暂停 GC，会影响虚拟机的正常运行。建议：
- 长时间阻塞的操作放在独立的原生线程中执行；
- 避免在GetPrimitiveArrayCritical调用期间进行阻塞操作。
4.2 常见坑与解决方案
4.2.1 内存泄漏
JNI 中最常见的问题是内存泄漏，主要源于未释放的资源：
- 局部引用未释放：虽然局部引用会在方法返回时自动释放，但如果原生函数执行时间长、创建大量局部引用（如循环创建 jstring），会导致虚拟机内存溢出，需手动调用DeleteLocalRef释放；
- 全局引用未释放：全局引用不会自动释放，必须在使用完毕后调用DeleteGlobalRef，否则会导致对应的 Java 对象无法被 GC 回收；
- 字符串 / 数组资源未释放：GetStringUTFChars、GetIntArrayElements等 API 分配的原生资源，必须调用对应的ReleaseXxx方法释放。
解决方案：
- 遵循 “谁获取，谁释放” 的原则，确保每个获取资源的 API 都有对应的释放操作；
- 使用工具检测内存泄漏：如 VisualVM（监控 Java 堆内存）、Valgrind（检测原生代码的内存泄漏）。
4.2.2 UnsatisfiedLinkError
该异常表示 Java 虚拟机找不到指定的原生库或原生函数，常见原因：
- 库路径错误：未通过-Djava.library.path指定库所在路径；
- 库文件名错误：如 Linux 平台库名未以lib开头，Windows 平台后缀不是.dll；
- 函数名不一致：原生函数名与头文件中的声明不一致（如包名、类名拼写错误）；
- 编译架构不匹配：如 Java 虚拟机是 64 位，而原生库是 32 位；
- JNI 版本不兼容：编译时使用的 JDK 版本与运行时的 JDK 版本差异过大。
解决方案：
- 仔细检查库路径、文件名、函数名是否正确；
- 使用nm命令（Linux/MacOS）或dumpbin命令（Windows）查看原生库中的函数名，确认是否与预期一致；
- 确保编译架构与 Java 虚拟机一致（64 位对 64 位，32 位对 32 位）。
4.2.3 空指针异常
原生代码中的空指针异常（如访问NULL的 jobject、jstring）会导致 Java 虚拟机崩溃（而非 Java 的NullPointerException），难以调试：
- 原因：Java 层传递null给 native 方法（如 jstring 为 NULL），原生代码未做检查直接使用；
- 解决方案：在原生代码中对接收的参数进行空指针检查，如：
if (input == NULL) {
(*env)->ThrowNew(env, (*env)->FindClass(env, "java/lang/NullPointerException"), "input参数不能为null");
return NULL;
}
4.2.4 线程安全问题
原生代码通常不具备线程安全，若多个 Java 线程同时调用同一个原生函数，可能导致数据竞争：
- 解决方案：
- 在原生代码中使用互斥锁（如 pthread_mutex_t）保护共享资源；
- 避免在原生代码中使用全局变量存储状态，或确保全局变量的线程安全访问。
4.2.5 跨平台兼容性问题
原生代码的跨平台兼容性差，同样的代码在 Windows 上编译通过，在 Linux 上可能报错：
- 原因：
- 操作系统 API 差异（如文件操作、线程创建的 API 不同）；
- 数据类型大小差异（如某些平台long是 4 字节，某些是 8 字节）；
- 编译选项差异（如 Windows 需要__stdcall调用约定）。
解决方案：
- 尽量使用标准 C/C++ 库，避免直接调用操作系统 API；
- 对于平台相关的代码，使用条件编译（如#ifdef _WIN32、#ifdef __linux__）；
- 统一编译选项，确保不同平台生成的库符合 JNI 规范。
五、JNI 与其他跨语言方案对比
除了 JNI，Java 还有其他跨语言调用方案，如 JNA、SWIG、JNR 等，各有优劣，需根据场景选择：
方案 | 核心优势 | 核心劣势 | 适用场景 |
JNI | 性能最优，直接与虚拟机交互，功能最全面 | 开发复杂，需手动编写原生代码和头文件，易出错 | 性能要求高、需深度访问底层资源的场景（如音视频编解码、驱动开发） |
JNA | 开发简单，无需编写原生代码，直接映射 Java 接口到原生库 | 性能略低于 JNI，不支持某些 JNI 高级特性（如原生线程附着） | 快速整合第三方原生库，无需优化性能的场景 |
SWIG | 自动生成 JNI 包装代码，支持多种语言（Java、Python 等） | 配置复杂，生成的代码可读性差，难以调试 | 需跨多种语言复用原生库的场景 |
JNR | 基于 JNI 的封装，开发简单，性能接近 JNI | 生态不如 JNA 成熟，支持的原生库特性有限 | 对性能有要求且希望简化开发的场景 |
选择建议：
- 若追求极致性能和全面功能，选择 JNI；
- 若开发效率优先，需快速整合第三方库，选择 JNA；
- 若需跨多种语言复用原生库，选择 SWIG。
六、总结与展望
JNI 作为 Java 与原生世界的桥梁，为 Java 提供了访问底层资源、复用原生代码、优化性能的强大能力，是 Android、大数据、金融等领域不可或缺的技术。但 JNI 的开发门槛较高，需要开发者同时掌握 Java 和 C/C++ 语言，且需严格遵循内存管理、线程安全等规则，否则容易引入难以调试的问题。
本文从基础概念、开发流程、进阶特性到性能优化，全面覆盖了 JNI 的核心知识，并通过实战案例帮助开发者快速上手。掌握 JNI 的关键在于理解其架构原理和 API 设计思想，同时注重细节（如资源释放、异常处理），避免常见坑。
随着 Java 技术的发展，JNI 也在不断演进：JDK 9 引入的Foreign Linker API（孵化特性）旨在提供更安全、更易用的跨语言调用方案，减少 JNI 的复杂性；GraalVM 等新一代虚拟机也对 JNI 提供了更好的支持和性能优化。但在可预见的未来，JNI 仍将是 Java 生态中不可或缺的一部分，尤其是在需要深度整合底层系统的场景中。
希望本文能帮助开发者真正掌握 JNI 技术，在实际项目中灵活运用，充分发挥 Java 与原生代码的优势，构建高性能、高可靠性的软件系统。
