JNI类型系统深度解析：掌握Java与C++数据交互的核心机制

1. 为什么JNI的类型系统是第一道门槛提起JNI很多人的第一反应是调用native方法这件事本身但真正上手写代码的时候最先卡住的往往不是方法调用而是类型问题。JNI有一套自己的类型体系它既不是纯粹的C/C类型也不是Java类型的简单映射而是一套夹在两层世界之间的翻译规则。不理解这套规则后面所有对数组、字符串、对象、回调的处理都会变得非常别扭。我在Clion里配置JNI环境时遇到过一件很典型的事明明Java端传过来一个intnative层声明参数是jint结果打印出来数值是对的但一旦改成long类型数值就变成了乱码。问题就出在jint和jlong在C/C层面本质上就是不同长度的整数类型Java 的int固定占4字节C语言里int的字节数却是跟平台走的。JNI定义jint就是为了绕过C语言int不跨平台的问题让你在任何平台上都能拿到一个确定的4字节有符号整数。还有一个高频误区是直接把Java的String当作char *处理。Java的String是UTF-16编码的Unicode字符序列而C语言的字符串是字节流两者连基本的存在形式都不一样。JNI专门设计了jstring类型和一组转换函数来处理这种差异如果你尝试用GetStringUTFChars这种API去拿一个字符串指针拿到的其实是JVM内部临时分配的字节数组副本修改它不会影响Java层的String对象这是很多人第一次写native字符串处理时会惊讶的地方。这篇文章会把JNI类型系统从头到尾梳理一遍重点讲清楚三件事JNI的原始类型为什么这么设计、引用类型和原始类型的关系、以及在实际工程中处理这些类型时常见的坑。适合刚接触JNI的读者也适合写过一些native代码但一直没系统梳理过类型体系的开发者。读完你对Java和C之间到底是怎么传数据的会有一个完整的认识。2. JNI原始类型的底层对应关系2.1 jint、jlong、jboolean这些类型到底是什么JNI规范在jni.h头文件里定义了一整套原始类型的映射关系它们的本质其实非常简单都是C/C里的typedef别名只不过固定了字节长度。Java类型JNI类型C/C底层类型字节数说明intjintint32_t4有符号32位整数longjlongint64_t8有符号64位整数bytejbyteint8_t1有符号8位整数shortjshortint16_t2有符号16位整数floatjfloatfloat4IEEE 754单精度doublejdoubledouble8IEEE 754双精度charjcharuint16_t2无符号16位UTF-16编码单元booleanjbooleanuint8_t10表示false非0表示truevoidvoidvoid-无返回值这张表建议直接存下来因为它是整个JNI类型系统的地基。注意几个容易混淆的地方。第一个是jchar是无符号16位整数。Java的char是16位的Unicode字符所以JNI里jchar必须能完整承载一个UTF-16编码单元用uint8_t那种1字节类型肯定不行。很多从C语言转过来的开发者会本能地把jchar当成char1字节来处理结果就是中文字符取出来全是乱的。第二个是jboolean只有0和非0两种语义。JNI官方文档明确说jboolean的取值应该只用JNI_FALSE0和JNI_TRUE1但C/C里任何非0值都会被认为是真。Java层的boolean传给native之后你拿到的不一定是1可能是任何非0值。规范虽说不允许别的值但保险起见判断时应该写成if (value ! JNI_FALSE)而不是if (value JNI_TRUE)。第三个是jfloat和jfloat之间不要直接做位运算。Java的float和C的float在绝大部分平台上是同一个东西但JNI规范里其实没有强制规定C的float必须符合IEEE 754只是实际平台基本上都符合。在嵌入式或者特殊编译器环境下如果你要做跨平台移植最好用jfloat原生类型直接传递数值不要试图去看它的内存位模式。2.2 原始类型在JVM内部是怎么传的我们平时写native方法参数和返回值走的是JVM的解释器栈。JVM内部有一套自己的表示方式比如Java栈帧里的slotJNI层看到的其实是JVM把这些slot压缩成一堆C类型参数传过来的。JNI规范里明确了一个原则原始类型按值传递引用类型按引用传递。对于int、long这种标量JVM直接把它们复制到native函数的参数里你在native层修改参数值不会影响Java层调用方的局部变量。比如Java端调一个native方法把int传进去native层把jint参数改成100Java端那个int变量还是原来的值。这个行为跟Java自己的方法参数传递完全一致Java方法内修改参数也不会影响外部变量。但这里有一个很多人忽略的细节JNI层拿到jint和Java层拿到int本质上是同一份数据的不同视图JVM在处理整数时不需要做任何转换直接把栈里的值搬过去就行。真正会做转换的是booleanJVM内部的boolean是1字节但规范要求native层看到的是jboolean也就是uint8_t所以JVM要确保传给native的值不越界。而char会复杂一点Java的char在JVM内部是16位无符号jchar也是16位无符号这个转换是平凡的。再说返回值和参数同理。native函数返回一个jintJVM把它塞回调用方的栈里后续字节码再把它压栈或者存到局部变量。整个过程没有装箱拆箱也没有对象分配所以JNI调用原始类型参数的效率是可以很高的。这也是为什么一些对性能敏感的库比如图像处理、音频处理会优先选择用JNI在native层做计算然后用原始类型接口把结果传回Java。2.3 原始类型不匹配时会发生什么JNI规范对类型匹配有严格校验一旦你Java声明的方法签名和native函数实际接收的参数类型不一致JVM会在调用时报错。最常见的错误就是Java方法声明参数是intnative函数却写成了jlong调用时会抛出UnsatisfiedLinkError或者NoSuchMethodError。这个校验发生在方法解析阶段不是调用阶段。JVM根据Java方法名和签名去动态库里找对应名字的native函数如果签名对不上链接就失败。所以你会发现明明代码能编译通过、动态库也加载了但一调用就报method not found。我建议在调试阶段先把native方法都声明成public static native然后写一个单元测试把所有方法全部触发一遍一旦链接不匹配就能快速暴露。等你把所有方法都调通了再改回真实访问级别能省下不少排查时间。这个经验在Clion里配合JNI插件尤其好使遇到链接错误直接看日志里的方法签名就能快速定位。3. 引用类型jobject体系不是所有对象都一样3.1 从jstring到jarray再到自定义对象JNI引用类型的大致体系如下jobject所有Java对象的通用引用类型相当于Java里的Objectjclassjava.lang.Class对象的引用反射操作里经常用到jstringjava.lang.String对象的引用jarray数组的通用引用类型jbooleanArray、jbyteArray、jintArray等各种基本类型数组的引用jobjectArray引用类型数组的引用jthrowableThrowable对象的引用这里最需要纠正的认知是jstring不是一个直接可用的C字符串jintArray也不是一个可以直接下标访问的int指针。它们是JVM堆上对象的句柄handle你拿着这个句柄必须通过JNI提供的函数去访问里面的实际数据。为什么JNI不直接把Java数组指针暴露给native层因为JVM有垃圾回收机制对象可能在内存中被移动。如果你拿着一个裸指针GC一旦移动对象这个指针就悬空了。JNI的解决方式是你通过JNI函数告诉JVM你要访问某个数组或字符串JVM给你一个固定的指针或一份拷贝访问完之后你再通过Release系列函数告知JVM我不再需要这个固定区域了。这套机制叫做pinning和copying它是理解所有JNI引用类型访问函数的关键。拿jintArray举例。你要读取一个int数组的所有元素标准流程是jint *elements (*env)-GetIntArrayElements(env, array, NULL); // 使用 elements[0..len-1] (*env)-ReleaseIntArrayElements(env, array, elements, 0);JVM可能直接把数组内部的内存锁定后返回指针pinning模式也可能复制一份数组出来给你copying模式。你无法从API层面确定是哪种模式除非通过第三个参数isCopy传出但无论哪种模式对你来说都一样用完必须Release。如果没有Release在copying模式下JVM没法把你修改的数据同步回Java数组在pinning模式下JVM没法解除内存锁定可能导致GC被阻塞。3.2 为什么jobject在C和C写法不同接触过JNI的读者一定见过两种风格的代码C风格的写法和C风格的写法。C风格的JNI函数调用长这样jsize len (*env)-GetArrayLength(env, arr);C风格的写法则把env封装成了JNIEnv类jsize len env-GetArrayLength(arr);造成这种差异的原因很简单jni.h在C环境下定义JNIEnv为一个带成员函数的类在C环境下定义为一个结构体指针。底层调用的JNI函数表是完全一样的C只是做了一层语法糖包装。我建议所有新项目都用C风格。原因不只是语法好看更重要的是C环境下比较容易和现代C代码混用。比如你可以在一个.cpp文件里写C风格JNI代码同时使用STL容器、智能指针、模板这些现代C特性整体工程体验好很多。在Clion里配置JNI环境时只要把源文件后缀改成.cpp编译器就会自动走C分支不需要任何额外开关。3.3 本地引用和全局引用的生死问题JNI引用类型还有个重要的子话题就是引用的生命周期。JNI把引用分成三类本地引用Local Reference、全局引用Global Reference、弱全局引用Weak Global Reference。本地引用是默认的。你在native方法内部通过NewStringUTF、FindClass、GetObjectClass等方式拿到的引用都属于本地引用它们在native方法返回时自动释放。但有个陷阱如果你在一个循环里大量创建本地引用比如循环一万次去拿对象的引用JVM不会像GC那样及时回收它们要等到native方法返回才一起释放这会导致内存被JNI本地引用表撑爆表现就是OutOfMemoryError。解决办法有两个。一是把操作拆到多个native方法里每个方法只处理一小段二是在循环里手动调用DeleteLocalRef释放不再使用的引用。全局引用需要用NewGlobalRef显式创建用DeleteGlobalRef显式释放。它不会被native方法返回自动回收生命周期由你控制适合在native层长期缓存一个jclass或者对象实例。弱全局引用则是全局引用的弱化版不阻止GC回收对象适合做缓存场景。这里给个实际的例子很多JNI封装代码会在JNI_OnLoad阶段缓存一些jclassstatic jclass g_StringClass; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JNIEnv *env; if (vm-GetEnv((void **)env, JNI_VERSION_1_6) ! JNI_OK) { return JNI_ERR; } jclass localRef env-FindClass(java/lang/String); g_StringClass (jclass)env-NewGlobalRef(localRef); env-DeleteLocalRef(localRef); return JNI_VERSION_1_6; }缓存jclass用全局引用而不是本地引用是因为本地引用在JNI_OnLoad返回后就会被释放下次再想用的时候jclass已经没用了。这个细节在写工具库时非常重要错过它会让你每次都去重新FindClass浪费性能不说代码也会啰嗦很多。4. 字符串在JNI里的传输方式4.1 UTF-8和UTF-16之间的搬运工Java的String内部在JDK 9以后可能是LATIN1也可能是UTF-16编码但外部接口层面JNI规范统一用UTF-16的jchar数组来代表字符串内容。native层如果要用C风格字符串需要先把Java字符串转成Modified UTF-8字节数组。JNI提供了两组主要函数方向C风格API说明从Java字符串到C字符串GetStringUTFChars / ReleaseStringUTFChars返回Modified UTF-8字节指针从Java字符串到Unicode数组GetStringChars / ReleaseStringChars返回jchar数组指针从C字符串到Java字符串NewStringUTF用Modified UTF-8创建jstring从jchar数组到Java字符串NewString用UTF-16 jchar数组创建jstring这里有一个非常常见的坑Modified UTF-8不是标准UTF-8。标准UTF-8对4字节以上的字符用4字节编码Modified UTF-8却把4字节字符拆成两个3字节的代理对编码。比如U1F600这个emoji字符在标准UTF-8里编码是F0 9F 98 804字节在Modified UTF-8里却编码成ED A0 BD ED B8 806字节。JNI的NewStringUTF只认Modified UTF-8如果你用标准UTF-8字符串去创建jstring遇到非BMP字符会得到错误的结果。所以工程上的建议很简单尽量不要把JNI字符串当成编码转换器来用。如果你要在Java和C之间传大段文本最好直接传byte数组或者使用native buffer绕开字符串编码转换的坑。如果一定要用jstring传文本记住JNI的UTF函数只适合处理ASCII为主的内容复杂的Unicode文本建议走byte数组加你自己约定的编码方式。4.2 GetStringUTFChars返回的是副本还是指针官方文档的解释是JVM可以选择返回一个指针指向字符串内部数组也可以选择复制一份给你。无论哪种方式你都必须调用ReleaseStringUTFChars否则可能出现内存泄漏或者GC无法移动对象的问题。在HotSpot VM上GetStringChars的典型实现是复制一份字符串内存出来copying模式因为JVM需要保证native层拿到的是连续内存。如果你调用GetStringUTFCharsJVM会先把Java内部的UTF-16序列转换成UTF-8再复制一份给你。这个过程有两次内存分配和两次拷贝性能开销不低。所以对于高频调用的native方法尽量避免对字符串做转换可以考虑直接传byte[]或直接传一个实现了共享接口的Java对象。我写过一个图像处理库一开始接口设计是用jstring传文件路径后来改成传byte数组性能提升了将近30%。字符串转换的开销在单次调用里不明显但在循环调用里会被放大。4.3 手动释放与安全编码建议编码层面的最佳实践jstring jstr ...; const char *utf env-GetStringUTFChars(jstr, NULL); if (utf NULL) { // 内存不足JVM可能抛出OutOfMemoryError return NULL; } // 使用utf env-ReleaseStringUTFChars(jstr, utf);注意GetStringUTFChars可能返回NULL这是JVM内存分配失败的信号必须做检查。很多初学者的代码忽略了这个检查一旦内存紧张后面直接崩溃都不知道怎么回事。另一个常见问题是申请了C的存储空间来存JNI返回的字符串用完忘记释放。例如char *buf strdup(utf); // std::strdup 或 _strdupstrdup分配的内存在Windows和Linux上都需要free但很多人看到返回值直接赋值给std::string就以为没事了结果就是内存泄漏。实用的做法是尽量用std::string去管理C字符串的生命周期让RAII机制帮你兜底std::string str(env-GetStringUTFChars(jstr, NULL)); env-ReleaseStringUTFChars(jstr, utf);先拿到C字符串立刻构造std::string然后马上Release。这样就算后面规模再大内存管理责任也在C对象身上不会裸奔。5. 数组处理Java数组与native容器的桥梁5.1 基本类型数组的访问模式基本类型数组是JNI里性能最友好的类型因为它的内存布局在绝大多数JVM实现里就是连续的区域。JNI提供一组函数族GetIntArrayElements / ReleaseIntArrayElementsGetBooleanArrayElements / ReleaseBooleanArrayElementsGetByteArrayElements / ReleaseByteArrayElementsGetShortArrayElements / ReleaseShortArrayElementsGetLongArrayElements / ReleaseLongArrayElementsGetFloatArrayElements / ReleaseFloatArrayElementsGetDoubleArrayElements / ReleaseDoubleArrayElementsGetCharArrayElements / ReleaseCharArrayElements调用模式和字符串类似先用Get系列拿指针用完之后Release。第三个参数isCopy可以传出当前模式是否是复制模式但通常我们用NULL忽略它。对于只读不写的场景Release时的mode传入JNI_ABORT可以避免把内存内容同步回Java数组。JNI_ABORT的含义是我修改过这个缓冲区但我不需要让修改生效在copying模式下能省掉一次拷贝。这里有个性能优化技巧如果native层只是读取数组求和、分析不想写回去最后一个参数用JNI_ABORT能明显减少缓冲区的写回成本如果你确实修改了数组内容并且希望Java层看到用0表示同步回并释放如果你修改了内容但不希望同步那也是JNI_ABORT。注意JNI_COMMIT模式表示同步但不释放日常使用中很少用到。jint *elems env-GetIntArrayElements(arr, NULL); int sum 0; for (int i 0; i len; i) { sum elems[i]; } env-ReleaseIntArrayElements(arr, elems, JNI_ABORT);这段代码里elems只是一个原始缓冲区修改它不会直接反映到Java数组上必须等Release时把数据拷回去才能生效。所以如果你在native层改了元素却忘了ReleaseJava层看到的数组完全没有变动这在排查问题时很难发现一定要保持配对意识Get必须配ReleaseNew必须配Delete。5.2 GetArrayLength与数组元素个数还是字节数GetArrayLength返回的是数组的元素个数不是字节数。这在很多统计代码里容易混淆特别是在处理byte[]数组时jsize len env-GetArrayLength(jbytes);如果你拿len当字节数恰好byte元素占1字节结果碰巧是对的但换成jintArraylen就变成元素个数你如果拿它当字节数访问缓冲区就会越界。这是一个很隐蔽的错误类型尤其是在现有代码基础上扩展时。数组越界在JNI层不会像Java层那样抛ArrayIndexOutOfBoundsException它是纯粹的未定义行为可能崩溃、可能数据错乱、可能在某些时候正常运行然后在某个不相关的调用里爆炸。我强烈建议在自己写的JNI辅助函数里对数组长度参数做一次显式断言或边界检查if (idx 0 || idx env-GetArrayLength(arr)) { return -1; // 或抛出Java异常 }尤其在做图像处理时Java层传过来的宽高、步长、长度这些参数native层一定要做校验。native层是信任边界你永远不知道上层会不会传一个负数过来。5.3 对象数组jobjectArray的遍历与创建对象数组在JNI里走的是另一套API。它的元素类型是jobject所以你不能直接拿指针去访问必须逐元素调用GetObjectArrayElement和SetObjectArrayElement。jobjectArray arr ...; jsize len env-GetArrayLength(arr); for (int i 0; i len; i) { jobject elem env-GetObjectArrayElement(arr, i); // 处理elem env-DeleteLocalRef(elem); }这里必须注意DeleteLocalRef。在遍历大对象数组时如果每次GetObjectArrayElement都产生一个本地引用且不及时释放本地引用表会被撑爆。在HotSpot VM中一个native方法内部的本地引用表空间有限超过上限会抛OutOfMemoryError。创建对象数组也有自己的函数jclass strClass env-FindClass(java/lang/String); jobjectArray arr env-NewObjectArray(10, strClass, NULL);第三个参数是初始值NULL表示数组元素全部为null。如果你需要创建String数组并给元素赋值可以把初始值传一个jstring进去或者创建后逐个SetObjectArrayElement。5.4 DirectByteBuffer另一种绕过数组拷贝的方案当JNI需要频繁传递大批量二进制数据时GetByteArrayElements的拷贝开销会让人很难受。这时候可以考虑使用ByteBuffer.allocateDirect()创建的DirectByteBuffer。DirectByteBuffer在JVM里是一块独立于堆外的内存区域JVM不负责GC它所以native层可以直接拿到它的地址不需要通过JNI的Get/Release机制。相关API是GetDirectBufferAddress和GetDirectBufferCapacityvoid *addr env-GetDirectBufferAddress(buf); jlong cap env-GetDirectBufferCapacity(buf);拿到addr之后就可以直接当指针用。这种方式几乎没有调用开销非常适合视频帧、音频流、大文件分块处理这类场景。但DirectByteBuffer也有代价堆外内存不受GC管理你需要自己负责分配和释放否则容易堆积堆外内存导致进程被系统杀掉。具体的做法一般是在Java层用一个ByteBuffer的包装对象通过Cleaner或者显式调用free来管理生命周期。工程经验是数据量小用byte[]数组简单直接数据量大且需要频繁跨层传递时用DirectByteBuffer性能收益非常明显。6. JNI类型转换中容易踩的隐藏陷阱6.1 jsize和size_t混用导致的大数据错误GetArrayLength返回的类型是jsize也就是jint的typedef通常是32位有符号整数。如果你用size_t去接收并当作数组索引在现代64位环境上没问题但在Windows上如果数组长度超过2^31-1基本不可能或者你把jsize和C容器的size_t做比较会触发符号比较的警告。真正的风险不在于长度超大而在于类型混用的代码容易让别人看不懂。另一个容易忽略的点JNI返回jsize之后对返回值的负数情况要敏感。如果你从C层调用Java方法返回一个char[]结果Java端返回了一个nullGetArrayLength不会为null数组返回0而是会崩溃。崩溃之前没有任何提示。所以拿数组之前先判断数组引用是否为空if (arr NULL) { return; // 或抛异常 }这在所有引用类型上都适用JNI函数里引用类型的NULL都是合法的返回值代表Java层传进来了null。你不处理就往下走十有八九会空指针崩溃。6.2 C的bool和JNI的jboolean不是一回事C里bool占1字节值为false或trueJNI的jboolean也是1字节但语义上是JNI_FALSE0和JNI_TRUE1。看起来很像但如果你直接把一个C bool数组当成jboolean数组返回给Java虽然大部分编译器abi相同没有实际问题但严格来说不规范的实现可能踩到。更实际的问题出现在结构体对齐上。如果你自己定义了一个结构体里面既有bool又有int在C里的内存布局和Java侧读到的字段偏移极可能不一致因为它受编译器对齐影响。如果Java层的native方法接收的是一个long表示的结构体地址你直接强转成C结构体指针来解析一旦两边编译器对齐规则不同解析就是错的。我的建议是跨边界传递自定义结构体时不要传C对象本身而是传扁平化的字节数组或者把关键字段拆成若干个原始类型参数。字段多了以后用一个打包结构体配合#pragma pack(1)可以缓解对齐问题但最好还是保持数据结构简单。6.3 方法签名符号的格式每个JNI函数的名字里都嵌着参数签名比如JNIEXPORT void JNICALL Java_com_example_NativeLib_nativeMethod(JNIEnv *env, jobject thiz, jint value);对应的Java声明是public native void nativeMethod(int value);JVM在链接时靠方法名里的签名来判断是否匹配一旦Java方法签名和native函数参数不匹配直接链接失败。对于返回类型是int的native方法函数名里要不要写签名不写只有参数类型会进入到native函数名中返回值不会在名字里体现。所以一个Java声明为public native long foo(int a);的方法对应的native函数名是Java_包名_类名_foo(JNIEnv*, jobject, jint)返回值是jlong但你没法从函数名看出返回值类型JVM只能靠方法签名表来匹配。如果你Java方法签名和native函数写的不一致链接阶段就会报错而不是等到实际调用。这也是为什么网上很多链接时找不到方法的求助帖最后查下来往往不是动态库没加载而是参数类型写错了。6.4 动态注册vs静态注册的取舍静态注册依赖刚才那种长函数名规则只要名字拼对JVM就能自动找到。缺点是函数名冗长、类名或包名一变就得全部改名。动态注册则是在JNI_OnLoad里手动注册函数指针和签名不需要遵守长函数名规则函数名可以随意起。用动态注册还有性能上的优势因为JVM不用做字符串匹配查找。static const JNINativeMethod methods[] { {nativeMethod, (I)V, (void *)nativeMethodImpl}, }; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JNIEnv *env; if (vm-GetEnv((void **)env, JNI_VERSION_1_6) ! JNI_OK) return JNI_ERR; jclass cls env-FindClass(com/example/NativeLib); env-RegisterNatives(cls, methods, sizeof(methods) / sizeof(methods[0])); env-DeleteLocalRef(cls); return JNI_VERSION_1_6; }签名串(I)V表示参数是int、返回void这个签名规则在动态注册里必须写准确。它是最容易写错的地方多一个空格都不行。常见的签名对照表最好常备Java方法JNI签名串void foo(int a)(I)Vint bar(String s)(Ljava/lang/String;)Ilong baz(int a, int b)(II)Jboolean test(double d)(D)Z动态注册的最大好处之一是编译时就能通过函数指针类型检查发现参数类型不一致而不是等运行时链接报错。在Clion里写JNI代码时因为IDE对C类型检查很严格用动态注册能借助静态分析提前揪出一批问题。7. Clion里配置JNI环境的实操记录7.1 找到JDK头文件和jni.h配置JNI环境第一件事是让编译器能找到jni.h和jni_md.h。在Windows上依赖的目录通常包括JDK安装目录\includeJDK安装目录\include\win32在Linux上是JDK安装目录/includeJDK安装目录/include/linuxClion的CMakeLists.txt里通过引入Java包路径来做find_package(JAVA COMPONENTS Runtime REQUIRED) include_directories( ${JAVA_INCLUDE_PATH} ${JAVA_INCLUDE_PATH2} )如果你用的JDK是11以上的版本JAVA_HOME环境变量指向的是JDK根目录而不是JRE目录。某些IDEA内部带了JDK但系统环境变量里没设JAVA_HOMEClion的find_package可能找不到这种情况下直接在CMakeLists里硬编码include路径也行只要能编译过路径写死完全没关系看你自己习惯。7.2 Clion里跑通第一个native方法一个最小的可运行项目只需要三步第一步Java侧定义一个含native方法的类并加载动态库public class NativeLib { static { System.loadLibrary(native-lib); } public static native int add(int a, int b); }第二步用javac编译这个类再用javac -h生成头文件或者干脆手写一个对应的C函数名。如果你使用JNI官方头文件生成工具其实出错率更低但现在动态注册写起来也不复杂我更推荐动态注册省去一堆自动生成的头文件。第三步CMakeLists里把cpp编译成动态库add_library(native-lib SHARED native_lib.cpp)然后运行Java类System.loadLibrary会在java.library.path里找动态库Clion生成的可执行文件目录下如果没找到可以手动在运行配置里指定-Djava.library.path/path/to/build/dir很多人在Windows上遇到UnsatisfiedLinkError不是编译问题是动态库名字不对。Windows上动态库必须是native-lib.dllLinux上是libnative-lib.so如果生成的名字带了其它前缀System.loadLibrary(native-lib)会找不到。7.3 调试JNI代码的实用手段JNI代码一旦写错最常见的表现就是程序直接崩溃没有Java异常栈很难定位。我的经验是给native方法入口加日志用__android_log_printAndroid或者printf桌面把入参和返回值先在调试阶段打出来。另一个有效手段是学会看崩溃日志里的native stack trace通常在崩溃dump里会显示native函数的符号名配合addr2line或者Clion的调试器就能定位到具体代码行。Clion的调试器对JNI的支持其实不错只要CPU断在native代码里你就能看到C变量值。比较麻烦的是JVM自带的线程断点经常被打断建议调试时在native方法入口处直接下断点然后把Java线程挂起让调试器只在当前线程内单步走。7.4 一个mini示例用JNI完成数组求和用一个完整的小例子串一下前面所有内容Java端public class ArraySum { static { System.loadLibrary(array_sum); } public static native long sum(int[] data); public static void main(String[] args) { int[] data {1, 2, 3, 4, 5}; System.out.println(sum(data)); } }C端#include jni.h extern C JNIEXPORT jlong JNICALL Java_ArraySum_sum(JNIEnv *env, jclass clazz, jintArray data) { jsize len env-GetArrayLength(data); if (len 0) return 0; jint *elems env-GetIntArrayElements(data, NULL); if (elems NULL) return 0; jlong total 0; for (jsize i 0; i len; i) { total elems[i]; } env-ReleaseIntArrayElements(data, elems, JNI_ABORT); return total; }这里要注意几个细节。一是jlong是64位累加int数组肯定不会溢出用long接收更安全。二是Release时用了JNI_ABORT因为不需要把修改同步回Java数组。三是函数入口处判断了elems为NULL虽然正常情况几乎不会发生但防御性编程在JNI层尤其值得。四是即使data是空数组GetArrayLength返回0不进入循环也要正常返回0。无论静态注册还是动态注册这段逻辑本身是统一的。初学者建议先用静态注册跑通后续做库封装再迁移到动态注册。8. 从类型系统延伸出去JNI性能边界与后续进阶方向类型系统是整个JNI世界的骨架但掌握它只解决了数据能传过去的问题。真正到了性能敏感场景还要考虑JNI调用本身的开销、引用类型传递的成本、以及如何减少Java与native之间的数据拷贝。几个可以直接落地的优化思路能用jint、jdouble这类原始类型传递的数据就不要封装成对象原始类型的传递开销极低。大批量数据优先用数组或者DirectByteBuffer避免一个字段一个字段地拼接字符串。尽量避免频繁的GetStringUTFChars / ReleaseStringUTFChars。如果get和release之间只是读取长度可以考虑用GetStringLength先拿到长度再按需获取子串。JNI临界区Critical Section和GetPrimitiveArrayCritical可以在极短时间内让JVM禁止GC从而拿到更稳定的指针。但这个API的使用限制很多临界区内不能回调Java方法容易把自己锁死新手不要轻易上。在Android平台上有专门的NativeAllocationRegistry管理native内存生命周期如果你在Android里用JNI建议去熟悉它。还有一块被很多人忽视的内容是JNI和C异常机制的交互。C的throw不能跨越JNI边界你需要在外围函数里catch住所有异常并转成JNI返回值或者抛Java异常。JNI规范要求native方法里绝对不能有C异常未捕获地穿过JNI边界否则程序直接崩溃。工程上通常这样处理native方法入口包一层try-catch-all在catch块里通过抛出Java异常的方式上报错误然后返回安全默认值。int safeCall() { try { return doWork(); } catch (const std::exception e) { jclass exClass env-FindClass(java/lang/RuntimeException); env-ThrowNew(exClass, e.what()); return 0; } }写JNI时间久了你会发现它真正考验的不是Java也不是C本身而是你同时管理两种语言运行时的能力一边要保证Java层的类型语义不被破坏一边要照顾好C的内存和生命周期。类型系统是第一层认知框架这层框架打牢了后面再看JNI_OnLoad、引用管理、线程模型、跨线程回调、JavaVM指针这些内容都会顺畅得多。下一篇我会接着梳理JNI的引用管理细节和常见崩溃案例把那些运行时莫名崩溃的场景逐个拆开来看。