數(shù)據(jù)類型全解析：從jboolean到j(luò)long的常見(jiàn)坑)
1. 從JNI的類型系統(tǒng)說(shuō)起為什么第一課必須講這個(gè)JNIJava Native Interface是Java生態(tài)里一個(gè)特別的存在。它讓Java代碼可以直接調(diào)用C/C寫(xiě)的動(dòng)態(tài)庫(kù)反過(guò)來(lái)C/C代碼也能調(diào)用Java層的代碼。十年前我做Android系統(tǒng)定制時(shí)第一次真正用上JNI后來(lái)轉(zhuǎn)做后端中間件在Java服務(wù)里用JNA/JNI調(diào)一些底層算法庫(kù)可以說(shuō)JNI貫穿了我整個(gè)職業(yè)生涯的很多關(guān)鍵階段。很多初學(xué)者一上來(lái)就急著寫(xiě)代碼、調(diào)接口結(jié)果被jstring、jobjectArray、jfieldID這些東西搞得一頭霧水。其實(shí)JNI的所有困難根源都在類型系統(tǒng)——你用什么類型接收J(rèn)ava層傳過(guò)來(lái)的參數(shù)、用什么類型把數(shù)據(jù)傳回Java層直接決定了后面一切調(diào)用的成敗。這篇內(nèi)容我會(huì)把JNI類型系統(tǒng)的全貌講清楚重點(diǎn)聚焦基礎(chǔ)數(shù)據(jù)類型這一塊。內(nèi)容偏向?qū)崙?zhàn)為什么JNI要定義一套自己的typedef這些類型和C/C原生類型之間怎么換算在CLion里搭環(huán)境時(shí)要注意哪些坑以及我在實(shí)際項(xiàng)目中踩過(guò)的那些看起來(lái)能編譯、跑起來(lái)就崩的問(wèn)題。如果你是下面這幾種情況這篇文章值得讀完正在學(xué)JNI剛開(kāi)始接觸javac -h和C/C代碼生成對(duì)jni.h里的類型定義感到陌生在維護(hù)老項(xiàng)目遇到了UnsatisfiedLinkError、JNI參數(shù)錯(cuò)位或者native層讀到亂碼的問(wèn)題想在CLion里配置一套完整的JNI開(kāi)發(fā)調(diào)試環(huán)境不想再用命令行手動(dòng)javac/編譯的笨辦法。JNI類型系統(tǒng)說(shuō)白了就兩件事一是Java和C/C之間的數(shù)據(jù)怎么“翻譯”二是翻譯過(guò)程中誰(shuí)能保證字節(jié)數(shù)、符號(hào)、內(nèi)存布局完全不出錯(cuò)?；A(chǔ)數(shù)據(jù)類型是整個(gè)JNI類型系統(tǒng)的地基地基不牢后面說(shuō)什么jobject回調(diào)、局部引用管理都是在空中樓閣。2. 基礎(chǔ)數(shù)據(jù)類型全解析jboolean到j(luò)double的每一個(gè)坑2.1 JNI為什么不用C語(yǔ)言的int、long先回答一個(gè)非常自然的疑問(wèn)Java層有int、long、booleanC語(yǔ)言也有int、long為什么JNI不能直接用我在給團(tuán)隊(duì)做內(nèi)部培訓(xùn)時(shí)經(jīng)常舉這個(gè)例子C標(biāo)準(zhǔn)里只規(guī)定了int最短16位、long最長(zhǎng)不超過(guò)double但具體是多少位由編譯器和平臺(tái)決定。在Windows上是LLP64模型long是32位在Linux x86_64上是LP64模型long是64位。Java的int永遠(yuǎn)32位、long永遠(yuǎn)64位這是語(yǔ)言規(guī)范寫(xiě)死的事情。如果JNI直接映射同一個(gè)C函數(shù)在Windows下編譯和Linux下編譯對(duì)于long類型參數(shù)的二進(jìn)制布局可能完全不同。老練的C程序員肯定會(huì)說(shuō)用int32_t、int64_t這些stdint.h里的定長(zhǎng)類型不就行了JNI思路一致但它比這個(gè)更進(jìn)一步它直接在jni.h頭文件里把類型全部typedef出來(lái)形成一套Java世界和原生世界之間的“契約語(yǔ)言”。這就是JNI類型系統(tǒng)存在的核心價(jià)值用一套固定的、平臺(tái)無(wú)關(guān)的typedef屏蔽Java與C/C之間的類型差異。你看jni.h時(shí)會(huì)發(fā)現(xiàn)所有平臺(tái)的JNI實(shí)現(xiàn)都約定同一個(gè)頭文件、同一套類型名保證Java代碼“一處編寫(xiě)、處處原生”。2.2 八大基礎(chǔ)數(shù)據(jù)類型的完整映射表JNI的基礎(chǔ)類型定義在jni.h的頭部核心映射我整理成一張表Java類型JNI的C/C類型實(shí)際C語(yǔ)言底層定義占用字節(jié)數(shù)說(shuō)明booleanjbooleanunsigned char1字節(jié)只約定0和1bytejbytesigned char1字節(jié)有符號(hào)8位charjcharunsigned short2字節(jié)Java的char是UTF-16編碼單元不是ASCIIshortjshortshort2字節(jié)有符號(hào)16位intjintint4字節(jié)固定32位等價(jià)int32_tlongjlonglong long8字節(jié)固定64位等價(jià)int64_tfloatjfloatfloat4字節(jié)IEEE 754單精度doublejdoubledouble8字節(jié)IEEE 754雙精度voidvoidvoid—僅用于方法返回類型這張表里最值得警惕的就是jboolean和jchar它們也是我見(jiàn)到的錯(cuò)誤率最高的兩個(gè)類型。jboolean底層是unsigned char而不是C里的bool。Java層的boolean語(yǔ)義上只有true/falsenative層用unsigned char只是為了嚴(yán)格保證1個(gè)字節(jié)的存儲(chǔ)尺寸。C的bool標(biāo)準(zhǔn)雖然也通常是1字節(jié)但C標(biāo)準(zhǔn)的bool和這畢竟不是同一個(gè)東西所以JNI規(guī)范里特意定義了jboolean。實(shí)際調(diào)用時(shí)如果Java傳了true你收到的是1傳false收到0。但你在native層用jboolean接收后用if (value JNI_TRUE)判斷這里的JNI_TRUE定義就是常量1。jchar是unsigned short2字節(jié)無(wú)符號(hào)。這里有個(gè)隱蔽的坑C/C里的char幾乎都是1字節(jié)很多新手在C/C側(cè)把JNI返回的jchar直接強(qiáng)轉(zhuǎn)為char結(jié)果遇到中文或者4字節(jié)以上的Unicode碼點(diǎn)時(shí)數(shù)據(jù)直接截?cái)?。Java的char是UTF-16 code unit你接到的jchar可能是代理對(duì)surrogate pair中的一半。如果你要做字符串處理應(yīng)該走GetStringChars或者GetStringUTFChars而不是自己逐個(gè)轉(zhuǎn)char。jlong的坑更偏向“習(xí)慣”在Windows上的C代碼里long是32位但JNI的jlong明確是long long。如果你寫(xiě)成long接收jlong編譯能過(guò)但高32位直接被丟掉返回的數(shù)據(jù)完全錯(cuò)亂。我見(jiàn)過(guò)不止一個(gè)同事在這種地方花了一整天才排查出來(lái)。2.3 類型映射背后的數(shù)字講究為什么正好是這些字節(jié)長(zhǎng)度有人會(huì)問(wèn)Java的byte如果映射成signed char為什么不用int8_tJava的int為什么不用int32_t答案不是JNI老而是JNI要考慮C89/C99的老編譯器兼容性。當(dāng)年JNI規(guī)范定下來(lái)的時(shí)候C99的stdint.h還沒(méi)有被廣泛支持JNI在jni.h里自己用typedef定義了一套類型保證哪怕在非常老舊的C編譯環(huán)境下也能編譯通過(guò)。不過(guò)現(xiàn)代的jni.h里也大量配合使用stdint.h里的類型typedef unsigned char jboolean; typedef unsigned short jchar; typedef short jshort; typedef int jint; // 在特定的JNI實(shí)現(xiàn)里jlong也可能是 // typedef long long jlong;你去看JDK自帶的jni.h有的版本里jint就是intjlong就是long long但這都無(wú)所謂因?yàn)镴NI規(guī)范保證的是“字節(jié)寬度固定、符號(hào)固定”。真正重要的是你在自己的C/C代碼里用等寬類型去接// 推薦做法使用定長(zhǎng)類型 int32_t myJavaInt jint_value; int64_t myJavaLong jlong_value;這種寫(xiě)法的好處在于你的native代碼邏輯是自文檔化的明示了數(shù)據(jù)寬度未來(lái)跨平臺(tái)移植時(shí)不會(huì)因?yàn)閕nt、long在不同平臺(tái)上的默認(rèn)寬度不一致而出問(wèn)題。2.4 為什么沒(méi)有jbyteArray的基礎(chǔ)類型對(duì)應(yīng)物JNI區(qū)分“基礎(chǔ)類型”和“引用類型”。八種基礎(chǔ)類型對(duì)應(yīng)Java的基本類型引用類型則對(duì)應(yīng)數(shù)組、String、Class、Throwable以及所有Java對(duì)象。最容易混淆的是jbyteArray、jintArray這類東西——它們不是基礎(chǔ)類型而是數(shù)組類型屬于引用類型范疇。JNI設(shè)計(jì)時(shí)給每種基礎(chǔ)類型都配了一個(gè)對(duì)應(yīng)的Array類型但不建議把它們和基礎(chǔ)類型混在一起記憶基礎(chǔ)類型對(duì)應(yīng)的JNI數(shù)組類型獲取數(shù)據(jù)的JNI函數(shù)jbooleanjbooleanArrayGetBooleanArrayElementsjbytejbyteArrayGetByteArrayElementsjcharjcharArrayGetCharArrayElementsjshortjshortArrayGetShortArrayElementsjintjintArrayGetIntArrayElementsjlongjlongArrayGetLongArrayElementsjfloatjfloatArrayGetFloatArrayElementsjdoublejdoubleArrayGetDoubleArrayElements從這里能看出JNI的一貫思路基礎(chǔ)類型是值傳遞的數(shù)組和對(duì)象是引用類型的需要JNI函數(shù)專門獲取與釋放。這篇著重講基礎(chǔ)類型但數(shù)組類型你一定會(huì)碰到尤其是byte數(shù)組在傳輸二進(jìn)制數(shù)據(jù)時(shí)幾乎避不開(kāi)。后面的章節(jié)里我會(huì)詳細(xì)展開(kāi)數(shù)組和引用類型的細(xì)節(jié)。3. JNIEnV的取值與傳值機(jī)制基礎(chǔ)數(shù)據(jù)到底怎么跨語(yǔ)言流動(dòng)3.1 基礎(chǔ)類型按值傳遞這句話怎么理解熟悉C的人都知道函數(shù)參數(shù)有兩種傳遞方式值傳遞和引用傳遞。JNI對(duì)于基礎(chǔ)類型采用的就是值傳遞。Java層調(diào)用native方法時(shí)int參數(shù)直接復(fù)制一份原始值傳到C函數(shù)棧上C函數(shù)返回jint時(shí)也直接返回值本身。這意味著native函數(shù)里對(duì)參數(shù)的修改不會(huì)影響Java層的原變量。這和Java本身的基本類型語(yǔ)義是一致的。理解這一點(diǎn)對(duì)調(diào)試很有用如果你在native層改了jint的值Java層沒(méi)變不是JNI出bug了是你對(duì)值傳遞的預(yù)期錯(cuò)了。但是有個(gè)重要的例外如果你傳入的是一個(gè)int[]數(shù)組jintArray哪怕每個(gè)元素是int整個(gè)數(shù)組在JNI層面是一個(gè)引用類型。你操作數(shù)組元素時(shí)必須通過(guò)GetIntArrayElements拿到C側(cè)指針這時(shí)候你在C側(cè)改數(shù)組元素如果調(diào)用了ReleaseIntArrayElements時(shí)用了JNI_COMMIT或0是可以把修改同步回Java數(shù)組的。所以“基礎(chǔ)類型按值傳遞”只對(duì)單個(gè)標(biāo)量成立對(duì)數(shù)組完全不成立。3.2 JNIEXPORT和JNIEXPORT的符號(hào)導(dǎo)出原理看JNI的native函數(shù)聲明會(huì)有兩個(gè)醒目的宏JNIEXPORT jint JNICALL Java_com_example_NativeLib_add(JNIEnv *env, jobject thiz, jint a, jint b);JNIEXPORT這個(gè)宏在Windows上是__declspec(dllexport)在Linux/Unix上為空或__attribute__((visibility(default)))JNICALL在Windows上是__stdcall調(diào)用約定在Linux等平臺(tái)上為空。這段宏的作用是控制函數(shù)導(dǎo)出和調(diào)用約定。Windows下DLL的符號(hào)默認(rèn)不導(dǎo)出如果沒(méi)有JNIEXPORTJava層運(yùn)行時(shí)就會(huì)報(bào)“找不到add符號(hào)”也就是UnsatisfiedLinkError。所以如果你在Windows上手動(dòng)寫(xiě)JNI函數(shù)名千萬(wàn)別漏了這兩個(gè)宏。在CMakeLists.txt里設(shè)置C_VISIBILITY_PRESET hidden時(shí)這兩個(gè)宏的意義就更重要了。從JVM的角度看動(dòng)態(tài)庫(kù)加載后JVM會(huì)通過(guò)dlsymLinux或GetProcAddressWindows查找符號(hào)。如果找不到就報(bào)錯(cuò)。符號(hào)本身還必須是extern C的否則C編譯器會(huì)做名字改編name manglingJVM按C符號(hào)去找就會(huì)撲空。這里我列一下最常見(jiàn)的三個(gè)native層找不到符號(hào)的場(chǎng)景漏了extern CWindows下漏了JNIEXPORT導(dǎo)致未導(dǎo)出用C寫(xiě)了函數(shù)重載名字被編譯器改編每個(gè)都讓你報(bào)錯(cuò)UnsatisfiedLinkError但報(bào)錯(cuò)位置和時(shí)機(jī)略有不同。實(shí)際開(kāi)發(fā)中我建議所有JNI封裝函數(shù)都按這個(gè)格式嚴(yán)格寫(xiě)全不要偷懶省宏。3.3 從Java層調(diào)用native方法時(shí)的完整數(shù)據(jù)流以最簡(jiǎn)單的add方法為例完整數(shù)據(jù)流是這樣的Java層調(diào)用NativeLib.add(3, 5)JVM根據(jù)System.loadLibrary(native)加載動(dòng)態(tài)庫(kù)把符號(hào)解析注冊(cè)到當(dāng)前進(jìn)程調(diào)用時(shí)JVM把JNIEnv指針和jobject或jclass看方法是否static壓棧再把參數(shù)按JNI類型壓棧native函數(shù)執(zhí)行拿到a3、b5算出jint返回值返回值通過(guò)JNI約定傳回Java層Java方法獲得8。整個(gè)過(guò)程中JVM不關(guān)心你native函數(shù)內(nèi)部怎么實(shí)現(xiàn)的它只關(guān)心入口符號(hào)約定是否匹配、參數(shù)棧布局是否匹配。這就是為什么類型語(yǔ)義這么重要——一旦某個(gè)參數(shù)類型對(duì)不上壓棧/出棧的字節(jié)數(shù)不一樣函數(shù)可能不立即崩潰直到下一次調(diào)用棧返回時(shí)才炸這種bug極其難查。我舉一個(gè)我真實(shí)遇到過(guò)的例子。項(xiàng)目里有人把native方法簽名里的long參數(shù)換成了int參數(shù)因?yàn)閮蛇叺拇a不是同一個(gè)人寫(xiě)的Java層傳的是longC層接的是jint。64位系統(tǒng)下long是8字節(jié)jint是4字節(jié)。JVM壓棧了8字節(jié)C函數(shù)按4字節(jié)解析局部變量后面的參數(shù)全部錯(cuò)位。最終表現(xiàn)是函數(shù)能進(jìn)能出但第二個(gè)參數(shù)永遠(yuǎn)是個(gè)垃圾值而且概率性崩潰。用valgrind一跑才發(fā)現(xiàn)棧被寫(xiě)壞了。所以Java和native層的類型簽名必須嚴(yán)格一致這是JNI第一條軍規(guī)。類型映射表不是參考建議是法律條文。4. CLion中配置JNI開(kāi)發(fā)環(huán)境從零到一跑通第一個(gè)example4.1 為什么推薦CLion作為JNI開(kāi)發(fā)IDECLion對(duì)JNI開(kāi)發(fā)的支持在當(dāng)前的IDE陣營(yíng)里算是比較友好的一檔。一方面JetBrains家的IDEA和CLion可以聯(lián)動(dòng)端到端調(diào)試Java調(diào)用native方法的場(chǎng)景可以直接在CLion的調(diào)試器里斷點(diǎn)另一方面CLion原生支持CMake而JNI的C/C側(cè)正好絕大多數(shù)都是用CMake構(gòu)建的。相比Eclipse CDT那套老掉牙的組合CLion的環(huán)境配置要順滑很多。我在開(kāi)篇提到的“在CLion中配置jni環(huán)境”這個(gè)熱搜詞也確實(shí)反映了很多人的剛需。下面我給的配置流程基于Linux/macOS環(huán)境Windows步驟基本一致差異主要是JAVA_HOME路徑和動(dòng)態(tài)庫(kù)后綴名Windows是.dllmacOS是.jnilib或.dylibLinux是.so。4.2 第一步準(zhǔn)備JDK和CLion先用java -version確認(rèn)你的JDK版本。JNI開(kāi)發(fā)建議用JDK 8或更高的版本。然后記下你的JAVA_HOME路徑# Linux/macOS echo $JAVA_HOME # 如果沒(méi)有設(shè)置先找到j(luò)ava所在路徑 which java # 然后推斷JAVA_HOME一般是 /usr/lib/jvm/java-11-openjdk-amd64 之類一般CMakeLists.txt里需要這個(gè)路徑來(lái)引入jni.h和jni_md.h。4.3 第二步創(chuàng)建Java端代碼并生成頭文件CLion雖然主打C/C但它也能混編。我習(xí)慣把Java文件放在項(xiàng)目的java_src目錄下這樣便于管理。新建一個(gè)Java類public class NativeLib { static { System.loadLibrary(native); } public native int add(int a, int b); public native String getMessage(); public static void main(String[] args) { NativeLib lib new NativeLib(); System.out.println(3 5 lib.add(3, 5)); System.out.println(lib.getMessage()); } }編譯后生成頭文件cd java_src javac NativeLib.java javac -h . NativeLib.java如果用的是JDK 8請(qǐng)用javac -h不是javac -jniJDK 8以前用的是javah命令JDK 8雖然還保留javah但建議直接用javac -h。成功后會(huì)生成一個(gè)NativeLib.h文件里面就是JNIEXPORT聲明的函數(shù)原型。/* DO NOT EDIT THIS FILE - it is machine generated */ #include jni.h #ifndef _Included_NativeLib #define _Included_NativeLib #ifdef __cplusplus extern C { #endif JNIEXPORT jint JNICALL Java_NativeLib_add (JNIEnv *, jobject, jint, jint); JNIEXPORT jstring JNICALL Java_NativeLib_getMessage (JNIEnv *, jobject); #ifdef __cplusplus } #endif #endif請(qǐng)仔細(xì)看這個(gè)頭文件所有函數(shù)都包裹在extern C里這就是為什么我們自己的.cpp實(shí)現(xiàn)文件也要包含這個(gè)頭文件以確保函數(shù)定義時(shí)也是C鏈接。4.4 第三步CMakeLists.txt配置在項(xiàng)目根目錄創(chuàng)建CMakeLists.txt重點(diǎn)是將jni.h所在的include目錄和平臺(tái)相關(guān)的目錄暴露給編譯器。cmake_minimum_required(VERSION 3.20) project(jni_native LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) # JDK 路徑按你的實(shí)際JAVA_HOME修改 set(JAVA_HOME /usr/lib/jvm/java-11-openjdk-amd64) include_directories( ${JAVA_HOME}/include ${JAVA_HOME}/include/linux # macOS 下是 ${JAVA_HOME}/include/darwin ) add_library(native SHARED native_lib.cpp ) # macOS 需要額外設(shè)置安裝名 if(APPLE) set_target_properties(native PROPERTIES INSTALL_RPATH loader_path BUILD_WITH_INSTALL_RPATH TRUE ) endif()注意Windows上的include目錄是JAVA_HOME/include和JAVA_HOME/include/win32Linux是include/linuxmacOS是include/darwin。很多人在這一步漏了平臺(tái)子目錄導(dǎo)致找不到j(luò)ni_md.h。4.5 第四步C側(cè)實(shí)現(xiàn)實(shí)現(xiàn)文件里我們的函數(shù)簽名要和生成的頭文件完全一致。這里我用一個(gè)關(guān)鍵點(diǎn)示范jstring和jint混合處理。#include jni.h #include string #include NativeLib.h extern C { JNIEXPORT jint JNICALL Java_NativeLib_add(JNIEnv *env, jobject thiz, jint a, jint b) { return a b; } JNIEXPORT jstring JNICALL Java_NativeLib_getMessage(JNIEnv *env, jobject thiz) { std::string msg Hello from C JNI; return env-NewStringUTF(msg.c_str()); } }這個(gè)函數(shù)里出現(xiàn)了jstring和NewStringUTF這屬于引用類型和JNI函數(shù)調(diào)用的范疇了但先記住一點(diǎn)jstring你不能當(dāng)成普通字符串返回必須通過(guò)NewStringUTF或NewString創(chuàng)建。后面章節(jié)講引用類型時(shí)我會(huì)重點(diǎn)展開(kāi)。4.6 第五步編譯并運(yùn)行在CLion里直接點(diǎn)擊Build生成libnative.so或libnative.dylib、native.dll。然后把生成的動(dòng)態(tài)庫(kù)放到Java代碼能加載到的地方運(yùn)行NativeLib。運(yùn)行Java主類的方式可以直接用CLion的Run Configuration搭配IDEA也可以命令行java -Djava.library.path./build/lib NativeLibIdea自身也可以在VM options里配置-Djava.library.path指向你的動(dòng)態(tài)庫(kù)所在目錄。第一次跑通這個(gè)流程你基本就對(duì)JNI的開(kāi)發(fā)閉環(huán)有了整體感知Java定義native方法javac -h生成頭文件C實(shí)現(xiàn)編譯成一個(gè)動(dòng)態(tài)庫(kù)Java程序加載并調(diào)用。后面所有復(fù)雜功能包括字符串、數(shù)組、Java對(duì)象回調(diào)都是在這條流水線上擴(kuò)展出來(lái)的。5. 基礎(chǔ)數(shù)據(jù)類型實(shí)操案例從int到j(luò)charArray的完整演示5.1 一個(gè)綜合示例Java層傳多種基礎(chǔ)類型前面只演示了add函數(shù)這里我多給一個(gè)綜合一點(diǎn)的例子涉及所有基礎(chǔ)類型。Java端public class TypeDemo { static { System.loadLibrary(typedemo); } public native void passAllTypes(boolean boolVal, byte byteVal, char charVal, short shortVal, int intVal, long longVal, float floatVal, double doubleVal); public native long testLongReturn(); }生成頭文件后C側(cè)實(shí)現(xiàn)extern C JNIEXPORT void JNICALL Java_TypeDemo_passAllTypes(JNIEnv *env, jobject thiz, jboolean boolVal, jbyte byteVal, jchar charVal, jshort shortVal, jint intVal, jlong longVal, jfloat floatVal, jdouble doubleVal) { // 打印時(shí)全部顯式轉(zhuǎn)成可打印的類型 char cStr[64]; snprintf(cStr, sizeof(cStr), char code point: %u, static_castunsigned int(charVal)); printf(boolVal%d, byteVal%d, shortVal%d, intVal%d, longVal%lld\n, static_castint(boolVal), static_castint(byteVal), static_castint(shortVal), static_castint(intVal), static_castlong long(longVal)); printf(floatVal%.2f, doubleVal%.2f, %s\n, static_castdouble(floatVal), doubleVal, cStr); }這里的關(guān)鍵點(diǎn)在printf里。jboolean是unsigned char不能直接匹配%dfloat傳給printf的%f之前必須轉(zhuǎn)成double。如果你偷懶直接把jfloat當(dāng)double傳給printf在64位平臺(tái)上可能會(huì)因?yàn)閰?shù)類型不匹配讀到垃圾值。C語(yǔ)言的printf是類型不安全的這里我要再?gòu)?qiáng)調(diào)一次JNI函數(shù)內(nèi)部不是避風(fēng)港C/C的類型規(guī)則照常生效。5.2 jcharArray入?yún)⒌奶幚硎痉秱鲉蝹€(gè)jchar很簡(jiǎn)單但是一旦遇到char數(shù)組事情就不一樣了?？聪旅孢@個(gè)例子Java層傳一個(gè)char[]過(guò)來(lái)。public native int calcCharArrayLength(char[] data);C側(cè)實(shí)現(xiàn)extern C JNIEXPORT jint JNICALL Java_TypeDemo_calcCharArrayLength(JNIEnv *env, jobject thiz, jcharArray array) { if (array nullptr) { return 0; } jsize len env-GetArrayLength(array); jchar *elements env-GetCharArrayElements(array, nullptr); if (elements nullptr) { return 0; } // 這里臨時(shí)用elements做一些只讀操作 jsize count 0; for (jsize i 0; i len; i) { if (elements[i] ! 0) { count; } } env-ReleaseCharArrayElements(array, elements, JNI_ABORT); return count; }GetCharArrayElements拿回來(lái)的是底層緩沖區(qū)的指針這個(gè)指針可能指向Java堆的拷貝也可能直接指向原始數(shù)組取決于JVM實(shí)現(xiàn)和調(diào)用場(chǎng)景。用完之后必須Release否則會(huì)內(nèi)存泄漏。第三個(gè)參數(shù)mode有三種取值0將修改拷貝回Java數(shù)組并釋放原生數(shù)組相當(dāng)于“寫(xiě)回”JNI_COMMIT將修改拷貝回Java數(shù)組但不釋放原生數(shù)組JNI_ABORT不拷貝回Java數(shù)組直接釋放原生數(shù)組小程序里很多人圖省事永遠(yuǎn)傳0但當(dāng)你修改的是從Java傳進(jìn)來(lái)的只讀數(shù)據(jù)時(shí)用JNI_ABORT性能更高避免一次無(wú)謂的拷貝回寫(xiě)。這是JNI性能優(yōu)化里最基礎(chǔ)的一課。5.3 jboolean的特異功能JNI_TRUE和JNI_FALSEJNI在jni.h里還定義了兩個(gè)常量#define JNI_FALSE 0 #define JNI_TRUE 1實(shí)際寫(xiě)代碼時(shí)請(qǐng)用這兩個(gè)常量不要直接用數(shù)字0、1。同時(shí)因?yàn)閖boolean是unsigned char不要把它和C的bool混用更不要拿它直接做某些系統(tǒng)API的bool參數(shù)。如果需要轉(zhuǎn)換顯示轉(zhuǎn)換出來(lái)bool cppBool (jboolValue JNI_TRUE);這樣避免了一個(gè)經(jīng)典異常你把jboolean直接當(dāng)作bool傳給了某個(gè)C接口C接口內(nèi)部檢查value true或者is true時(shí)如果jboolean的值是1以外的其他非零值結(jié)果就是未定義行為。6. JNI中無(wú)處不在的JNIEnv指針理解它是理解一切的鑰匙6.1 JNIEnv到底是什么JNIEnv是JNI Native Interface的核心句柄。每個(gè)native方法第一個(gè)參數(shù)都是它除非是JNI_CreateJavaVM那類特殊入口。它本質(zhì)上是一個(gè)指向線程局部數(shù)據(jù)的指針這個(gè)數(shù)據(jù)里裝著一整個(gè)函數(shù)表你調(diào)用的所有JNI函數(shù)NewStringUTF、GetArrayLength、CallIntMethod等都是這張表里的函數(shù)指針?？梢园袹NIEnv想象成一個(gè)“Java虛擬機(jī)在native層的翻譯”。你通過(guò)它向JVM查詢數(shù)組長(zhǎng)度、創(chuàng)建Java對(duì)象、拋異常、訪問(wèn)字段。沒(méi)有它JNI代碼寸步難行。C和C訪問(wèn)JNIEnv的方式有很大差別C語(yǔ)言中JNIEnv是JNIEnv_結(jié)構(gòu)體的指針調(diào)用時(shí)要寫(xiě)成(*env)-GetArrayLength(env, array)C中有內(nèi)聯(lián)函數(shù)包裝可以直接寫(xiě)成env-GetArrayLength(array)兩種調(diào)用方式等價(jià)但混用容易出錯(cuò)。我在C文件里寫(xiě)了(*env)-這種在C里寫(xiě)成env-這種都沒(méi)問(wèn)題。怕就怕C文件里混用了(*env)-雖然能編譯但可讀性很差。6.2 JNIEnv是與線程綁定的JNIEnv一個(gè)極度重要的特性是它綁定的是當(dāng)前native調(diào)用所在的線程。你在一個(gè)線程里拿到JNIEnv如果把它存起來(lái)到了另一個(gè)線程再用輕則拿不到正確的引用對(duì)象重則導(dǎo)致進(jìn)程崩潰。正確做法是在需要訪問(wèn)JNI的線程里通過(guò)JavaVM去獲取對(duì)應(yīng)的JNIEnv。在native方法里拿到JNIEnv時(shí)如果要跨線程使用可以先調(diào)用AttachCurrentThread把新線程掛載到JVM上再拿到這個(gè)線程的JNIEnv用完后再DetachCurrentThread。這里我提一個(gè)在Android或者服務(wù)端線程池場(chǎng)景中非常常見(jiàn)的坑。你有一個(gè)線程池里的工作線程想回調(diào)Java層方法直接用了之前主線程的JNIEnv結(jié)果“時(shí)好時(shí)壞”。本質(zhì)上就是這個(gè)線程綁定問(wèn)題。你需要存一個(gè)JavaVM全局引用而不是存JNIEnv局部引用。JavaVM *g_vm; // 在JNI_OnLoad或初始化時(shí)保存JavaVM JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { g_vm vm; return JNI_VERSION_1_8; } // 在子線程中獲取JNIEnv JNIEnv *env nullptr; g_vm-AttachCurrentThread((void**)env, nullptr); // 使用env... g_vm-DetachCurrentThread();這個(gè)示例提前引入了JNI_OnLoad和JavaVM兩個(gè)概念但其實(shí)是避不開(kāi)的?；A(chǔ)數(shù)據(jù)類型那一層你可能暫時(shí)用不到但只要你繼續(xù)深入JNI一定會(huì)撞上。6.3 JNI_OnLoadJNI環(huán)境的入口動(dòng)態(tài)庫(kù)被System.loadLibrary加載后JVM會(huì)先找JNI_OnLoad這個(gè)導(dǎo)出函數(shù)。如果找到了就調(diào)用它返回值必須是一個(gè)表示JNI版本號(hào)的常量比如JNI_VERSION_1_6、JNI_VERSION_1_8。這個(gè)函數(shù)的常見(jiàn)用途有三個(gè)保存全局的JavaVM指針注冊(cè)native方法RegisterNatives做一些native側(cè)的初始化工作對(duì)比起來(lái)不寫(xiě)JNI_OnLoad的庫(kù)也能跑JVM會(huì)默認(rèn)按JNI_VERSION_1_2規(guī)范去找native符號(hào)。但我建議所有正經(jīng)的JNI庫(kù)都寫(xiě)上因?yàn)楹罄m(xù)全局引用管理、方法注冊(cè)、日志初始化都需要它。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 編譯期報(bào)錯(cuò)找不到j(luò)ni.h或jni_md.h這個(gè)問(wèn)題90%的原因是CMAKE的include路徑?jīng)]配好。CLion里報(bào)錯(cuò)時(shí)仔細(xì)看是哪個(gè)頭文件缺失jni.h缺失JAVA_HOME/include沒(méi)加進(jìn)來(lái)jni_md.h缺失JAVA_HOME/include/linux或win32或darwin沒(méi)加進(jìn)來(lái)。Windows用戶經(jīng)常會(huì)碰到另一個(gè)情況JAVA_HOME路徑里帶了空格比如C:\Program Files\Java\jdk-17CMake如果沒(méi)處理好引號(hào)路徑會(huì)被截?cái)?。解決辦法是把JAVA_HOME路徑用雙引號(hào)包起來(lái)或者干脆設(shè)一個(gè)不含空格的JDK路徑。7.2 運(yùn)行時(shí)UnsatisfiedLinkError找不到符號(hào)UnsatisfiedLinkError可能的原因我按排名列出動(dòng)態(tài)庫(kù)沒(méi)被系統(tǒng)找到j(luò)ava.library.path不對(duì)函數(shù)簽名和Java native方法不對(duì)應(yīng)類名/方法名/參數(shù)不一致C函數(shù)沒(méi)有用extern CWindows上漏了JNIEXPORT動(dòng)態(tài)庫(kù)extension不對(duì)Linux一般是.somacOS是.dylib或.jnilibWindows是.dll檢查順序建議先確認(rèn)庫(kù)路徑然后javap -s看Java側(cè)的native簽名再用nm命令查出動(dòng)態(tài)庫(kù)里的導(dǎo)出符號(hào)對(duì)不對(duì)比最后核對(duì)JNI函數(shù)簽名。比如我經(jīng)常用的排查命令# 查看動(dòng)態(tài)庫(kù)導(dǎo)出符號(hào) nm -D libnative.so | grep Java_如果這里輸出為空那就說(shuō)明符號(hào)導(dǎo)出或者extern C有問(wèn)題。7.3 native方法參數(shù)錯(cuò)位但沒(méi)崩潰這類bug最磨人心態(tài)。表現(xiàn)為運(yùn)行不報(bào)錯(cuò)但某個(gè)參數(shù)的數(shù)值總是錯(cuò)。我一般優(yōu)先懷疑是類型寬度不匹配比如Java層是longC側(cè)用了jint或者Java層是char16位C側(cè)用了jchar16位結(jié)果又強(qiáng)轉(zhuǎn)成了char8位。排查思路用javap -s反編譯確認(rèn)Java側(cè)簽名在native函數(shù)入口處把所有參數(shù)按二進(jìn)制dump出來(lái)對(duì)比期望值檢查所有用了printf的轉(zhuǎn)換是否類型安全如果涉及數(shù)組檢查GetXXXArrayElements后是否動(dòng)過(guò)指針偏移。我還有一個(gè)習(xí)慣所有JNI函數(shù)入口第一行都用宏寫(xiě)一個(gè)“參數(shù)打印”日志把每個(gè)參數(shù)類型和值打印出來(lái)日志會(huì)極大縮短定位時(shí)間。實(shí)際項(xiàng)目里這個(gè)習(xí)慣救了我很多次。7.4 char相關(guān)的中文亂碼問(wèn)題Java的char和C/C的char不是一回事這在前面已經(jīng)強(qiáng)調(diào)了。如果你在C層收到j(luò)char數(shù)組并想轉(zhuǎn)成UTF-8字符串輸出千萬(wàn)別直接強(qiáng)轉(zhuǎn)。推薦的做法是使用JNI的字符串翻譯函數(shù)GetStringUTFChars把Java的String轉(zhuǎn)成UTF-8格式的char*NewStringUTF把UTF-8的char*轉(zhuǎn)成Java的String對(duì)于char[]數(shù)組想好你要的是Unicode碼點(diǎn)還是UTF-8字節(jié)流后再動(dòng)手。很多圖像處理項(xiàng)目傳byte[]就是這個(gè)原因字節(jié)流的語(yǔ)義明確不會(huì)和UTF-16的代理對(duì)打架。7.5 局部引用表溢出JNI里通過(guò)NewStringUTF、FindClass、NewObject等函數(shù)創(chuàng)建的都是局部引用local reference它們只在當(dāng)前native方法調(diào)用期間有效且在一個(gè)線程中額度有限默認(rèn)在某些JVM上是16KB或32KB以上具體因?qū)崿F(xiàn)而異?；A(chǔ)數(shù)據(jù)類型階段還不會(huì)頻繁創(chuàng)建局部引用但你在循環(huán)里反復(fù)調(diào)用NewStringUTF時(shí)就會(huì)踩到這個(gè)坑。解法只有兩種使用DeleteLocalRef顯式釋放或者讓代碼邏輯減少循環(huán)內(nèi)引用創(chuàng)建。更深層的局部引用、全局引用管理會(huì)在后續(xù)章節(jié)單獨(dú)細(xì)講這里先埋個(gè)預(yù)告。8. 后續(xù)內(nèi)容預(yù)告與個(gè)人經(jīng)驗(yàn)JNI這套東西類型系統(tǒng)是第一個(gè)坎但不是最后一個(gè)坎。基礎(chǔ)數(shù)據(jù)類型處理熟之后整個(gè)JNI的常用面就打開(kāi)了。后續(xù)系列里我計(jì)劃重點(diǎn)寫(xiě)這么幾塊第一部分是引用類型jstring、jobject、jclass這些東西的內(nèi)部結(jié)構(gòu)和訪問(wèn)方式特別是字符串處理的UTF-8和UTF-16各種坑第二部分是數(shù)組與直接緩沖區(qū)byte數(shù)組在圖像、音視頻、序列化場(chǎng)景里的高性能傳輸?shù)谌糠质亲侄闻c方法調(diào)用包括訪問(wèn)Java對(duì)象的實(shí)例字段、靜態(tài)字段以及回調(diào)Java方法第四部分是全局引用和局部引用的管理策略這在長(zhǎng)期運(yùn)行的服務(wù)里直接決定內(nèi)存穩(wěn)定性第五部分是RegisterNatives手動(dòng)注冊(cè)方法很多工業(yè)級(jí)JNI庫(kù)都用它繞開(kāi)自動(dòng)符號(hào)查找。當(dāng)初我學(xué)JNI的時(shí)候啃完類型系統(tǒng)后最大的體會(huì)是所有難懂的概念最后都能落到內(nèi)存布局和線程綁定這兩個(gè)核心問(wèn)題上。你理解了數(shù)據(jù)在Java堆和native堆之間怎么流動(dòng)、誰(shuí)手里握著的JNIEnv屬于哪條線程后面再?gòu)?fù)雜的坑也都能推出來(lái)。這篇文章能寫(xiě)的內(nèi)容還有很多但基礎(chǔ)數(shù)據(jù)類型這層地基值得你花一個(gè)下午親手敲一遍代碼。我已經(jīng)把CLion環(huán)境下從Java到C的閉環(huán)流程都列出來(lái)了照著走一遍再去解決那些報(bào)錯(cuò)和錯(cuò)位問(wèn)題你對(duì)JNI的信心會(huì)完全不一樣。 JNI基礎(chǔ)數(shù)據(jù)類型全解析：從jboolean到j(luò)long的常見(jiàn)坑
1. 從JNI的類型系統(tǒng)說(shuō)起為什么第一課必須講這個(gè)JNIJava Native Interface是Java生態(tài)里一個(gè)特別的存在。它讓Java代碼可以直接調(diào)用C/C寫(xiě)的動(dòng)態(tài)庫(kù)反過(guò)來(lái)C/C代碼也能調(diào)用Java層的代碼。十年前我做Android系統(tǒng)定制時(shí)第一次真正用上JNI后來(lái)轉(zhuǎn)做后端中間件在Java服務(wù)里用JNA/JNI調(diào)一些底層算法庫(kù)可以說(shuō)JNI貫穿了我整個(gè)職業(yè)生涯的很多關(guān)鍵階段。很多初學(xué)者一上來(lái)就急著寫(xiě)代碼、調(diào)接口結(jié)果被jstring、jobjectArray、jfieldID這些東西搞得一頭霧水。其實(shí)JNI的所有困難根源都在類型系統(tǒng)——你用什么類型接收J(rèn)ava層傳過(guò)來(lái)的參數(shù)、用什么類型把數(shù)據(jù)傳回Java層直接決定了后面一切調(diào)用的成敗。這篇內(nèi)容我會(huì)把JNI類型系統(tǒng)的全貌講清楚重點(diǎn)聚焦基礎(chǔ)數(shù)據(jù)類型這一塊。內(nèi)容偏向?qū)崙?zhàn)為什么JNI要定義一套自己的typedef這些類型和C/C原生類型之間怎么換算在CLion里搭環(huán)境時(shí)要注意哪些坑以及我在實(shí)際項(xiàng)目中踩過(guò)的那些看起來(lái)能編譯、跑起來(lái)就崩的問(wèn)題。如果你是下面這幾種情況這篇文章值得讀完正在學(xué)JNI剛開(kāi)始接觸javac -h和C/C代碼生成對(duì)jni.h里的類型定義感到陌生在維護(hù)老項(xiàng)目遇到了UnsatisfiedLinkError、JNI參數(shù)錯(cuò)位或者native層讀到亂碼的問(wèn)題想在CLion里配置一套完整的JNI開(kāi)發(fā)調(diào)試環(huán)境不想再用命令行手動(dòng)javac/編譯的笨辦法。JNI類型系統(tǒng)說(shuō)白了就兩件事一是Java和C/C之間的數(shù)據(jù)怎么“翻譯”二是翻譯過(guò)程中誰(shuí)能保證字節(jié)數(shù)、符號(hào)、內(nèi)存布局完全不出錯(cuò)?；A(chǔ)數(shù)據(jù)類型是整個(gè)JNI類型系統(tǒng)的地基地基不牢后面說(shuō)什么jobject回調(diào)、局部引用管理都是在空中樓閣。2. 基礎(chǔ)數(shù)據(jù)類型全解析jboolean到j(luò)double的每一個(gè)坑2.1 JNI為什么不用C語(yǔ)言的int、long先回答一個(gè)非常自然的疑問(wèn)Java層有int、long、booleanC語(yǔ)言也有int、long為什么JNI不能直接用我在給團(tuán)隊(duì)做內(nèi)部培訓(xùn)時(shí)經(jīng)常舉這個(gè)例子C標(biāo)準(zhǔn)里只規(guī)定了int最短16位、long最長(zhǎng)不超過(guò)double但具體是多少位由編譯器和平臺(tái)決定。在Windows上是LLP64模型long是32位在Linux x86_64上是LP64模型long是64位。Java的int永遠(yuǎn)32位、long永遠(yuǎn)64位這是語(yǔ)言規(guī)范寫(xiě)死的事情。如果JNI直接映射同一個(gè)C函數(shù)在Windows下編譯和Linux下編譯對(duì)于long類型參數(shù)的二進(jìn)制布局可能完全不同。老練的C程序員肯定會(huì)說(shuō)用int32_t、int64_t這些stdint.h里的定長(zhǎng)類型不就行了JNI思路一致但它比這個(gè)更進(jìn)一步它直接在jni.h頭文件里把類型全部typedef出來(lái)形成一套Java世界和原生世界之間的“契約語(yǔ)言”。這就是JNI類型系統(tǒng)存在的核心價(jià)值用一套固定的、平臺(tái)無(wú)關(guān)的typedef屏蔽Java與C/C之間的類型差異。你看jni.h時(shí)會(huì)發(fā)現(xiàn)所有平臺(tái)的JNI實(shí)現(xiàn)都約定同一個(gè)頭文件、同一套類型名保證Java代碼“一處編寫(xiě)、處處原生”。2.2 八大基礎(chǔ)數(shù)據(jù)類型的完整映射表JNI的基礎(chǔ)類型定義在jni.h的頭部核心映射我整理成一張表Java類型JNI的C/C類型實(shí)際C語(yǔ)言底層定義占用字節(jié)數(shù)說(shuō)明booleanjbooleanunsigned char1字節(jié)只約定0和1bytejbytesigned char1字節(jié)有符號(hào)8位charjcharunsigned short2字節(jié)Java的char是UTF-16編碼單元不是ASCIIshortjshortshort2字節(jié)有符號(hào)16位intjintint4字節(jié)固定32位等價(jià)int32_tlongjlonglong long8字節(jié)固定64位等價(jià)int64_tfloatjfloatfloat4字節(jié)IEEE 754單精度doublejdoubledouble8字節(jié)IEEE 754雙精度voidvoidvoid—僅用于方法返回類型這張表里最值得警惕的就是jboolean和jchar它們也是我見(jiàn)到的錯(cuò)誤率最高的兩個(gè)類型。jboolean底層是unsigned char而不是C里的bool。Java層的boolean語(yǔ)義上只有true/falsenative層用unsigned char只是為了嚴(yán)格保證1個(gè)字節(jié)的存儲(chǔ)尺寸。C的bool標(biāo)準(zhǔn)雖然也通常是1字節(jié)但C標(biāo)準(zhǔn)的bool和這畢竟不是同一個(gè)東西所以JNI規(guī)范里特意定義了jboolean。實(shí)際調(diào)用時(shí)如果Java傳了true你收到的是1傳false收到0。但你在native層用jboolean接收后用if (value JNI_TRUE)判斷這里的JNI_TRUE定義就是常量1。jchar是unsigned short2字節(jié)無(wú)符號(hào)。這里有個(gè)隱蔽的坑C/C里的char幾乎都是1字節(jié)很多新手在C/C側(cè)把JNI返回的jchar直接強(qiáng)轉(zhuǎn)為char結(jié)果遇到中文或者4字節(jié)以上的Unicode碼點(diǎn)時(shí)數(shù)據(jù)直接截?cái)?。Java的char是UTF-16 code unit你接到的jchar可能是代理對(duì)surrogate pair中的一半。如果你要做字符串處理應(yīng)該走GetStringChars或者GetStringUTFChars而不是自己逐個(gè)轉(zhuǎn)char。jlong的坑更偏向“習(xí)慣”在Windows上的C代碼里long是32位但JNI的jlong明確是long long。如果你寫(xiě)成long接收jlong編譯能過(guò)但高32位直接被丟掉返回的數(shù)據(jù)完全錯(cuò)亂。我見(jiàn)過(guò)不止一個(gè)同事在這種地方花了一整天才排查出來(lái)。2.3 類型映射背后的數(shù)字講究為什么正好是這些字節(jié)長(zhǎng)度有人會(huì)問(wèn)Java的byte如果映射成signed char為什么不用int8_tJava的int為什么不用int32_t答案不是JNI老而是JNI要考慮C89/C99的老編譯器兼容性。當(dāng)年JNI規(guī)范定下來(lái)的時(shí)候C99的stdint.h還沒(méi)有被廣泛支持JNI在jni.h里自己用typedef定義了一套類型保證哪怕在非常老舊的C編譯環(huán)境下也能編譯通過(guò)。不過(guò)現(xiàn)代的jni.h里也大量配合使用stdint.h里的類型typedef unsigned char jboolean; typedef unsigned short jchar; typedef short jshort; typedef int jint; // 在特定的JNI實(shí)現(xiàn)里jlong也可能是 // typedef long long jlong;你去看JDK自帶的jni.h有的版本里jint就是intjlong就是long long但這都無(wú)所謂因?yàn)镴NI規(guī)范保證的是“字節(jié)寬度固定、符號(hào)固定”。真正重要的是你在自己的C/C代碼里用等寬類型去接// 推薦做法使用定長(zhǎng)類型 int32_t myJavaInt jint_value; int64_t myJavaLong jlong_value;這種寫(xiě)法的好處在于你的native代碼邏輯是自文檔化的明示了數(shù)據(jù)寬度未來(lái)跨平臺(tái)移植時(shí)不會(huì)因?yàn)閕nt、long在不同平臺(tái)上的默認(rèn)寬度不一致而出問(wèn)題。2.4 為什么沒(méi)有jbyteArray的基礎(chǔ)類型對(duì)應(yīng)物JNI區(qū)分“基礎(chǔ)類型”和“引用類型”。八種基礎(chǔ)類型對(duì)應(yīng)Java的基本類型引用類型則對(duì)應(yīng)數(shù)組、String、Class、Throwable以及所有Java對(duì)象。最容易混淆的是jbyteArray、jintArray這類東西——它們不是基礎(chǔ)類型而是數(shù)組類型屬于引用類型范疇。JNI設(shè)計(jì)時(shí)給每種基礎(chǔ)類型都配了一個(gè)對(duì)應(yīng)的Array類型但不建議把它們和基礎(chǔ)類型混在一起記憶基礎(chǔ)類型對(duì)應(yīng)的JNI數(shù)組類型獲取數(shù)據(jù)的JNI函數(shù)jbooleanjbooleanArrayGetBooleanArrayElementsjbytejbyteArrayGetByteArrayElementsjcharjcharArrayGetCharArrayElementsjshortjshortArrayGetShortArrayElementsjintjintArrayGetIntArrayElementsjlongjlongArrayGetLongArrayElementsjfloatjfloatArrayGetFloatArrayElementsjdoublejdoubleArrayGetDoubleArrayElements從這里能看出JNI的一貫思路基礎(chǔ)類型是值傳遞的數(shù)組和對(duì)象是引用類型的需要JNI函數(shù)專門獲取與釋放。這篇著重講基礎(chǔ)類型但數(shù)組類型你一定會(huì)碰到尤其是byte數(shù)組在傳輸二進(jìn)制數(shù)據(jù)時(shí)幾乎避不開(kāi)。后面的章節(jié)里我會(huì)詳細(xì)展開(kāi)數(shù)組和引用類型的細(xì)節(jié)。3. JNIEnV的取值與傳值機(jī)制基礎(chǔ)數(shù)據(jù)到底怎么跨語(yǔ)言流動(dòng)3.1 基礎(chǔ)類型按值傳遞這句話怎么理解熟悉C的人都知道函數(shù)參數(shù)有兩種傳遞方式值傳遞和引用傳遞。JNI對(duì)于基礎(chǔ)類型采用的就是值傳遞。Java層調(diào)用native方法時(shí)int參數(shù)直接復(fù)制一份原始值傳到C函數(shù)棧上C函數(shù)返回jint時(shí)也直接返回值本身。這意味著native函數(shù)里對(duì)參數(shù)的修改不會(huì)影響Java層的原變量。這和Java本身的基本類型語(yǔ)義是一致的。理解這一點(diǎn)對(duì)調(diào)試很有用如果你在native層改了jint的值Java層沒(méi)變不是JNI出bug了是你對(duì)值傳遞的預(yù)期錯(cuò)了。但是有個(gè)重要的例外如果你傳入的是一個(gè)int[]數(shù)組jintArray哪怕每個(gè)元素是int整個(gè)數(shù)組在JNI層面是一個(gè)引用類型。你操作數(shù)組元素時(shí)必須通過(guò)GetIntArrayElements拿到C側(cè)指針這時(shí)候你在C側(cè)改數(shù)組元素如果調(diào)用了ReleaseIntArrayElements時(shí)用了JNI_COMMIT或0是可以把修改同步回Java數(shù)組的。所以“基礎(chǔ)類型按值傳遞”只對(duì)單個(gè)標(biāo)量成立對(duì)數(shù)組完全不成立。3.2 JNIEXPORT和JNIEXPORT的符號(hào)導(dǎo)出原理看JNI的native函數(shù)聲明會(huì)有兩個(gè)醒目的宏JNIEXPORT jint JNICALL Java_com_example_NativeLib_add(JNIEnv *env, jobject thiz, jint a, jint b);JNIEXPORT這個(gè)宏在Windows上是__declspec(dllexport)在Linux/Unix上為空或__attribute__((visibility(default)))JNICALL在Windows上是__stdcall調(diào)用約定在Linux等平臺(tái)上為空。這段宏的作用是控制函數(shù)導(dǎo)出和調(diào)用約定。Windows下DLL的符號(hào)默認(rèn)不導(dǎo)出如果沒(méi)有JNIEXPORTJava層運(yùn)行時(shí)就會(huì)報(bào)“找不到add符號(hào)”也就是UnsatisfiedLinkError。所以如果你在Windows上手動(dòng)寫(xiě)JNI函數(shù)名千萬(wàn)別漏了這兩個(gè)宏。在CMakeLists.txt里設(shè)置C_VISIBILITY_PRESET hidden時(shí)這兩個(gè)宏的意義就更重要了。從JVM的角度看動(dòng)態(tài)庫(kù)加載后JVM會(huì)通過(guò)dlsymLinux或GetProcAddressWindows查找符號(hào)。如果找不到就報(bào)錯(cuò)。符號(hào)本身還必須是extern C的否則C編譯器會(huì)做名字改編name manglingJVM按C符號(hào)去找就會(huì)撲空。這里我列一下最常見(jiàn)的三個(gè)native層找不到符號(hào)的場(chǎng)景漏了extern CWindows下漏了JNIEXPORT導(dǎo)致未導(dǎo)出用C寫(xiě)了函數(shù)重載名字被編譯器改編每個(gè)都讓你報(bào)錯(cuò)UnsatisfiedLinkError但報(bào)錯(cuò)位置和時(shí)機(jī)略有不同。實(shí)際開(kāi)發(fā)中我建議所有JNI封裝函數(shù)都按這個(gè)格式嚴(yán)格寫(xiě)全不要偷懶省宏。3.3 從Java層調(diào)用native方法時(shí)的完整數(shù)據(jù)流以最簡(jiǎn)單的add方法為例完整數(shù)據(jù)流是這樣的Java層調(diào)用NativeLib.add(3, 5)JVM根據(jù)System.loadLibrary(native)加載動(dòng)態(tài)庫(kù)把符號(hào)解析注冊(cè)到當(dāng)前進(jìn)程調(diào)用時(shí)JVM把JNIEnv指針和jobject或jclass看方法是否static壓棧再把參數(shù)按JNI類型壓棧native函數(shù)執(zhí)行拿到a3、b5算出jint返回值返回值通過(guò)JNI約定傳回Java層Java方法獲得8。整個(gè)過(guò)程中JVM不關(guān)心你native函數(shù)內(nèi)部怎么實(shí)現(xiàn)的它只關(guān)心入口符號(hào)約定是否匹配、參數(shù)棧布局是否匹配。這就是為什么類型語(yǔ)義這么重要——一旦某個(gè)參數(shù)類型對(duì)不上壓棧/出棧的字節(jié)數(shù)不一樣函數(shù)可能不立即崩潰直到下一次調(diào)用棧返回時(shí)才炸這種bug極其難查。我舉一個(gè)我真實(shí)遇到過(guò)的例子。項(xiàng)目里有人把native方法簽名里的long參數(shù)換成了int參數(shù)因?yàn)閮蛇叺拇a不是同一個(gè)人寫(xiě)的Java層傳的是longC層接的是jint。64位系統(tǒng)下long是8字節(jié)jint是4字節(jié)。JVM壓棧了8字節(jié)C函數(shù)按4字節(jié)解析局部變量后面的參數(shù)全部錯(cuò)位。最終表現(xiàn)是函數(shù)能進(jìn)能出但第二個(gè)參數(shù)永遠(yuǎn)是個(gè)垃圾值而且概率性崩潰。用valgrind一跑才發(fā)現(xiàn)棧被寫(xiě)壞了。所以Java和native層的類型簽名必須嚴(yán)格一致這是JNI第一條軍規(guī)。類型映射表不是參考建議是法律條文。4. CLion中配置JNI開(kāi)發(fā)環(huán)境從零到一跑通第一個(gè)example4.1 為什么推薦CLion作為JNI開(kāi)發(fā)IDECLion對(duì)JNI開(kāi)發(fā)的支持在當(dāng)前的IDE陣營(yíng)里算是比較友好的一檔。一方面JetBrains家的IDEA和CLion可以聯(lián)動(dòng)端到端調(diào)試Java調(diào)用native方法的場(chǎng)景可以直接在CLion的調(diào)試器里斷點(diǎn)另一方面CLion原生支持CMake而JNI的C/C側(cè)正好絕大多數(shù)都是用CMake構(gòu)建的。相比Eclipse CDT那套老掉牙的組合CLion的環(huán)境配置要順滑很多。我在開(kāi)篇提到的“在CLion中配置jni環(huán)境”這個(gè)熱搜詞也確實(shí)反映了很多人的剛需。下面我給的配置流程基于Linux/macOS環(huán)境Windows步驟基本一致差異主要是JAVA_HOME路徑和動(dòng)態(tài)庫(kù)后綴名Windows是.dllmacOS是.jnilib或.dylibLinux是.so。4.2 第一步準(zhǔn)備JDK和CLion先用java -version確認(rèn)你的JDK版本。JNI開(kāi)發(fā)建議用JDK 8或更高的版本。然后記下你的JAVA_HOME路徑# Linux/macOS echo $JAVA_HOME # 如果沒(méi)有設(shè)置先找到j(luò)ava所在路徑 which java # 然后推斷JAVA_HOME一般是 /usr/lib/jvm/java-11-openjdk-amd64 之類一般CMakeLists.txt里需要這個(gè)路徑來(lái)引入jni.h和jni_md.h。4.3 第二步創(chuàng)建Java端代碼并生成頭文件CLion雖然主打C/C但它也能混編。我習(xí)慣把Java文件放在項(xiàng)目的java_src目錄下這樣便于管理。新建一個(gè)Java類public class NativeLib { static { System.loadLibrary(native); } public native int add(int a, int b); public native String getMessage(); public static void main(String[] args) { NativeLib lib new NativeLib(); System.out.println(3 5 lib.add(3, 5)); System.out.println(lib.getMessage()); } }編譯后生成頭文件cd java_src javac NativeLib.java javac -h . NativeLib.java如果用的是JDK 8請(qǐng)用javac -h不是javac -jniJDK 8以前用的是javah命令JDK 8雖然還保留javah但建議直接用javac -h。成功后會(huì)生成一個(gè)NativeLib.h文件里面就是JNIEXPORT聲明的函數(shù)原型。/* DO NOT EDIT THIS FILE - it is machine generated */ #include jni.h #ifndef _Included_NativeLib #define _Included_NativeLib #ifdef __cplusplus extern C { #endif JNIEXPORT jint JNICALL Java_NativeLib_add (JNIEnv *, jobject, jint, jint); JNIEXPORT jstring JNICALL Java_NativeLib_getMessage (JNIEnv *, jobject); #ifdef __cplusplus } #endif #endif請(qǐng)仔細(xì)看這個(gè)頭文件所有函數(shù)都包裹在extern C里這就是為什么我們自己的.cpp實(shí)現(xiàn)文件也要包含這個(gè)頭文件以確保函數(shù)定義時(shí)也是C鏈接。4.4 第三步CMakeLists.txt配置在項(xiàng)目根目錄創(chuàng)建CMakeLists.txt重點(diǎn)是將jni.h所在的include目錄和平臺(tái)相關(guān)的目錄暴露給編譯器。cmake_minimum_required(VERSION 3.20) project(jni_native LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) # JDK 路徑按你的實(shí)際JAVA_HOME修改 set(JAVA_HOME /usr/lib/jvm/java-11-openjdk-amd64) include_directories( ${JAVA_HOME}/include ${JAVA_HOME}/include/linux # macOS 下是 ${JAVA_HOME}/include/darwin ) add_library(native SHARED native_lib.cpp ) # macOS 需要額外設(shè)置安裝名 if(APPLE) set_target_properties(native PROPERTIES INSTALL_RPATH loader_path BUILD_WITH_INSTALL_RPATH TRUE ) endif()注意Windows上的include目錄是JAVA_HOME/include和JAVA_HOME/include/win32Linux是include/linuxmacOS是include/darwin。很多人在這一步漏了平臺(tái)子目錄導(dǎo)致找不到j(luò)ni_md.h。4.5 第四步C側(cè)實(shí)現(xiàn)實(shí)現(xiàn)文件里我們的函數(shù)簽名要和生成的頭文件完全一致。這里我用一個(gè)關(guān)鍵點(diǎn)示范jstring和jint混合處理。#include jni.h #include string #include NativeLib.h extern C { JNIEXPORT jint JNICALL Java_NativeLib_add(JNIEnv *env, jobject thiz, jint a, jint b) { return a b; } JNIEXPORT jstring JNICALL Java_NativeLib_getMessage(JNIEnv *env, jobject thiz) { std::string msg Hello from C JNI; return env-NewStringUTF(msg.c_str()); } }這個(gè)函數(shù)里出現(xiàn)了jstring和NewStringUTF這屬于引用類型和JNI函數(shù)調(diào)用的范疇了但先記住一點(diǎn)jstring你不能當(dāng)成普通字符串返回必須通過(guò)NewStringUTF或NewString創(chuàng)建。后面章節(jié)講引用類型時(shí)我會(huì)重點(diǎn)展開(kāi)。4.6 第五步編譯并運(yùn)行在CLion里直接點(diǎn)擊Build生成libnative.so或libnative.dylib、native.dll。然后把生成的動(dòng)態(tài)庫(kù)放到Java代碼能加載到的地方運(yùn)行NativeLib。運(yùn)行Java主類的方式可以直接用CLion的Run Configuration搭配IDEA也可以命令行java -Djava.library.path./build/lib NativeLibIdea自身也可以在VM options里配置-Djava.library.path指向你的動(dòng)態(tài)庫(kù)所在目錄。第一次跑通這個(gè)流程你基本就對(duì)JNI的開(kāi)發(fā)閉環(huán)有了整體感知Java定義native方法javac -h生成頭文件C實(shí)現(xiàn)編譯成一個(gè)動(dòng)態(tài)庫(kù)Java程序加載并調(diào)用。后面所有復(fù)雜功能包括字符串、數(shù)組、Java對(duì)象回調(diào)都是在這條流水線上擴(kuò)展出來(lái)的。5. 基礎(chǔ)數(shù)據(jù)類型實(shí)操案例從int到j(luò)charArray的完整演示5.1 一個(gè)綜合示例Java層傳多種基礎(chǔ)類型前面只演示了add函數(shù)這里我多給一個(gè)綜合一點(diǎn)的例子涉及所有基礎(chǔ)類型。Java端public class TypeDemo { static { System.loadLibrary(typedemo); } public native void passAllTypes(boolean boolVal, byte byteVal, char charVal, short shortVal, int intVal, long longVal, float floatVal, double doubleVal); public native long testLongReturn(); }生成頭文件后C側(cè)實(shí)現(xiàn)extern C JNIEXPORT void JNICALL Java_TypeDemo_passAllTypes(JNIEnv *env, jobject thiz, jboolean boolVal, jbyte byteVal, jchar charVal, jshort shortVal, jint intVal, jlong longVal, jfloat floatVal, jdouble doubleVal) { // 打印時(shí)全部顯式轉(zhuǎn)成可打印的類型 char cStr[64]; snprintf(cStr, sizeof(cStr), char code point: %u, static_castunsigned int(charVal)); printf(boolVal%d, byteVal%d, shortVal%d, intVal%d, longVal%lld\n, static_castint(boolVal), static_castint(byteVal), static_castint(shortVal), static_castint(intVal), static_castlong long(longVal)); printf(floatVal%.2f, doubleVal%.2f, %s\n, static_castdouble(floatVal), doubleVal, cStr); }這里的關(guān)鍵點(diǎn)在printf里。jboolean是unsigned char不能直接匹配%dfloat傳給printf的%f之前必須轉(zhuǎn)成double。如果你偷懶直接把jfloat當(dāng)double傳給printf在64位平臺(tái)上可能會(huì)因?yàn)閰?shù)類型不匹配讀到垃圾值。C語(yǔ)言的printf是類型不安全的這里我要再?gòu)?qiáng)調(diào)一次JNI函數(shù)內(nèi)部不是避風(fēng)港C/C的類型規(guī)則照常生效。5.2 jcharArray入?yún)⒌奶幚硎痉秱鲉蝹€(gè)jchar很簡(jiǎn)單但是一旦遇到char數(shù)組事情就不一樣了?？聪旅孢@個(gè)例子Java層傳一個(gè)char[]過(guò)來(lái)。public native int calcCharArrayLength(char[] data);C側(cè)實(shí)現(xiàn)extern C JNIEXPORT jint JNICALL Java_TypeDemo_calcCharArrayLength(JNIEnv *env, jobject thiz, jcharArray array) { if (array nullptr) { return 0; } jsize len env-GetArrayLength(array); jchar *elements env-GetCharArrayElements(array, nullptr); if (elements nullptr) { return 0; } // 這里臨時(shí)用elements做一些只讀操作 jsize count 0; for (jsize i 0; i len; i) { if (elements[i] ! 0) { count; } } env-ReleaseCharArrayElements(array, elements, JNI_ABORT); return count; }GetCharArrayElements拿回來(lái)的是底層緩沖區(qū)的指針這個(gè)指針可能指向Java堆的拷貝也可能直接指向原始數(shù)組取決于JVM實(shí)現(xiàn)和調(diào)用場(chǎng)景。用完之后必須Release否則會(huì)內(nèi)存泄漏。第三個(gè)參數(shù)mode有三種取值0將修改拷貝回Java數(shù)組并釋放原生數(shù)組相當(dāng)于“寫(xiě)回”JNI_COMMIT將修改拷貝回Java數(shù)組但不釋放原生數(shù)組JNI_ABORT不拷貝回Java數(shù)組直接釋放原生數(shù)組小程序里很多人圖省事永遠(yuǎn)傳0但當(dāng)你修改的是從Java傳進(jìn)來(lái)的只讀數(shù)據(jù)時(shí)用JNI_ABORT性能更高避免一次無(wú)謂的拷貝回寫(xiě)。這是JNI性能優(yōu)化里最基礎(chǔ)的一課。5.3 jboolean的特異功能JNI_TRUE和JNI_FALSEJNI在jni.h里還定義了兩個(gè)常量#define JNI_FALSE 0 #define JNI_TRUE 1實(shí)際寫(xiě)代碼時(shí)請(qǐng)用這兩個(gè)常量不要直接用數(shù)字0、1。同時(shí)因?yàn)閖boolean是unsigned char不要把它和C的bool混用更不要拿它直接做某些系統(tǒng)API的bool參數(shù)。如果需要轉(zhuǎn)換顯示轉(zhuǎn)換出來(lái)bool cppBool (jboolValue JNI_TRUE);這樣避免了一個(gè)經(jīng)典異常你把jboolean直接當(dāng)作bool傳給了某個(gè)C接口C接口內(nèi)部檢查value true或者is true時(shí)如果jboolean的值是1以外的其他非零值結(jié)果就是未定義行為。6. JNI中無(wú)處不在的JNIEnv指針理解它是理解一切的鑰匙6.1 JNIEnv到底是什么JNIEnv是JNI Native Interface的核心句柄。每個(gè)native方法第一個(gè)參數(shù)都是它除非是JNI_CreateJavaVM那類特殊入口。它本質(zhì)上是一個(gè)指向線程局部數(shù)據(jù)的指針這個(gè)數(shù)據(jù)里裝著一整個(gè)函數(shù)表你調(diào)用的所有JNI函數(shù)NewStringUTF、GetArrayLength、CallIntMethod等都是這張表里的函數(shù)指針?？梢园袹NIEnv想象成一個(gè)“Java虛擬機(jī)在native層的翻譯”。你通過(guò)它向JVM查詢數(shù)組長(zhǎng)度、創(chuàng)建Java對(duì)象、拋異常、訪問(wèn)字段。沒(méi)有它JNI代碼寸步難行。C和C訪問(wèn)JNIEnv的方式有很大差別C語(yǔ)言中JNIEnv是JNIEnv_結(jié)構(gòu)體的指針調(diào)用時(shí)要寫(xiě)成(*env)-GetArrayLength(env, array)C中有內(nèi)聯(lián)函數(shù)包裝可以直接寫(xiě)成env-GetArrayLength(array)兩種調(diào)用方式等價(jià)但混用容易出錯(cuò)。我在C文件里寫(xiě)了(*env)-這種在C里寫(xiě)成env-這種都沒(méi)問(wèn)題。怕就怕C文件里混用了(*env)-雖然能編譯但可讀性很差。6.2 JNIEnv是與線程綁定的JNIEnv一個(gè)極度重要的特性是它綁定的是當(dāng)前native調(diào)用所在的線程。你在一個(gè)線程里拿到JNIEnv如果把它存起來(lái)到了另一個(gè)線程再用輕則拿不到正確的引用對(duì)象重則導(dǎo)致進(jìn)程崩潰。正確做法是在需要訪問(wèn)JNI的線程里通過(guò)JavaVM去獲取對(duì)應(yīng)的JNIEnv。在native方法里拿到JNIEnv時(shí)如果要跨線程使用可以先調(diào)用AttachCurrentThread把新線程掛載到JVM上再拿到這個(gè)線程的JNIEnv用完后再DetachCurrentThread。這里我提一個(gè)在Android或者服務(wù)端線程池場(chǎng)景中非常常見(jiàn)的坑。你有一個(gè)線程池里的工作線程想回調(diào)Java層方法直接用了之前主線程的JNIEnv結(jié)果“時(shí)好時(shí)壞”。本質(zhì)上就是這個(gè)線程綁定問(wèn)題。你需要存一個(gè)JavaVM全局引用而不是存JNIEnv局部引用。JavaVM *g_vm; // 在JNI_OnLoad或初始化時(shí)保存JavaVM JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { g_vm vm; return JNI_VERSION_1_8; } // 在子線程中獲取JNIEnv JNIEnv *env nullptr; g_vm-AttachCurrentThread((void**)env, nullptr); // 使用env... g_vm-DetachCurrentThread();這個(gè)示例提前引入了JNI_OnLoad和JavaVM兩個(gè)概念但其實(shí)是避不開(kāi)的?；A(chǔ)數(shù)據(jù)類型那一層你可能暫時(shí)用不到但只要你繼續(xù)深入JNI一定會(huì)撞上。6.3 JNI_OnLoadJNI環(huán)境的入口動(dòng)態(tài)庫(kù)被System.loadLibrary加載后JVM會(huì)先找JNI_OnLoad這個(gè)導(dǎo)出函數(shù)。如果找到了就調(diào)用它返回值必須是一個(gè)表示JNI版本號(hào)的常量比如JNI_VERSION_1_6、JNI_VERSION_1_8。這個(gè)函數(shù)的常見(jiàn)用途有三個(gè)保存全局的JavaVM指針注冊(cè)native方法RegisterNatives做一些native側(cè)的初始化工作對(duì)比起來(lái)不寫(xiě)JNI_OnLoad的庫(kù)也能跑JVM會(huì)默認(rèn)按JNI_VERSION_1_2規(guī)范去找native符號(hào)。但我建議所有正經(jīng)的JNI庫(kù)都寫(xiě)上因?yàn)楹罄m(xù)全局引用管理、方法注冊(cè)、日志初始化都需要它。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 編譯期報(bào)錯(cuò)找不到j(luò)ni.h或jni_md.h這個(gè)問(wèn)題90%的原因是CMAKE的include路徑?jīng)]配好。CLion里報(bào)錯(cuò)時(shí)仔細(xì)看是哪個(gè)頭文件缺失jni.h缺失JAVA_HOME/include沒(méi)加進(jìn)來(lái)jni_md.h缺失JAVA_HOME/include/linux或win32或darwin沒(méi)加進(jìn)來(lái)。Windows用戶經(jīng)常會(huì)碰到另一個(gè)情況JAVA_HOME路徑里帶了空格比如C:\Program Files\Java\jdk-17CMake如果沒(méi)處理好引號(hào)路徑會(huì)被截?cái)?。解決辦法是把JAVA_HOME路徑用雙引號(hào)包起來(lái)或者干脆設(shè)一個(gè)不含空格的JDK路徑。7.2 運(yùn)行時(shí)UnsatisfiedLinkError找不到符號(hào)UnsatisfiedLinkError可能的原因我按排名列出動(dòng)態(tài)庫(kù)沒(méi)被系統(tǒng)找到j(luò)ava.library.path不對(duì)函數(shù)簽名和Java native方法不對(duì)應(yīng)類名/方法名/參數(shù)不一致C函數(shù)沒(méi)有用extern CWindows上漏了JNIEXPORT動(dòng)態(tài)庫(kù)extension不對(duì)Linux一般是.somacOS是.dylib或.jnilibWindows是.dll檢查順序建議先確認(rèn)庫(kù)路徑然后javap -s看Java側(cè)的native簽名再用nm命令查出動(dòng)態(tài)庫(kù)里的導(dǎo)出符號(hào)對(duì)不對(duì)比最后核對(duì)JNI函數(shù)簽名。比如我經(jīng)常用的排查命令# 查看動(dòng)態(tài)庫(kù)導(dǎo)出符號(hào) nm -D libnative.so | grep Java_如果這里輸出為空那就說(shuō)明符號(hào)導(dǎo)出或者extern C有問(wèn)題。7.3 native方法參數(shù)錯(cuò)位但沒(méi)崩潰這類bug最磨人心態(tài)。表現(xiàn)為運(yùn)行不報(bào)錯(cuò)但某個(gè)參數(shù)的數(shù)值總是錯(cuò)。我一般優(yōu)先懷疑是類型寬度不匹配比如Java層是longC側(cè)用了jint或者Java層是char16位C側(cè)用了jchar16位結(jié)果又強(qiáng)轉(zhuǎn)成了char8位。排查思路用javap -s反編譯確認(rèn)Java側(cè)簽名在native函數(shù)入口處把所有參數(shù)按二進(jìn)制dump出來(lái)對(duì)比期望值檢查所有用了printf的轉(zhuǎn)換是否類型安全如果涉及數(shù)組檢查GetXXXArrayElements后是否動(dòng)過(guò)指針偏移。我還有一個(gè)習(xí)慣所有JNI函數(shù)入口第一行都用宏寫(xiě)一個(gè)“參數(shù)打印”日志把每個(gè)參數(shù)類型和值打印出來(lái)日志會(huì)極大縮短定位時(shí)間。實(shí)際項(xiàng)目里這個(gè)習(xí)慣救了我很多次。7.4 char相關(guān)的中文亂碼問(wèn)題Java的char和C/C的char不是一回事這在前面已經(jīng)強(qiáng)調(diào)了。如果你在C層收到j(luò)char數(shù)組并想轉(zhuǎn)成UTF-8字符串輸出千萬(wàn)別直接強(qiáng)轉(zhuǎn)。推薦的做法是使用JNI的字符串翻譯函數(shù)GetStringUTFChars把Java的String轉(zhuǎn)成UTF-8格式的char*NewStringUTF把UTF-8的char*轉(zhuǎn)成Java的String對(duì)于char[]數(shù)組想好你要的是Unicode碼點(diǎn)還是UTF-8字節(jié)流后再動(dòng)手。很多圖像處理項(xiàng)目傳byte[]就是這個(gè)原因字節(jié)流的語(yǔ)義明確不會(huì)和UTF-16的代理對(duì)打架。7.5 局部引用表溢出JNI里通過(guò)NewStringUTF、FindClass、NewObject等函數(shù)創(chuàng)建的都是局部引用local reference它們只在當(dāng)前native方法調(diào)用期間有效且在一個(gè)線程中額度有限默認(rèn)在某些JVM上是16KB或32KB以上具體因?qū)崿F(xiàn)而異?；A(chǔ)數(shù)據(jù)類型階段還不會(huì)頻繁創(chuàng)建局部引用但你在循環(huán)里反復(fù)調(diào)用NewStringUTF時(shí)就會(huì)踩到這個(gè)坑。解法只有兩種使用DeleteLocalRef顯式釋放或者讓代碼邏輯減少循環(huán)內(nèi)引用創(chuàng)建。更深層的局部引用、全局引用管理會(huì)在后續(xù)章節(jié)單獨(dú)細(xì)講這里先埋個(gè)預(yù)告。8. 后續(xù)內(nèi)容預(yù)告與個(gè)人經(jīng)驗(yàn)JNI這套東西類型系統(tǒng)是第一個(gè)坎但不是最后一個(gè)坎。基礎(chǔ)數(shù)據(jù)類型處理熟之后整個(gè)JNI的常用面就打開(kāi)了。后續(xù)系列里我計(jì)劃重點(diǎn)寫(xiě)這么幾塊第一部分是引用類型jstring、jobject、jclass這些東西的內(nèi)部結(jié)構(gòu)和訪問(wèn)方式特別是字符串處理的UTF-8和UTF-16各種坑第二部分是數(shù)組與直接緩沖區(qū)byte數(shù)組在圖像、音視頻、序列化場(chǎng)景里的高性能傳輸?shù)谌糠质亲侄闻c方法調(diào)用包括訪問(wèn)Java對(duì)象的實(shí)例字段、靜態(tài)字段以及回調(diào)Java方法第四部分是全局引用和局部引用的管理策略這在長(zhǎng)期運(yùn)行的服務(wù)里直接決定內(nèi)存穩(wěn)定性第五部分是RegisterNatives手動(dòng)注冊(cè)方法很多工業(yè)級(jí)JNI庫(kù)都用它繞開(kāi)自動(dòng)符號(hào)查找。當(dāng)初我學(xué)JNI的時(shí)候啃完類型系統(tǒng)后最大的體會(huì)是所有難懂的概念最后都能落到內(nèi)存布局和線程綁定這兩個(gè)核心問(wèn)題上。你理解了數(shù)據(jù)在Java堆和native堆之間怎么流動(dòng)、誰(shuí)手里握著的JNIEnv屬于哪條線程后面再?gòu)?fù)雜的坑也都能推出來(lái)。這篇文章能寫(xiě)的內(nèi)容還有很多但基礎(chǔ)數(shù)據(jù)類型這層地基值得你花一個(gè)下午親手敲一遍代碼。我已經(jīng)把CLion環(huán)境下從Java到C的閉環(huán)流程都列出來(lái)了照著走一遍再去解決那些報(bào)錯(cuò)和錯(cuò)位問(wèn)題你對(duì)JNI的信心會(huì)完全不一樣。