当前位置：首页 > news >正文

Java调用DLL实战指南：JNI原理、环境配置与避坑详解

news 2026/8/17 8:14:19

1. 项目概述：为什么Java需要调用DLL？

在Java开发者的日常工作中，我们常常会遇到一个看似矛盾的需求：Java明明以“一次编写，到处运行”的跨平台特性著称，为什么还要去调用特定于Windows平台的DLL（动态链接库）文件？这个问题背后，其实是技术栈融合与历史遗留系统集成的现实需求。我见过太多项目，核心算法用C/C++写成，封装在DLL里，性能高、逻辑成熟，但上层业务系统却用Java重构了。这时候，硬着头皮用Java重写一遍算法不仅耗时，还可能引入新Bug，最稳妥高效的办法，就是让Java直接“对话”DLL。

这个过程的核心技术就是JNI（Java Native Interface）。简单来说，JNI是Java平台提供的一座“桥梁”，它定义了Java代码如何调用其他语言（主要是C/C++）编写的本地（Native）方法，以及本地代码如何回调Java。调用DLL，本质上就是通过JNI，让Java虚拟机（JVM）加载并执行DLL中符合JNI规范的函数。

对于刚接触这块的开发者，常见的困惑和痛点非常集中：环境怎么配？头文件是什么鬼？为什么总是报UnsatisfiedLinkError？参数和数据结构在Java和C之间怎么传递？内存谁来管理？这篇教程的目的，就是以一个过来人的身份，把这些坑一个个填平，手把手带你完成从零到一的完整流程。无论你是需要集成一个第三方商业库的DLL，还是将自己团队的C++核心模块暴露给Java服务，这篇“保姆级”指南都能让你避开我当年踩过的那些雷。

2. 核心原理与前置知识扫盲

在动手写代码之前，我们必须把几个核心概念和它们之间的关系理清楚。这就像盖房子前要看懂图纸，能避免很多“地基没打牢，墙面一直歪”的窘境。

2.1 JNI、Native方法与DLL的关系

很多人容易把这几个概念混淆。我们来打个比方：

Java程序就像一位只会说Java语的经理。
DLL文件就像一位只会说C/C++语的资深专家，肚子里有我们需要的“绝活”（函数）。
JNI就是这位经理和专家之间的一套标准“翻译协议”和“呼叫流程”。
Native方法则是经理根据“翻译协议”，在Java这边定义的一个“对接接口”。经理只要调用这个接口，JNI翻译官就会按照流程去找到专家（DLL），让他执行绝活，再把结果翻译回来。

所以，流程是这样的：

你在Java类中声明一个用native关键字修饰的方法，这只是个“接口声明”。
使用javac编译这个Java类，然后使用javah（旧版）或javac -h（新版）命令，根据这个声明生成一个C/C++的头文件（.h文件）。这个头文件里定义了符合JNI规范的函数原型，它就是“翻译协议”的C语言版本。
你根据这个头文件，用C/C++编写具体的函数实现，并编译生成一个DLL文件。这个DLL里的函数，就是那位“专家”的真身。
在Java程序里，使用System.loadLibrary()或System.load()加载这个DLL文件。这时，JVM就会根据DLL的名称和Java中native方法的声明，把两者关联起来。
当你调用Java中的那个native方法时，JVM就会自动跳转到DLL中对应的C/C++函数去执行。

2.2 环境准备与工具选择

工欲善其事，必先利其器。以下是经过验证的环境配置方案：

1. Java开发环境：

JDK：必须安装，而不仅仅是JRE。因为我们需要javac编译器、javah或javac -h工具来生成头文件。建议使用JDK 8或11这些LTS版本，稳定性有保障。确保JAVA_HOME环境变量正确设置，并且%JAVA_HOME%\bin添加到系统的PATH变量中。

2. C/C++编译环境：这是最容易出问题的一环。关键原则是：Java是32位还是64位，你的DLL就必须编译成对应的位数。一个64位的JVM无法加载32位的DLL，反之亦然。

Windows下推荐使用MinGW-w64或Visual Studio。
- MinGW-w64：轻量，适合生成与GCC兼容的DLL。安装后，使用x86_64-w64-mingw32-gcc（64位）或i686-w64-mingw32-gcc（32位）进行编译。
- Visual Studio：功能强大，尤其是处理复杂的C++项目或依赖特定MSVC运行库的DLL。你需要安装“使用C++的桌面开发”工作负载。编译时，务必在项目属性中设置正确的目标平台（x86或x64）。

3. 开发工具：

IDE：IntelliJ IDEA或Eclipse for Java开发；Visual Studio或CLion for C/C++开发。用你顺手的就行。
依赖查看工具：Dependency Walker（Depends.exe）是一个老牌但依然好用的工具，可以用来查看DLL的导出函数名、依赖的其他DLL，以及判断其是32位还是64位。在排查“找不到函数”的问题时非常有用。

注意：强烈建议将你的Java项目、C/C++源码、生成的DLL放在一个工程目录下管理。例如，可以建立/java-src，/c-src，/lib（放DLL）这样的结构，清晰明了。

3. 实战第一步：从Java声明到C/C++实现

让我们从一个最简单的例子开始：让Java调用一个DLL中的函数，实现两个整数的加法。

3.1 Java侧：声明Native方法与加载DLL

首先，我们创建一个Java类。

// 文件：src/com/example/calc/Calculator.java package com.example.calc; public class Calculator { // 1. 声明一个native方法 public native int add(int a, int b); // 2. 静态代码块，在类加载时加载DLL static { // 方式一：加载系统库路径下的DLL（无需后缀） // System.loadLibrary("MyNativeCalc"); // 方式二：指定绝对路径加载DLL（需要后缀） System.load("C:/projects/my-jni-demo/lib/MyNativeCalc.dll"); } public static void main(String[] args) { Calculator calc = new Calculator(); int result = calc.add(10, 20); System.out.println("The result is: " + result); // 期望输出 30 } }

关键点解析：

native关键字：告诉编译器，这个方法的实现不在当前的Java代码中。
System.loadLibrary(“MyNativeCalc”)：它会去java.library.path系统属性指定的路径（如PATH环境变量、-Djava.library.path=指定的路径）下寻找名为MyNativeCalc.dll（Windows）或libMyNativeCalc.so（Linux）的文件。注意，参数不包含“lib”前缀和文件扩展名。
System.load(“绝对路径”)：直接通过完整文件路径加载DLL。这在开发调试阶段非常方便，可以避免库路径配置问题。注意，参数需要完整的路径和文件名。
加载操作放在static块中，确保类被使用时DLL已就绪。

3.2 生成JNI头文件

接下来，我们需要根据Java类生成C/C++需要的头文件。

编译Java类：javac -d . src/com/example/calc/Calculator.java。这会生成com/example/calc/Calculator.class。
生成头文件。有两种方式，推荐使用第二种（JDK 10+）：
- 传统方式 (JDK 8及之前常用)：使用javah命令。
```
javah -o com_example_calc_Calculator.h com.example.calc.Calculator
```
- 现代方式 (JDK 10+ 推荐)：使用javac的-h选项，它更直接。
```
javac -h ./c-headers src/com/example/calc/Calculator.java
```
  这个命令会同时编译Java文件，并在指定的./c-headers目录下生成头文件。

生成的com_example_calc_Calculator.h内容大致如下：

/* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class com_example_calc_Calculator */ #ifndef _Included_com_example_calc_Calculator #define _Included_com_example_calc_Calculator #ifdef __cplusplus extern "C" { #endif /* * Class: com_example_calc_Calculator * Method: add * Signature: (II)I */ JNIEXPORT jint JNICALL Java_com_example_calc_Calculator_add (JNIEnv *, jobject, jint, jint); #ifdef __cplusplus } #endif #endif

解读这个“天书”：

#include <jni.h>：引入JNI标准头文件，定义了JNIEnv,jobject,jint等关键类型。
JNIEXPORT和JNICALL：这是编译器相关的宏，确保函数能被JVM正确调用和链接。
Java_com_example_calc_Calculator_add：这是函数名的命名规则，也是JNI查找函数的依据。格式为：Java_包名_类名_方法名。任何一点错误（大小写、下划线）都会导致UnsatisfiedLinkError。
(JNIEnv *, jobject, jint, jint)：函数参数。
- JNIEnv*：指向JNI环境的指针，是所有JNI函数的“入口”，通过它可以调用一系列JNI函数（如创建Java对象、调用Java方法等）。
- jobject：调用这个native方法的Java对象实例的引用（相当于Java里的this）。如果是静态native方法，这里则是jclass。
- 后面的jint, jint：对应Java方法中的两个int参数。jint是JNI中与Javaint对应的C类型。

3.3 C/C++侧：实现函数并编译为DLL

现在，我们创建C源文件来实现这个函数。

// 文件：c-src/Calculator.c #include <stdio.h> #include "com_example_calc_Calculator.h" // 引入生成的头文件 // 实现头文件中声明的函数 JNIEXPORT jint JNICALL Java_com_example_calc_Calculator_add (JNIEnv *env, jobject obj, jint a, jint b) { printf("[C] Received numbers: %d and %d\n", a, b); // 可以在控制台输出，便于调试 return a + b; // 执行加法并返回 }

代码非常简单，就是接收两个jint，相加后返回。printf语句是一个很好的调试习惯，可以确认函数确实被调用了。

接下来是最关键的一步：编译成DLL。这里以使用MinGW-w64为例（假设是64位系统）：

# 1. 首先，找到你的jni.h所在位置。它通常在 %JAVA_HOME%/include 和 %JAVA_HOME%/include/win32 下。 # 2. 编译命令 x86_64-w64-mingw32-gcc -I"%JAVA_HOME%/include" -I"%JAVA_HOME%/include/win32" -shared -o MyNativeCalc.dll Calculator.c

-I：指定头文件搜索路径，必须包含jni.h及其平台相关头文件（jni_md.h）的目录。
-shared：告诉编译器我们要生成一个动态链接库（DLL）。
-o MyNativeCalc.dll：指定输出的DLL文件名。

如果使用Visual Studio的MSVC编译器，通常是通过创建一个“动态链接库(DLL)”项目，将头文件路径添加到项目属性中的“附加包含目录”，然后编译生成。

编译成功后，你会得到MyNativeCalc.dll文件。

3.4 运行与测试

将生成的MyNativeCalc.dll文件，放到Java程序中System.load(...)指定的路径下，或者放到java.library.path包含的目录中（例如项目根目录、C:\Windows\System32等，但不推荐放系统目录）。

运行Java程序：

java -cp . com.example.calc.Calculator

如果一切顺利，你将看到输出：

[C] Received numbers: 10 and 20 The result is: 30

恭喜！你已经完成了最简单的JNI调用。但现实世界的需求远不止两个整数相加这么简单。

4. 核心难点突破：复杂数据类型的传递与处理

实际开发中，我们经常需要处理字符串、数组、自定义对象等复杂数据。JNI为这些Java类型提供了对应的C类型（如jstring,jintArray,jobject）和一系列操作函数。

4.1 字符串（String）的传递

Java中的String在JNI中是jstring类型。你不能直接把它当C的char*用，必须通过JNI函数进行转换。

C代码示例：拼接字符串并返回

JNIEXPORT jstring JNICALL Java_com_example_util_StringHelper_concat (JNIEnv *env, jobject obj, jstring str1, jstring str2) { // 1. 将jstring转换为C风格的字符串（UTF-8编码） const char *c_str1 = (*env)->GetStringUTFChars(env, str1, NULL); const char *c_str2 = (*env)->GetStringUTFChars(env, str2, NULL); // 检查转换是否成功（虽然NULL情况少见，但好的习惯） if (c_str1 == NULL || c_str2 == NULL) { return NULL; // 内存不足时会返回NULL } // 2. 执行操作（这里简单拼接，实际中注意缓冲区溢出！） // 计算所需内存 int len1 = strlen(c_str1); int len2 = strlen(c_str2); char *result_c_str = (char *)malloc(len1 + len2 + 1); strcpy(result_c_str, c_str1); strcat(result_c_str, c_str2); // 3. 将C字符串转换回jstring jstring result = (*env)->NewStringUTF(env, result_c_str); // 4. 释放第一步中获取的字符串资源！这是必须的，否则会内存泄漏。 (*env)->ReleaseStringUTFChars(env, str1, c_str1); (*env)->ReleaseStringUTFChars(env, str2, c_str2); // 5. 释放我们自己分配的堆内存 free(result_c_str); return result; }

重要原则：有Get就有Release。GetStringUTFChars和ReleaseStringUTFChars必须成对出现。对于Get<Type>ArrayElements也一样。

4.2 数组（Array）的传递

处理数组（如int[]）时，JNI提供了两种访问模式：

复制模式：GetIntArrayRegion/SetIntArrayRegion。将Java数组的一部分复制到C数组，或反之。适合处理小数组或只需部分数据。
直接指针模式：GetIntArrayElements。尝试获取指向Java数组底层数据的直接指针，JVM可能返回一个副本（如果数组在内存中不连续或出于安全考虑）。性能更高，但操作后必须Release。

C代码示例：计算整型数组的和（使用直接指针模式）

JNIEXPORT jint JNICALL Java_com_example_util_ArrayCalculator_sum (JNIEnv *env, jobject obj, jintArray javaArray) { jint sum = 0; jsize len = (*env)->GetArrayLength(env, javaArray); // 获取数组长度 // 获取数组元素指针。第三个参数是isCopy，可以传NULL，或者用一个jboolean变量接收是否被复制。 jint *c_array = (*env)->GetIntArrayElements(env, javaArray, NULL); if (c_array == NULL) { return 0; // 内存不足 } for (int i = 0; i < len; i++) { sum += c_array[i]; } // 释放数组元素。第三个参数mode： // 0: 将内容复制回原数组并释放c_array。 // JNI_COMMIT: 将内容复制回原数组，但不释放c_array。 // JNI_ABORT: 不复制回原数组，直接释放c_array。 (*env)->ReleaseIntArrayElements(env, javaArray, c_array, 0); return sum; }

4.3 在C代码中创建并返回Java对象

有时，我们需要在Native层构造一个复杂的Java对象返回给上层。

步骤：

通过FindClass获取类的引用（jclass）。
通过GetMethodID获取构造方法的ID。构造方法名固定为<init>，返回值类型为V（void）。
通过NewObject调用构造方法创建对象。
通过Set<Type>Field系列函数设置对象的字段值（如果需要）。

C代码示例：创建一个Person对象并返回假设Java中有个Person类：

package com.example.model; public class Person { public String name; public int age; public Person(String name, int age) { ... } // getters and setters... }

对应的Native方法实现：

JNIEXPORT jobject JNICALL Java_com_example_factory_PersonFactory_createPerson (JNIEnv *env, jclass clazz, jstring name, jint age) { // 1. 找到Person类 jclass personClass = (*env)->FindClass(env, "com/example/model/Person"); if (personClass == NULL) { return NULL; // 类找不到，可能抛异常 } // 2. 获取构造方法ID "(Ljava/lang/String;I)V" // 签名表示：参数为String和int，返回void jmethodID constructor = (*env)->GetMethodID(env, personClass, "<init>", "(Ljava/lang/String;I)V"); if (constructor == NULL) { return NULL; } // 3. 创建对象 jobject personObj = (*env)->NewObject(env, personClass, constructor, name, age); // 4. （可选）如果需要修改字段，先获取字段ID，再设置 // jfieldID nameField = (*env)->GetFieldID(env, personClass, "name", "Ljava/lang/String;"); // (*env)->SetObjectField(env, personObj, nameField, newNameString); // 5. 局部引用管理：如果这个函数会被频繁调用，且personClass是局部引用，需要考虑删除局部引用以避免内存泄漏。 // (*env)->DeleteLocalRef(env, personClass); return personObj; }

注意：方法签名（Signature）：这是JNI中一个容易出错的地方。(Ljava/lang/String;I)V表示一个参数为String和int，返回void的方法。可以使用javap -s -p ClassName命令来查看一个类中所有方法的签名。

5. 高级主题与性能、内存管理

当你的JNI调用变得频繁或复杂时，下面这些话题就至关重要了。

5.1 全局引用与局部引用

JNI中的对象引用分为局部引用和全局引用。

局部引用：在Native方法执行期间有效，方法返回后会被JVM自动释放。通过FindClass,NewObject,NewString等函数返回的默认都是局部引用。局部引用过多可能导致JNI局部引用表溢出（默认容量有限）。对于不再需要的大对象或循环中创建的对象，应使用DeleteLocalRef手动释放。
全局引用：跨多个Native方法调用、甚至跨线程都有效，直到你显式调用DeleteGlobalRef释放它。通过NewGlobalRef函数创建。
弱全局引用：类似全局引用，但不阻止垃圾回收器回收对象。通过NewWeakGlobalRef创建。

最佳实践：在Native方法中，如果创建了大量临时对象（尤其在循环中），应适时使用DeleteLocalRef。如果需要一个对象在多次调用间存活，则创建全局引用，并在不用时删除。

5.2 异常处理

JNI函数调用可能会抛出Java异常（例如，GetFieldID如果字段不存在会抛NoSuchFieldError）。在调用一个可能抛出异常的JNI函数后，必须检查异常，否则后续的JNI调用行为是未定义的。

检查和处理异常的模式：

// 调用一个可能抛出异常的JNI函数 (*env)->CallVoidMethod(env, obj, mid); // 检查是否有异常发生 jthrowable exc = (*env)->ExceptionOccurred(env); if (exc) { // 1. 打印异常堆栈（调试用） (*env)->ExceptionDescribe(env); // 2. 清除异常，让JVM可以继续运行 (*env)->ExceptionClear(env); // 3. 处理错误情况，例如返回一个错误码或默认值 return ERROR_CODE; }

你也可以在Native代码中抛出新的Java异常给上层：

jclass excClass = (*env)->FindClass(env, "java/lang/IllegalArgumentException"); if (excClass != NULL) { (*env)->ThrowNew(env, excClass, "Native layer: Invalid argument provided."); } // 抛出异常后，Native函数应立即返回，控制权交回JVM处理异常。

5.3 多线程环境下的JNI

黄金法则：不能在一个线程中创建的JNIEnv*指针，传递到另一个线程中使用。JNIEnv是线程相关的。

如果需要在子线程（通过pthread_create或CreateThread创建）中调用JNI函数，你必须先将线程附加（Attach）到JVM，获取该线程对应的JNIEnv*。

JavaVM *g_jvm; // 通常需要在JNI_OnLoad函数中保存全局的JavaVM指针 void* native_thread_func(void* args) { JNIEnv *env; // 将当前线程附加到JVM，获取JNIEnv int status = (*g_jvm)->AttachCurrentThread(g_jvm, (void**)&env, NULL); if (status < 0) { // 处理附加失败 return NULL; } // 现在可以安全地使用env调用JNI函数了 // ... 你的业务逻辑 ... // 线程结束前，从JVM分离 (*g_jvm)->DetachCurrentThread(g_jvm); return NULL; }

JavaVM指针可以通过JNI_OnLoad函数获取，并保存为全局变量。

5.4 JNI_OnLoad与JNI_OnUnload

这两个是DLL的生命周期钩子函数。

JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved)：当DLL被System.loadLibrary()加载时自动调用。在这里可以保存JavaVM指针、注册本地方法（另一种绑定Native方法的方式，比动态查找更高效）、初始化全局资源。必须返回它支持的JNI版本，如JNI_VERSION_1_8。
JNIEXPORT void JNI_OnUnload(JavaVM* vm, void* reserved)：当类加载器被垃圾回收、DLL即将被卸载时调用。在这里释放全局资源（如全局引用）。

6. 实战避坑指南与常见问题排查

纸上得来终觉浅，绝知此事要躬行。下面是我在多年实践中总结的“血泪教训”。

6.1 编译与链接阶段问题

问题1：找不到jni.h或jni_md.h等头文件。

原因：编译命令中-I包含的路径不正确。
解决：确认%JAVA_HOME%环境变量指向的是JDK目录，而不是JRE。头文件在%JAVA_HOME%/include和%JAVA_HOME%/include/win32下。

问题2：链接错误，提示找不到__imp_JNI_CreateJavaVM等符号。

原因：没有链接JVM的导入库（如jvm.lib）。
解决：在编译命令中加入链接库的路径和库名。例如，使用MinGW时可能不需要（它动态查找），但使用MSVC时通常需要。对于MSVC，在项目属性中添加附加依赖项jvm.lib，并添加库目录%JAVA_HOME%/lib。

6.2 运行时问题

问题1：java.lang.UnsatisfiedLinkError: no XXX in java.library.path

原因：System.loadLibrary()找不到指定的DLL。
排查：
1. 确认DLL文件名是否正确（不含后缀）。
2. 确认DLL所在目录是否在java.library.path中。可以在Java中打印System.getProperty(“java.library.path”)查看。
3. 最常用调试方法：改用System.load(“绝对路径”)，确保路径无误。

问题2：java.lang.UnsatisfiedLinkError: Can‘t find dependent libraries或A dynamic link library (DLL) initialization routine failed

原因：你的DLL依赖其他DLL（如特定的MSVC运行时库msvcr120.dll），但运行时环境找不到它们。
排查：
1. 使用Dependency Walker打开你的DLL，查看它依赖哪些其他DLL，并检查这些DLL是否存在于目标机器的系统路径或DLL同级目录下。
2. 对于MSVC编译的DLL，确保目标机器安装了对应版本的Visual C++ Redistributable。这是最常见的原因！

问题3：java.lang.UnsatisfiedLinkError: Native method not found: com.example...

原因：Java声明的native方法名与DLL中导出的函数名不匹配。
排查：
1. 使用Dependency Walker或dumpbin /exports YourDLL.dll命令查看DLL实际导出的函数名。
2. 仔细核对JNI函数命名规则：Java_包名_类名_方法名。注意包名中的点.要换成下划线_。
3. 如果是C++编写的，函数名可能会被编译器“修饰”（Name Mangling）。需要在函数声明前加上extern “C”，强制使用C语言的链接约定，避免名称修饰。

问题4：程序运行崩溃（Access Violation, Segmentation Fault）

原因：通常是Native代码中的内存错误，如空指针解引用、数组越界、使用已释放的内存、或者错误的JNI调用（如在异常发生后继续调用JNI函数）。
排查：
1. 在C/C++代码中加入大量日志输出，定位崩溃前最后执行的语句。
2. 使用调试器（如GDB, Visual Studio Debugger）附加到Java进程进行调试。这需要一些技巧，但非常有效。
3. 检查所有GetStringUTFChars,GetArrayElements等函数的返回值是否为NULL。
4. 确保Release调用与Get调用配对。
5. 检查多线程环境下是否正确处理了JNIEnv。

6.3 性能优化建议

减少JNI调用次数：JNI调用开销较大。应避免在循环中频繁进行JNI调用。尽量一次传递批量数据（如数组），在Native侧处理完毕后再一次性返回。
使用直接缓冲区（Direct Buffer）：对于需要频繁交换的大块数据（如图像、音频），考虑使用java.nio.ByteBuffer，并在Native侧通过GetDirectBufferAddress获取其内存地址直接操作，避免数据复制。
缓存ID：FindClass,GetMethodID,GetFieldID等查找操作比较耗时。对于频繁使用的类、方法和字段ID，应该在JNI_OnLoad或某个初始化函数中查找一次，并保存为全局静态变量。
谨慎选择数据传递方式：对于小型数据，使用Get/SetArrayRegion复制可能更简单安全。对于大型数组，使用GetPrimitiveArrayCritical可以获得近乎直接指针的性能，但在此期间必须不能调用其他JNI函数，且必须尽快Release。

7. 现代替代方案与工具链简化

传统的JNI开发流程略显繁琐。现代有一些工具和框架可以简化这个过程：

JavaCPP：一个开源库，它提供了预先配置好的“桥接器”，可以让你用更自然的方式在Java中访问许多流行的C/C++库（如OpenCV, FFmpeg, Tesseract等）。它自动处理了JNI的胶水代码生成。
JNA (Java Native Access)：另一个流行的库。它允许你直接调用DLL中的函数，而无需编写任何C/C++的JNI胶水代码。你只需要在Java中定义一个接口，用注解或继承的方式映射到DLL的函数。JNA在运行时通过反射和动态代理来完成调用。它的优点是开发极其快速，缺点是性能略低于手写的JNI，且对复杂C++对象映射支持较弱。
SWIG (Simplified Wrapper and Interface Generator)：一个接口编译器，它可以读取C/C++头文件，自动生成多种目标语言（包括Java）的包装代码。对于大型的、已有的C/C++代码库，SWIG可以节省大量手写绑定代码的时间。

对于新项目，如果性能要求不是极端苛刻，且DLL接口相对简单，JNA是一个非常好的快速原型和开发选择。如果追求极致性能或需要深度控制，手写JNI仍然是最终方案。

最后，我想分享一个最深的体会：JNI开发就像在两个国度之间建立外交关系，协议（规范）必须严格遵守，资源（内存、引用）必须管理得当。最初的搭建过程可能磕磕绊绊，但一旦通道建立稳固，它就能让Java生态与庞大的本地代码世界无缝联通，释放出巨大的能量。耐心、细心和对细节的掌控，是玩转JNI的不二法门。当你第一次看到Java代码成功调用那个承载着核心算法的DLL并返回正确结果时，那种跨越语言屏障的成就感，绝对是值得的。

查看全文

http://www.jsqmd.com/news/1409762/