1. 项目概述：为什么需要深入理解JNI封装？

在Java生态里混了这么多年，我处理过不少需要“跨界”调用的场景。Java以其“一次编写，到处运行”的特性闻名，但有时候，为了极致性能、复用成熟的C/C++库，或者直接操作底层硬件，我们不得不请出“老大哥”C语言。连接这两大巨头的桥梁，就是JNI。但很多开发者对JNI的认知，可能还停留在“照着模板写个Hello World”的阶段，一旦涉及到复杂的参数传递、内存管理、异常处理和性能优化，就一头雾水，代码写得既臃肿又脆弱。

这个项目标题点出了核心痛点：封装。直接使用原生的JNI接口进行开发，无异于在钢丝上跳舞。你需要手动处理繁琐的JNIEnv*指针、小心翼翼地转换jobject与原生指针、时刻警惕本地引用导致的内存泄漏，更别提多线程环境下的JNIEnv附着问题了。代码里充斥着FindClass、GetMethodID、CallVoidMethod这类样板代码，业务逻辑被淹没在JNI的细节中，可读性和可维护性极差。

因此，封装JNI不是一个“可选项”，而是一个追求工程质量的“必选项”。一次良好的封装，能将JNI的复杂性隐藏起来，为上层Java代码提供一个清晰、安全、高效的调用接口。这就像给你的C库穿上了一件合身的“Java外衣”，让Java开发者可以像调用普通Java方法一样使用底层能力，而无需关心JNI内部的“魔法”。本次实战，我将带你从原理到代码，手把手构建一个健壮的JNI封装层，并附上完整的测试步骤，确保你不仅能跑通Demo，更能掌握设计背后的“为什么”。

2. 核心原理拆解：JNI交互的底层逻辑与封装必要性

要封装得好，必须先理解得透。JNI的交互远比表面上System.loadLibrary那一下加载要复杂。

2.1 JNI的桥梁作用与数据类型映射

JNI的核心是一个双向的、类型化的通信协议。Java虚拟机通过一个固定的接口指针JNIEnv*，为本地代码提供了一整套访问Java世界的能力。所有JNI函数调用都通过这个指针进行。

最基础也最容易出错的就是数据类型的转换。Java中的int对应JNI的jint，String对应jstring，对象对应jobject。但请注意，jstring和jobject在本地代码中只是“引用”（一个指针），你不能直接像操作C字符串一样操作jstring。必须使用GetStringUTFChars将其转换为const char*，使用完毕后必须用ReleaseStringUTFChars释放。这个“获取-释放”的配对操作是内存安全的生命线，一旦遗漏就会导致内存泄漏或JVM崩溃。

注意：GetStringUTFChars得到的字符串是JVM内部UTF-8格式的修改版，可能包含\0字符。如果你需要标准的C字符串（以\0结尾），并且字符串内容不包含\0，可以使用它。对于可能包含\0的字符串或需要精确的UTF-16编码时，应使用GetStringChars和GetStringLength。

2.2 引用管理：本地引用、全局引用与弱全局引用

这是JNI内存管理的核心，也是封装层必须妥善处理的部分。

• 本地引用：在本地方法中创建的大多数引用（如NewStringUTF、FindClass返回的引用）都是本地引用。它们在本方法执行期间有效，方法返回后会自动被JVM垃圾回收。问题在于：如果你在本地方法中创建了大量本地引用（例如在循环中创建对象），可能会耗尽JVM为本地方法栈分配的引用槽，导致FatalError。封装层需要警惕这种情况。
• 全局引用：通过NewGlobalRef创建，在显式调用DeleteGlobalRef之前一直有效，可以被多个线程、多次本地方法调用共享。常用于缓存jclass、jmethodID等。
• 弱全局引用：通过NewWeakGlobalRef创建，它不阻止所引用对象被垃圾回收。在使用前，必须用IsSameObject与NULL比较，或调用ExceptionCheck来检查对象是否已被回收。

一个健壮的封装层，通常会在一开始（如JNI_OnLoad函数中）就创建并缓存所需的全局引用（如jclass），避免每次调用都进行昂贵的FindClass操作。同时，要确保所有创建的全局引用在适当的时候（如JNI_OnUnload）被删除。

2.3 异常处理：跨越边界的错误传播

Java异常在本地代码中不会自动抛出。当调用一个JNI函数（如CallObjectMethod）导致Java端抛出异常时，这个异常在本地代码中处于“待决”状态。此时，绝大多数后续的JNI函数调用都会失败，直到异常被处理。

本地代码处理异常有两种方式：

1. 返回：立即从本地方法返回，让异常在Java调用栈中向上传播。这是最常见的方式。
2. 清除：调用ExceptionClear()清除待决异常，然后用自己的错误处理逻辑（如返回错误码）。

封装层必须设计统一的异常处理策略。例如，可以定义一个宏或内联函数，在每次关键JNI调用后检查异常，如果发生异常，则清理资源并立即返回一个错误标识，确保本地代码不会在异常状态下继续执行危险操作。

2.4 多线程安全：JNIEnv的附着与分离

JNIEnv*指针是线程相关的。它只在创建它的线程中有效。你不能将一个线程的JNIEnv传递给另一个线程使用。

当一个本地线程（非由JVM创建的线程，如pthread）需要调用JNI函数时，它必须先“附着”到JVM上，通过JavaVM*指针（这是一个全局引用，可以在线程间共享）调用AttachCurrentThread来获取属于当前线程的JNIEnv*。使用完毕后，如果该线程将不再调用JNI，应调用DetachCurrentThread进行分离。

封装层如果涉及多线程回调（例如，C库在后台线程完成计算后通知Java），就必须妥善处理JNIEnv的附着与分离，否则会导致JVM崩溃。

3. 封装层设计：构建清晰、安全、高效的交互边界

理解了原理，我们就可以开始设计封装层了。好的设计应该遵循“高内聚、低耦合”的原则，将JNI的脏活、累活都收拢在一处。

3.1 设计目标与原则

我们的封装层应该实现以下目标：

1. 对Java开发者透明：Java端看到的是一组干净的、带有JavaDoc注释的native方法声明。
2. 对C开发者友好：C端提供一组简单的、线程安全的C风格函数接口，内部处理所有JNI细节。
3. 内存安全：确保所有JNI引用（字符串、数组、全局引用）都被正确获取和释放，无泄漏。
4. 异常安全：确保任何Java异常或C端错误都能被妥善处理，不会导致JVM崩溃或资源泄漏。
5. 线程安全：支持在多线程环境下被安全调用，正确处理JNIEnv的附着。
6. 性能高效：缓存jclass、jmethodID等元数据，避免重复查找。

3.2 核心组件与接口定义

我们将封装层分为三个部分：

• Java层接口：定义native方法和可能用到的回调接口。
• JNI胶水层：实现JNI_OnLoad、JNI_OnUnload，并注册本地方法。它负责将Java调用路由到真正的C实现，并处理基本的类型转换和异常检查。
• 纯C实现层：这是我们真正的业务逻辑所在。它接收来自胶水层的、已经转换好的C数据类型，执行计算，并通过胶水层返回结果或抛出异常。

以一个简单的“计算器”库为例，我们想用C实现高性能的向量点积运算。

第一步：定义Java层接口 (NativeCalculator.java)

public class NativeCalculator { // 加载封装后的本地库，名字由后续编译决定（如 libnative_calc_jni.so 或 native_calc_jni.dll） static { System.loadLibrary("native_calc_jni"); } /** * 计算两个双精度浮点数向量的点积。 * @param vecA 向量A * @param vecB 向量B * @return 点积结果 * @throws IllegalArgumentException 如果向量为null或长度不匹配 * @throws NativeException 如果底层C库发生错误 */ public static native double dotProduct(double[] vecA, double[] vecB); }

这里我们明确声明了可能抛出的异常，这是良好封装的一部分。

第二步：设计JNI胶水层头文件 (native_calc_jni.h)这个头文件由javac -h命令自动生成，但我们关注其内容：

/* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class NativeCalculator */ #ifndef _Included_NativeCalculator #define _Included_NativeCalculator #ifdef __cplusplus extern "C" { #endif /* * Class: NativeCalculator * Method: dotProduct * Signature: ([D[D)D */ JNIEXPORT jdouble JNICALL Java_NativeCalculator_dotProduct (JNIEnv *, jclass, jdoubleArray, jdoubleArray); #ifdef __cplusplus } #endif #endif

函数名遵循Java_完整类名_方法名的规范，签名([D[D)D表示接收两个double数组，返回一个double。

第三步：设计纯C实现层接口 (native_calc_core.h)这是封装的关键。我们为C库设计一个不依赖JNI的纯净接口。

// native_calc_core.h #ifndef NATIVE_CALC_CORE_H #define NATIVE_CALC_CORE_H #include <stddef.h> // for size_t #ifdef __cplusplus extern "C" { #endif /** * 计算两个双精度浮点数向量的点积（C接口）。 * @param vecA 向量A的指针 * @param vecB 向量B的指针 * @param len 向量的长度 * @param[out] result 点积结果 * @return 0表示成功，非0表示错误码（如长度<=0，指针为NULL） */ int calc_dot_product(const double* vecA, const double* vecB, size_t len, double* result); #ifdef __cplusplus } #endif #endif // NATIVE_CALC_CORE_H

这个接口是标准的C函数，任何C程序都可以调用。错误通过返回值传递，结果通过输出参数返回。这隔离了JNI和业务逻辑。

4. 胶水层实现：连接Java与C核心的粘合剂

现在，我们来实现最关键的JNI胶水层 (native_calc_jni.c)。它的职责是将JNI的复杂调用，转换为对纯净C接口的简单调用。

4.1 全局缓存与初始化/反初始化

首先，我们需要缓存一些全局使用的jclass和jmethodID，比如我们自定义的NativeException类。

#include <jni.h> #include "native_calc_core.h" // 引入纯C接口 #include <stdlib.h> #include <string.h> // 全局引用缓存 static jclass g_NativeExceptionClass = NULL; static jmethodID g_NativeExceptionConstructor = NULL; // 自定义异常类名，需与Java端完全一致 #define NATIVE_EXCEPTION_CLASS "com/example/jni/NativeException" JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) { JNIEnv* env = NULL; if ((*vm)->GetEnv(vm, (void**)&env, JNI_VERSION_1_8) != JNI_OK) { return JNI_ERR; // 不支持JNI 1.8 } // 查找并缓存NativeException类 jclass localClass = (*env)->FindClass(env, NATIVE_EXCEPTION_CLASS); if (localClass == NULL) { // FindClass失败会抛出异常，直接返回错误 return JNI_ERR; } // 创建全局引用，防止类被卸载 g_NativeExceptionClass = (*env)->NewGlobalRef(env, localClass); (*env)->DeleteLocalRef(env, localClass); // 删除本地引用 if (g_NativeExceptionClass == NULL) { return JNI_ERR; } // 获取NativeException的构造函数ID // 假设构造函数为 NativeException(String message, int errorCode) g_NativeExceptionConstructor = (*env)->GetMethodID(env, g_NativeExceptionClass, "<init>", "(Ljava/lang/String;I)V"); if (g_NativeExceptionConstructor == NULL) { // GetMethodID失败也会抛出异常 (*env)->DeleteGlobalRef(env, g_NativeExceptionClass); g_NativeExceptionClass = NULL; return JNI_ERR; } return JNI_VERSION_1_8; } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM* vm, void* reserved) { JNIEnv* env = NULL; if ((*vm)->GetEnv(vm, (void**)&env, JNI_VERSION_1_8) != JNI_OK) { return; // 环境获取失败，可能正在卸载，直接返回 } // 删除全局引用，避免内存泄漏 if (g_NativeExceptionClass != NULL) { (*env)->DeleteGlobalRef(env, g_NativeExceptionClass); g_NativeExceptionClass = NULL; g_NativeExceptionConstructor = NULL; } }

4.2 工具函数：异常抛出与资源管理

为了代码清晰，我们编写几个工具函数。

// 工具函数：抛出IllegalArgumentException static void throw_illegal_argument_exception(JNIEnv* env, const char* message) { jclass exClass = (*env)->FindClass(env, "java/lang/IllegalArgumentException"); if (exClass != NULL) { (*env)->ThrowNew(env, exClass, message); (*env)->DeleteLocalRef(env, exClass); } // 如果FindClass失败，那JVM可能已经处于非常糟糕的状态，我们无能为力。 } // 工具函数：抛出我们自定义的NativeException static void throw_native_exception(JNIEnv* env, int errorCode, const char* message) { if (g_NativeExceptionClass == NULL || g_NativeExceptionConstructor == NULL) { // 缓存未初始化，抛出更通用的异常 throw_illegal_argument_exception(env, "JNI layer not properly initialized."); return; } jstring jMessage = (*env)->NewStringUTF(env, message); if (jMessage == NULL) { // 内存不足，无法创建字符串，直接返回让之前的异常传播或产生新的OutOfMemoryError return; } jobject exception = (*env)->NewObject(env, g_NativeExceptionClass, g_NativeExceptionConstructor, jMessage, errorCode); (*env)->DeleteLocalRef(env, jMessage); if (exception != NULL) { (*env)->Throw(env, exception); (*env)->DeleteLocalRef(env, exception); } } // 工具函数：安全的获取数组指针和长度，并确保释放 typedef struct { void* elems; jsize len; jboolean isCopy; } JniArrayCritical; // 使用 GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical 以获得可能的最优性能（JVM可能返回直接指针） static int get_double_array_critical(JNIEnv* env, jdoubleArray jArray, JniArrayCritical* out) { if (jArray == NULL || out == NULL) { return -1; } out->len = (*env)->GetArrayLength(env, jArray); out->elems = (*env)->GetPrimitiveArrayCritical(env, jArray, &(out->isCopy)); if (out->elems == NULL) { // 可能抛出了OutOfMemoryError return -2; } return 0; } static void release_double_array_critical(JNIEnv* env, jdoubleArray jArray, JniArrayCritical* crit) { if (crit != NULL && crit->elems != NULL) { (*env)->ReleasePrimitiveArrayCritical(env, jArray, crit->elems, 0); // 模式0 crit->elems = NULL; } }

4.3 核心JNI方法实现

现在，实现Java_NativeCalculator_dotProduct函数。

JNIEXPORT jdouble JNICALL Java_NativeCalculator_dotProduct (JNIEnv *env, jclass clazz, jdoubleArray jVecA, jdoubleArray jVecB) { // 1. 输入参数检查 if (jVecA == NULL || jVecB == NULL) { throw_illegal_argument_exception(env, "Input arrays must not be null."); return 0.0; // 异常已抛出，返回值将被忽略 } JniArrayCritical critA = {0}, critB = {0}; int getStatusA = get_double_array_critical(env, jVecA, &critA); int getStatusB = get_double_array_critical(env, jVecB, &critB); // 检查是否成功获取到临界数组 if (getStatusA != 0 || getStatusB != 0) { // 释放可能已获取的资源 release_double_array_critical(env, jVecA, &critA); release_double_array_critical(env, jVecB, &critB); // 如果是因为内存不足，JVM已抛出OutOfMemoryError，直接返回 return 0.0; } // 2. 检查数组长度是否匹配 if (critA.len != critB.len) { release_double_array_critical(env, jVecA, &critA); release_double_array_critical(env, jVecB, &critB); throw_illegal_argument_exception(env, "Input arrays must have the same length."); return 0.0; } if (critA.len == 0) { release_double_array_critical(env, jVecA, &critA); release_double_array_critical(env, jVecB, &critB); // 空向量点积为0，直接返回，不视为错误 return 0.0; } // 3. 调用纯C核心函数 double result = 0.0; int cErrorCode = calc_dot_product((const double*)critA.elems, (const double*)critB.elems, (size_t)critA.len, &result); // 4. 释放临界区资源（必须在调用C函数之后，返回之前） release_double_array_critical(env, jVecA, &critA); release_double_array_critical(env, jVecB, &critB); // 5. 处理C核心函数返回的错误码 if (cErrorCode != 0) { // 根据错误码抛出相应的自定义异常 const char* errorMsg = "Unknown native error"; switch(cErrorCode) { case 1: errorMsg = "Invalid vector length (must be > 0)"; break; case 2: errorMsg = "Memory allocation failed in native code"; break; // ... 其他错误码 default: break; } throw_native_exception(env, cErrorCode, errorMsg); return 0.0; } // 6. 返回成功结果 return (jdouble)result; }

5. 纯C核心实现与编译构建

胶水层完成后，实现纯C核心就很简单了。

5.1 C核心实现 (native_calc_core.c)

#include "native_calc_core.h" #include <math.h> // 如果需要 int calc_dot_product(const double* vecA, const double* vecB, size_t len, double* result) { // 输入验证 if (vecA == NULL || vecB == NULL || result == NULL) { return -1; // 无效指针 } if (len == 0) { *result = 0.0; return 0; // 长度为0是合法的，点积为0 } double sum = 0.0; for (size_t i = 0; i < len; ++i) { sum += vecA[i] * vecB[i]; } *result = sum; return 0; // 成功 }

你可以在这里实现任何复杂的算法，比如使用SIMD指令进行加速。

5.2 编译与链接（Linux/macOS示例）

我们需要编译两个部分：纯C核心库和JNI胶水层库。通常将它们合并成一个动态库。

编写CMakeLists.txt (推荐)

cmake_minimum_required(VERSION 3.10) project(NativeCalcJNI) # 查找Java，获取JNI头文件路径 find_package(Java REQUIRED) find_package(JNI REQUIRED) # 包含JNI头文件 include_directories(${JNI_INCLUDE_DIRS}) # 编译纯C核心为静态库，方便单元测试 add_library(native_calc_core STATIC native_calc_core.c) # 编译JNI胶水层为共享库，并链接核心静态库 add_library(native_calc_jni SHARED native_calc_jni.c) target_link_libraries(native_calc_jni native_calc_core ${JNI_LIBRARIES}) # 设置输出库名（不含lib前缀和.so后缀，需与Java中System.loadLibrary参数匹配） set_target_properties(native_calc_jni PROPERTIES OUTPUT_NAME "native_calc_jni")

编译命令：

mkdir build && cd build cmake .. make

编译后会在build目录下生成libnative_calc_jni.so（Linux）或libnative_calc_jni.dylib（macOS）。

Windows (MinGW或MSVC) 注意事项在Windows上，库名后缀为.dll，且Java的System.loadLibrary寻找的是不带lib前缀的库名。你可能需要将库命名为native_calc_jni.dll，并在CMake中设置CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS或显式导出JNI函数。

6. 完整测试步骤：从单元测试到集成验证

封装完成，必须经过严格测试。我习惯采用分层测试策略。

6.1 纯C核心单元测试

首先，独立测试C核心逻辑，不涉及JNI。这可以用任何C单元测试框架（如Unity、Check）或简单的测试程序完成。

// test_core.c #include "native_calc_core.h" #include <stdio.h> #include <assert.h> int main() { double vec1[] = {1.0, 2.0, 3.0}; double vec2[] = {4.0, 5.0, 6.0}; double result = 0.0; int ret = calc_dot_product(vec1, vec2, 3, &result); assert(ret == 0); printf("Test 1: %f (expected: %f)\n", result, 32.0); // 1*4 + 2*5 + 3*6 = 32 assert(fabs(result - 32.0) < 1e-9); // 测试空数组 ret = calc_dot_product(NULL, NULL, 0, &result); assert(ret == 0); assert(fabs(result - 0.0) < 1e-9); // 测试错误输入 ret = calc_dot_product(NULL, vec2, 3, &result); assert(ret != 0); printf("All core tests passed!\n"); return 0; }

编译并运行这个测试程序，确保核心算法和错误处理正确。

6.2 JNI层集成测试（Java端）

使用JUnit或TestNG编写Java测试类。

import org.junit.jupiter.api.BeforeAll; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; public class NativeCalculatorTest { @BeforeAll static void loadLibrary() { // 假设动态库路径已加入 -Djava.library.path，或放在系统库目录 // 如果放在当前目录，对于测试可能需要特殊处理 try { System.loadLibrary("native_calc_jni"); } catch (UnsatisfiedLinkError e) { fail("Failed to load native library: " + e.getMessage()); } } @Test void testDotProductBasic() { double[] a = {1.0, 2.0, 3.0}; double[] b = {4.0, 5.0, 6.0}; double result = NativeCalculator.dotProduct(a, b); assertEquals(32.0, result, 1e-9); } @Test void testDotProductEmptyArray() { double[] a = {}; double[] b = {}; double result = NativeCalculator.dotProduct(a, b); assertEquals(0.0, result, 1e-9); } @Test void testDotProductNullArray() { assertThrows(IllegalArgumentException.class, () -> { NativeCalculator.dotProduct(null, new double[]{1.0}); }); assertThrows(IllegalArgumentException.class, () -> { NativeCalculator.dotProduct(new double[]{1.0}, null); }); } @Test void testDotProductLengthMismatch() { double[] a = {1.0, 2.0}; double[] b = {3.0}; assertThrows(IllegalArgumentException.class, () -> { NativeCalculator.dotProduct(a, b); }); } // 如果需要测试NativeException，可以在C核心代码中模拟一个错误码返回 // @Test // void testNativeException() { ... } }

运行这些测试，确保JNI封装层能正确地将Java调用转发给C核心，并能妥善处理边界情况和异常。

6.3 性能与内存测试

对于性能敏感的应用，还需要进行性能对比测试（与纯Java实现对比）和内存泄漏检查。

• 性能测试：使用JMH（Java Microbenchmark Harness）进行可靠的微基准测试，比较封装后的JNI调用与纯Java实现的性能差异。注意JNI调用本身有开销，对于非常简单的操作（如单个加法），JNI开销可能超过计算收益。只有计算密集型任务才值得用JNI优化。
• 内存泄漏检查：
  • Valgrind (Linux/macOS)：使用Valgrind运行你的Java测试程序（通过-agentlib:jdwp等方式），检查C代码中是否存在内存泄漏、非法内存访问。命令类似：valgrind --leak-check=full java -Djava.library.path=/path/to/libs -cp ... TestClass。
  • AddressSanitizer (ASan)：在编译C代码时加上-fsanitize=address标志，然后运行测试，ASan能检测出内存错误。
  • Java Profiler：使用VisualVM、JProfiler或Async-Profiler观察JVM的本地内存（Native Memory）使用情况，看是否有持续增长，这可能暗示JNI层存在未释放的全局引用或直接内存。

6.4 多线程安全测试

如果封装层可能被多线程调用，或者C库内部有状态，必须进行并发测试。

@Test void testConcurrentDotProduct() throws InterruptedException { int threadCount = 10; int iterations = 10000; ExecutorService executor = Executors.newFixedThreadPool(threadCount); List<Future<Double>> futures = new ArrayList<>(); for (int t = 0; t < threadCount; t++) { futures.add(executor.submit(() -> { double localSum = 0.0; double[] a = {1.0, 1.0}; double[] b = {1.0, 1.0}; for (int i = 0; i < iterations; i++) { localSum += NativeCalculator.dotProduct(a, b); // 结果应为2.0 } return localSum; })); } executor.shutdown(); executor.awaitTermination(1, TimeUnit.MINUTES); double totalSum = 0.0; for (Future<Double> f : futures) { totalSum += f.get(); } double expected = threadCount * iterations * 2.0; assertEquals(expected, totalSum, 1e-9); }

这个测试创建多个线程反复调用本地方法，检查是否存在数据竞争或JNI环境相关的崩溃。

7. 高级话题与避坑指南

在实际项目中，你可能会遇到更复杂的情况。这里分享几个我踩过的坑和对应的解决方案。

7.1 处理复杂对象与嵌套结构

传递简单类型和数组还好，如果要传递或返回一个复杂的Java对象怎么办？例如，一个User对象，里面有String name和int id。

方案：使用“扁平化”参数或JSON序列化。

• 扁平化：在JNI层，将Java对象的字段逐个取出，转换为C结构体。返回时，再根据C结构体创建新的Java对象或修改传入的对象。这需要为每种对象类型编写繁琐的Get/Set代码。可以使用代码生成工具（如javac -h生成头文件，然后编写辅助函数）来减少工作量。
• JSON序列化：如果对象结构复杂且多变，可以考虑在Java端使用Gson/Jackson将对象序列化为JSON字符串，通过JNI传递给C层一个const char*。C层使用如cJSON之类的库解析。计算结果再序列化为JSON字符串传回。这种方法牺牲了一些性能，但极大提高了灵活性和开发效率，尤其适合配置传递或复杂数据交换。

7.2 在C/C++中回调Java方法

这是实现异步通知的关键。例如，C库完成一个耗时操作后，需要通知Java端。

步骤：

1. Java端将一个回调接口实例（如Runnable或自定义Callback）作为参数传递给本地方法。
2. JNI层将该jobject回调实例转换为全局引用（NewGlobalRef）并保存起来。
3. C层在合适的时机（可能在另一个线程）触发回调。
4. 在触发回调的线程中，必须首先附着到JVM（AttachCurrentThread）获取JNIEnv*。
5. 使用保存的全局引用和JNIEnv*调用回调对象的Java方法。
6. 回调完成后，如果该线程是专为回调创建的，需要分离（DetachCurrentThread）。
7. 最后，在不再需要时（如Java对象被回收时，可通过PhantomReference或显式调用一个dispose本地方法），删除全局引用（DeleteGlobalRef）。

重要警告：保存jobject为全局引用是必须的，因为本地引用在方法返回后无效。同时，必须管理好这个全局引用的生命周期，防止内存泄漏。在多线程回调中，附着/分离JVM和JNIEnv的使用是线程安全的关键。

7.3 管理本地内存与避免内存泄漏

除了JNI引用，C层自己分配的内存（malloc,new）也需要管理。如果C层分配内存并将指针返回给Java（例如，返回一个指向大量数据的ByteBuffer），必须提供相应的释放函数（native void freeBuffer(long handle)），并在其中调用free或delete。

一种更安全的方式是使用ByteBuffer.allocateDirect在Java端分配直接内存，然后通过GetDirectBufferAddress获取其地址在C端使用。这样内存生命周期由JVM的垃圾回收器管理，当ByteBuffer对象被回收时，其关联的本地内存也会被释放（通过关联的Cleaner）。这可以避免手动内存管理带来的复杂性。

7.4 跨平台编译与ABI兼容性

• 数据类型大小：jint、jlong等在平台上是固定的，但你的C代码中的int、long可能因平台而异。在涉及与Java交互的固定长度数据时，最好使用<stdint.h>中的int32_t、int64_t等。
• 结构体对齐：如果通过JNI传递结构体的字节流（例如使用ByteBuffer），需要注意不同平台下结构体的内存对齐（#pragma pack或__attribute__((packed))）可能不同，这会导致数据错位。发送前在Java端或C端进行序列化/反序列化是更稳妥的做法。
• 编译工具链：确保你的本地库与JVM使用相同的ABI（应用二进制接口）。在Linux上，这通常不是问题。在Windows上，如果用MinGW编译的库，可能无法被MSVC构建的JVM加载，反之亦然。最好使用与你的JDK版本匹配的编译器（Oracle JDK通常使用MSVC编译）。

封装JNI是一个细致活，需要兼顾Java的优雅和C的严谨。一次成功的封装，能让你在享受C/C++高性能的同时，保持Java项目的高可维护性。记住，封装的核心思想是隔离复杂性和保证安全。把JNI的细节隐藏在薄薄的一层胶水代码后面，让两端的开发者都能专注于自己擅长的领域，这才是高效协作的关键。