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