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