JNI 數(shù)組操作這塊說實(shí)話是最容易讓人寫崩的地方。你說 JNI 難吧字符串操作、對(duì)象字段訪問這些頂多算繁瑣但數(shù)組一進(jìn)來模式就完全不一樣了——關(guān)鍵不是你會(huì)不會(huì)調(diào) Get 函數(shù)而是你知不知道每次調(diào)用背后發(fā)生了什么數(shù)據(jù)是被復(fù)制出來的還是拿到指針直接訪問釋放的時(shí)候用哪種模式這些決策直接決定程序是穩(wěn)如老狗還是時(shí)不時(shí)崩一下。這篇指南主要解決四個(gè)問題怎么正確讀取和修改 Java 傳入的數(shù)組、怎么優(yōu)雅地創(chuàng)建數(shù)組返回給 Java、怎么用直接緩沖區(qū)減少拷貝、以及那些真正生產(chǎn)環(huán)境里會(huì)把程序搞掛的坑。適合已經(jīng)能寫基礎(chǔ) JNI 函數(shù)、但想深入掌握數(shù)組場(chǎng)景的 Android NDK / JNI 開發(fā)者?？赐昴隳苤苯佑眠@套思路重構(gòu)手里現(xiàn)有的數(shù)組相關(guān)代碼把內(nèi)存訪問和異常處理理順。1. JNI 數(shù)組操作的整體設(shè)計(jì)思路拆解1.1 為什么 JNI 數(shù)組操作是個(gè)“坑”先說個(gè)實(shí)際現(xiàn)象很多人在 Java 層寫了個(gè) int[] 傳給 native 方法然后 Native 代碼里直接 GetIntArrayElements 拿指針悶頭改完再 Release感覺一切正常。但上線之后發(fā)現(xiàn)兩種詭異 Bug——第一數(shù)組內(nèi)容在某些設(shè)備上改了沒生效第二更常見的偶爾直接崩日志里只有一行a JNI error has occurred。大部分問題都出在一個(gè)最基礎(chǔ)的概念上JNI 并沒有保證你拿到的數(shù)組元素指針就是 Java 堆里那份數(shù)據(jù)的指針。JNI 規(guī)范說得非常直白返回的指針可能是原始數(shù)據(jù)的直接指針也可能是一份臨時(shí)拷貝。這取決于虛擬機(jī)實(shí)現(xiàn)、數(shù)組類型、垃圾收集器狀態(tài)。也就是說你以為你在“改原數(shù)組”其實(shí)可能改的只是一塊副本如果改完沒有正確 Release這副本的變動(dòng)根本不會(huì)同步回 Java 層。所以整個(gè) JNI 數(shù)組編程的第一原則就是把你拿到的任何指針都當(dāng)成“可能是一份拷貝”來看待。在這個(gè)前提下所有關(guān)于鎖定、釋放、提交commit、臨界區(qū) API 的設(shè)計(jì)邏輯就都說得通了。1.2 核心 API 體系三組函數(shù)各管一攤JNI 的數(shù)組操作 API 大體可以分成三類我建議你在腦子里建立這個(gè)劃分類別代表函數(shù)適用場(chǎng)景元素訪問類GetIntArrayElements / ReleaseIntArrayElements基本類型數(shù)組通用場(chǎng)景區(qū)域讀寫類GetIntArrayRegion / SetIntArrayRegion只操作數(shù)組某一段避免全量拷貝臨界區(qū)類GetPrimitiveArrayCritical / ReleasePrimitiveArrayCritical性能敏感超大數(shù)組能接受短暫停頓對(duì)象數(shù)組類GetObjectArrayElement / SetObjectArrayElementString[]、自定義對(duì)象數(shù)組直接緩沖區(qū)NewDirectByteBuffer / GetDirectBufferAddress大塊連續(xù)內(nèi)存零拷貝這五組不是說越多越好而是每一類都有不可替代的使用場(chǎng)景。我見過很多代碼全程只用GetIntArrayElements連區(qū)域操作都不知道這在大數(shù)組場(chǎng)景里是真的浪費(fèi)。打個(gè)比方GetElements 就像你把整本書復(fù)印了一遍再讀GetArrayRegion則像只復(fù)印你需要的幾頁——當(dāng)數(shù)組很大而只需要處理其中一小段時(shí)性能差距非常直觀。2. 基本類型數(shù)組Get/Release 與臨界區(qū)的正確姿勢(shì)2.1 基礎(chǔ)用法GetIntArrayElements 和配套的 Release先看最標(biāo)準(zhǔn)的寫法。以本地方法接收一個(gè) int[]求和并返回為例JNIEXPORT jint JNICALL Java_com_example_NativeBridge_sumArray( JNIEnv *env, jobject thiz, jintArray arr) { if (arr nullptr) { return -1; } jsize len env-GetArrayLength(arr); jboolean isCopy JNI_FALSE; jint *elems env-GetIntArrayElements(arr, isCopy); if (elems nullptr) { // OOM 或虛擬機(jī)上鎖失敗 return -1; } jint sum 0; for (jsize i 0; i len; i) { sum elems[i]; } env-ReleaseIntArrayElements(arr, elems, 0); return sum; }幾點(diǎn)容易被忽略的細(xì)節(jié)返回值判空GetIntArrayElements不是一定成功的當(dāng)內(nèi)存不足或底層鎖失敗時(shí)可能返回 null。不判空直接訪問就是崩潰這種崩潰還特別難定位因?yàn)殄e(cuò)誤信息可能不會(huì)指向你這行。jsize是長(zhǎng)度類型它是帶符號(hào)的通常 32 位。不要跟 C/C 的 size_t 混用循環(huán)變量和數(shù)組索引都要注意符號(hào)匹配。每個(gè) Get 必須配對(duì) Release這個(gè)沒有例外。即使是提前 return也要先 Release 再 return否則就是內(nèi)存泄漏或鎖沒釋放。2.2 isCopy 參數(shù)到底在告訴你什么這個(gè)參數(shù)是我見過被忽略得最嚴(yán)重的一個(gè)。jboolean *isCopy是輸出參數(shù)虛擬機(jī)用它告訴你當(dāng)前拿到的指針到底是原始數(shù)據(jù)還是拷貝JNI_FALSE拿到的是原始內(nèi)存指針修改會(huì)直接反映到 Java 數(shù)組。JNI_TRUE拿到的是拷貝你改的是副本必須通過正確的 Release 模式把數(shù)據(jù)寫回去。但這里有個(gè)很實(shí)用的建議不要在業(yè)務(wù)邏輯里依賴 isCopy 做判斷。因?yàn)橥粋€(gè)數(shù)組、同一個(gè)虛擬機(jī)兩次調(diào)用可能返回不同的 isCopy 值——它受 GC 狀態(tài)影響。正確做法是無視它統(tǒng)一按“可能是拷貝”處理最后一定用 Release 把數(shù)據(jù)同步回去。2.3 Release 模式的三種選擇Release 函數(shù)的第三個(gè)參數(shù) mode 通常被草率地填 0但它其實(shí)有三種模式mode 值行為使用場(chǎng)景0將修改寫回 Java 數(shù)組釋放本地指針修改過數(shù)組內(nèi)容后JNI_COMMIT將修改寫回 Java 數(shù)組但不釋放本地指針需要多次修改、寫入一次性釋放JNI_ABORT不寫回修改僅釋放本地指針只讀數(shù)組或放棄修改說實(shí)話我日常寫代碼絕大多數(shù)時(shí)候就是 mode 0因?yàn)樗Z義最清楚修改寫回指針釋放。JNI_ABORT的典型場(chǎng)景是你拿數(shù)組指針只是為了做一次只讀計(jì)算比如統(tǒng)計(jì)總和、找最大值這類純讀邏輯根本不需要把內(nèi)容寫回此時(shí)用JNI_ABORT可以免掉一次可能的回寫拷貝。一個(gè)經(jīng)典的反面案例我在代碼審查里見過有人讀取數(shù)組算平均值Release 用的卻是 0。如果 isCopy 恰好是 JNI_TRUE那么 0 模式會(huì)把一份被改為原封不動(dòng)的副本回寫一次——這就是無意義的一整塊內(nèi)存拷貝。改成 JNI_ABORT 后性能在那段代碼上能快不少。JNI_COMMIT則適合頻繁修改的場(chǎng)景。比如你要在循環(huán)里多次更新數(shù)組內(nèi)容又不想每次更新都 Get/Release 一遍可以這樣jint *elems env-GetIntArrayElements(arr, nullptr); for (int iter 0; iter 10; iter) { // 修改 elems 內(nèi)容 env-ReleaseIntArrayElements(arr, elems, JNI_COMMIT); // 寫回但保留指針 } // 最終釋放 env-ReleaseIntArrayElements(arr, elems, 0);當(dāng)然這個(gè)場(chǎng)景有更優(yōu)的替代方案比如區(qū)域操作但 JNI_COMMIT 在兼容老代碼時(shí)很實(shí)用。2.4 GetPrimitiveArrayCritical臨界區(qū)的性能利刃如果數(shù)組非常大比如幾 MB 甚至幾十 MB每次 Get 都拷貝一次會(huì)很難受。JNI 提供了GetPrimitiveArrayCritical它有兩個(gè)目標(biāo)一是盡可能返回直接指針零拷貝二是讓 GC 在臨界區(qū)內(nèi)暫停對(duì)象移動(dòng)。JNIEXPORT jlong JNICALL Java_com_example_NativeBridge_sumLongArray( JNIEnv *env, jobject thiz, jlongArray arr) { jsize len env-GetArrayLength(arr); jboolean isCopy JNI_FALSE; jlong *elems env-GetPrimitiveArrayCritical(arr, isCopy); if (elems nullptr) return 0; jlong sum 0; for (jsize i 0; i len; i) sum elems[i]; env-ReleasePrimitiveArrayCritical(arr, elems, JNI_ABORT); return sum; }但這個(gè)名字里的 Critical 不是白叫的它對(duì)應(yīng)的使用約束極其嚴(yán)格在 Get 和 Release 之間不能調(diào)用任何可能阻塞的 JNI 函數(shù)——不能分配對(duì)象、不能調(diào)用 Java 方法、不能做文件 I/O、不能加鎖等待。這期間虛擬機(jī)為了復(fù)用內(nèi)存可能讓持有直接指針的調(diào)用線程住進(jìn)“GC 臨界區(qū)”如果你在里面 sleep 或調(diào) Java輕則死鎖重則崩。必須是配對(duì)使用不能跟 GetIntArrayElements 混用一個(gè)指針。只支持基本類型數(shù)組不支持對(duì)象數(shù)組。實(shí)踐經(jīng)驗(yàn)這個(gè) API 只適合“獲取指針 → 緊湊地處理 → 釋放”這種模式處理邏輯必須短小精悍。如果處理邏輯里面有日志輸出、回調(diào) Java、內(nèi)存分配那就老老實(shí)實(shí)用 GetIntArrayElements。3. 對(duì)象數(shù)組與二維數(shù)組的處理3.1 GetObjectArrayElement逐一持有對(duì)象數(shù)組比如 String[]沒有 GetElements 這種一次性拿全部指針的 API因?yàn)閷?duì)象數(shù)組的元素本身是引用C 側(cè)無法直接用連續(xù)內(nèi)存表示。你只能逐個(gè)獲取。JNIEXPORT jstring JNICALL Java_com_example_NativeBridge_getFirstString( JNIEnv *env, jobject thiz, jobjectArray arr) { jsize len env-GetArrayLength(arr); if (len 1) return nullptr; jobject first env-GetObjectArrayElement(arr, 0); if (first nullptr) { // 元素可能為 null或下標(biāo)越界 if (env-ExceptionCheck()) env-ExceptionClear(); return nullptr; } return static_castjstring(first); // 謹(jǐn)慎需確認(rèn)元素確實(shí)是 String }這里有兩個(gè)非常容易踩的雷第一元素類型檢查。如果 Java 層傳進(jìn)來的 array 是 Object[]你在 C 側(cè)強(qiáng)轉(zhuǎn)成 jstring 然后傳給需要 jstring 的函數(shù)在多數(shù)實(shí)現(xiàn)上不會(huì)立刻崩但行為未定義。更穩(wěn)妥的方式是用env-IsInstanceOf檢查類型或者直接把數(shù)組類型定死在 Java 層方法簽名里就用 String[]。第二局部引用溢出。在循環(huán)里 GetObjectArrayElement 獲取大量對(duì)象每個(gè)得到的 jobject 都是局部引用。局部引用表在 JNI 里的容量有限舊版本默認(rèn)只支持幾百個(gè)循環(huán)里聚集不釋放函數(shù)返回時(shí)會(huì)檢測(cè)到局部引用溢出。典型的如for (int i 0; i len; i) { jobject element env-GetObjectArrayElement(arr, i); // 處理 element env-DeleteLocalRef(element); // 必須手動(dòng)釋放 }至于為什么 GetObjectArrayElement 的索引越界會(huì)拋 ArrayIndexOutOfBoundsException而 GetArrayLength 不拋這得從 JNI 層對(duì)異常的處理說起。JNI 中絕大多數(shù)的 JNI 函數(shù)在出錯(cuò)后不會(huì)取消本地代碼執(zhí)行而是讓異常掛起。如果掛起異常后你繼續(xù)調(diào)用其他 JNI 函數(shù)行為是未定義的。所以每當(dāng)涉及 JNI 調(diào)用都要有“異?？赡苷趻炱稹钡木X。3.2 二維數(shù)組的“鋸齒”問題Java 的 int[][] 在 JNI 里其實(shí)是 jobjectArray每個(gè)元素又是一個(gè) jintArray。很多新人以為可以直接拿到一個(gè) int** 往下遍歷這是不可能的。JNIEXPORT jint JNICALL Java_com_example_NativeBridge_sum2DArray( JNIEnv *env, jobject thiz, jobjectArray outer) { jsize rows env-GetArrayLength(outer); jint total 0; for (jsize i 0; i rows; i) { jintArray inner static_castjintArray( env-GetObjectArrayElement(outer, i)); if (inner nullptr) continue; // 該行可能為 null jint *innerElems env-GetIntArrayElements(inner, nullptr); jsize cols env-GetArrayLength(inner); for (jsize j 0; j cols; j) { total innerElems[j]; } env-ReleaseIntArrayElements(inner, innerElems, JNI_ABORT); env-DeleteLocalRef(inner); } return total; }有一點(diǎn)要額外提醒二維數(shù)組每一行的長(zhǎng)度完全可能不一樣——這就是 Java 的“鋸齒數(shù)組”特性。你必須在遍歷時(shí)對(duì)每一行單獨(dú)取 GetArrayLength不能假設(shè)每個(gè) inner 都是相同大小。這也是二維數(shù)組性能優(yōu)化的難點(diǎn)外層是對(duì)象數(shù)組內(nèi)層才是基本類型數(shù)組如果你想一次性做批處理基本不可能只能一層層展開。如果性能真的很敏感建議不要用 jobjectArray 傳遞矩陣改用一維 int[] 加寬度高度參數(shù)C 側(cè)按行偏移計(jì)算。實(shí)戰(zhàn)中很多圖像處理庫都這樣設(shè)計(jì)接口不是為了省事而是避免每行一個(gè)對(duì)象引用的開銷和 GC 壓力。4. 直接緩沖區(qū)數(shù)組零拷貝的正確打開方式4.1 NewDirectByteBuffer從 Native 分配大塊內(nèi)存除了從 Java 數(shù)組復(fù)制數(shù)據(jù)JNI 還支持直接字節(jié)緩沖區(qū)DirectByteBuffer模式。這種模式下你可以在 native 側(cè)分配一塊內(nèi)存封裝成 ByteBuffer 返回給 Java或者接收 Java 層創(chuàng)建的 ByteBuffer直接拿到其內(nèi)存地址完全繞開拷貝。native 側(cè)分配并返回JNIEXPORT jobject JNICALL Java_com_example_NativeBridge_allocBuffer( JNIEnv *env, jobject thiz, jint size) { void *buf malloc(size); if (buf nullptr) return nullptr; // capacity 參數(shù)必須是正數(shù)long 類型的 address 在這里不傳而是用 buf return env-NewDirectByteBuffer(buf, size); }Java 側(cè)ByteBuffer buffer NativeBridge.allocBuffer(1024 * 1024);拿到這個(gè) buffer 后的地址native 側(cè)要訪問它時(shí)用GetDirectBufferAddressJNIEXPORT jlong JNICALL Java_com_example_NativeBridge_bufferAddress( JNIEnv *env, jobject thiz, jobject buffer) { return reinterpret_castjlong(env-GetDirectBufferAddress(buffer)); }要求注意的地方NewDirectByteBuffer分配后這塊內(nèi)存的釋放由 native 側(cè)負(fù)責(zé)必須記得在某個(gè)時(shí)機(jī) free否則就是內(nèi)存泄漏。這跟普通 JNI 數(shù)組的自動(dòng)回收完全不同。不是所有 JVM 都支持直接緩沖區(qū)Android 上支持但 API level 9 以下不支持現(xiàn)在基本不用考慮老版本。如果傳入的 jobject 不是 DirectByteBuffer 實(shí)例GetDirectBufferAddress返回 NULL。所以調(diào)用前先env-IsInstanceOf(buffer, clsDirectByteBuffer)判斷一下。直接緩沖區(qū)的使用場(chǎng)景很清晰音頻數(shù)據(jù)、圖像像素、協(xié)議包這類需要高頻讀寫的連續(xù)大塊數(shù)據(jù)用它就對(duì)了。Java 層持有一個(gè)ByteBuffernative 層直接內(nèi)存地址讀寫零拷貝性能最接近純 C 的水平。4.2 直接緩沖區(qū)與數(shù)組的配合什么時(shí)候不用它但直接緩沖區(qū)不適合所有場(chǎng)景。比如你需要頻繁隨機(jī)訪問小數(shù)組或者讀寫模式很離散那直接緩沖區(qū)的地址運(yùn)算和 byte 級(jí)的位操作反而容易寫錯(cuò)不如普通 JNI 數(shù)組方便。我一般這樣取舍數(shù)據(jù)量小64KB且讀寫模式簡(jiǎn)單用 GetIntArrayElements 或 GetArrayRegion。數(shù)據(jù)量中等64KB ~ 幾 MB且處理邏輯不阻塞用 GetPrimitiveArrayCritical。數(shù)據(jù)量大、跨多次 JNI 調(diào)用、希望零拷貝直接用 DirectByteBuffer。注意不管選擇哪種方式JNI 數(shù)組操作中數(shù)據(jù)一致性始終是首要問題。你從 Java 拿一個(gè)數(shù)組在 native 改了必須確保 Java 層能看到改動(dòng)或者明確知道自己看不到。在 Get/Release 的語境下Release 時(shí)用模式 0 或 JNI_COMMIT 就能保證寫回。在 DirectByteBuffer 語境下天然零拷貝但要注意多線程并發(fā)訪問同一塊緩沖區(qū)的同步問題JNI 不會(huì)幫你做任何內(nèi)存屏障。5. 數(shù)組的創(chuàng)建與區(qū)域讀寫5.1 NewIntArray 與 SetIntArrayRegion從 Native 構(gòu)造數(shù)組native 代碼不只是消費(fèi) Java 傳進(jìn)來的數(shù)組還經(jīng)常需要?jiǎng)?chuàng)建數(shù)組返回出去。最常用的一套組合是NewIntArray配上SetIntArrayRegionJNIEXPORT jintArray JNICALL Java_com_example_NativeBridge_generateIntArray( JNIEnv *env, jobject thiz, jint size) { jintArray result env-NewIntArray(size); if (result nullptr) { // 拋 OutOfMemoryError return nullptr; } std::vectorjint tmp(size); for (jint i 0; i size; i) { tmp[i] i * i; } env-SetIntArrayRegion(result, 0, size, tmp.data()); return result; }用SetIntArrayRegion而不是GetIntArrayElements寫數(shù)據(jù)最大的好處是你不需要請(qǐng)求整塊內(nèi)存的指針可以分多次往不同位置寫也避免了每次只改一個(gè)元素時(shí)獲取指針的開銷。底層實(shí)現(xiàn)是 memcpy速度快。NewXxxArray回來的數(shù)組初始值是全零而不是未定義內(nèi)容這一點(diǎn)值得確認(rèn)。如果業(yè)務(wù)邏輯依賴“先清零”的語義可以省掉一個(gè) memset。5.2 GetIntArrayRegion局部讀的優(yōu)雅方案與 Set 對(duì)應(yīng)的是GetIntArrayRegion它專門用于只讀取數(shù)組的一部分。用法JNIEXPORT jint JNICALL Java_com_example_NativeBridge_readRange( JNIEnv *env, jobject thiz, jintArray arr, jsize start, jsize len) { std::vectorjint buf(len); env-GetIntArrayRegion(arr, start, len, buf.data()); if (env-ExceptionCheck()) { // 通常下標(biāo)越界 env-ExceptionDescribe(); env-ExceptionClear(); return -1; } jint maxVal buf[0]; for (jsize i 1; i len; i) maxVal std::max(maxVal, buf[i]); return maxVal; }這段代碼有個(gè)隱藏問題GetIntArrayRegion在越界時(shí)會(huì)拋出ArrayIndexOutOfBoundsExceptionJNI 函數(shù)掛起異常后返回。很多新手繼續(xù)往下走此時(shí) buf 里的數(shù)據(jù)是未定義的可能算出一個(gè)錯(cuò)的極值如果不處理異常直接 returnJava 層會(huì)收到這個(gè)掛起異?！谀承﹫?chǎng)景下會(huì)導(dǎo)致整個(gè)進(jìn)程異常。所以區(qū)域操作后一定要檢查ExceptionCheck。對(duì)比一下兩個(gè) API 的定位GetArrayRegion適合只讀指定區(qū)間不需要先拿到整個(gè)數(shù)組的指針代碼更安全不存在“指針懸浮”的問題。GetArrayElements適合需要隨機(jī)反復(fù)訪問整個(gè)數(shù)組的場(chǎng)景一次拿指針多次訪問。釋放時(shí)寫回或放棄由你決定。5.3 用數(shù)組方法簽名時(shí)的一個(gè)細(xì)節(jié)如果你在 native 方法簽名里聲明jintArrayJava 側(cè)調(diào)用時(shí)傳的是int[]這個(gè)沒問題。但如果你想返回一個(gè)由 native 創(chuàng)建的數(shù)組別忘記返回類型必須匹配。我見過有人返回jobject然后 Java 層類型寫int[]編譯符號(hào)可以過但運(yùn)行時(shí)是類型不匹配直接拋ArrayStoreException或更惡心的a JNI error has occurred。關(guān)于這個(gè)錯(cuò)誤其實(shí)值得單獨(dú)展開。它在不同環(huán)境下的具體表現(xiàn)差異很大在 Android 上經(jīng)常是日志art::JNI相關(guān)的一個(gè)崩潰棧在桌面 JVM 上則是A fatal error has been detected by the Java Runtime Environment暗示是 native 代碼 bug。多數(shù)情況下不是數(shù)組類型匹配問題而是別的更深層問題下一部分詳細(xì)說。6. 常見問題排查與避坑實(shí)錄6.1error: a JNI error has occurred, please check your installation and try again的排查思路這個(gè)報(bào)錯(cuò)是 JNI 新手最容易搜到的但它往往并不是指“JNI 環(huán)境裝錯(cuò)了”。在桌面 JVM 上這個(gè)錯(cuò)誤通常意味著native 方法名解析失敗也就是 Java 層聲明的native方法和 C 層函數(shù)對(duì)不上符號(hào)。native 函數(shù)拋出異常后沒處理JNI 調(diào)用鏈返回后直擊 JVM。更隱蔽的在數(shù)組操作中某個(gè) JNI 函數(shù)調(diào)用后沒有檢查異常比如GetIntArrayRegion越界后異常掛起隨后又調(diào)用了其他 JNI 函數(shù)行為未定義——有的虛擬機(jī)干脆直接終止進(jìn)程報(bào)這個(gè)通用錯(cuò)誤。排查步驟我建議按這個(gè)順序來先看完整堆棧別只看第一行。確認(rèn) native 庫加載路徑正確System.loadLibrary的庫名和實(shí)際 so/dll 名稱是否匹配。在 C 側(cè)每個(gè) JNI 調(diào)用后加if (env-ExceptionCheck()) env-ExceptionDescribe();臨時(shí)定位異常源頭。檢查所有 Get 是否有對(duì)應(yīng)的 Release所有函數(shù)返回值是否判空。如果是數(shù)組操作后崩重點(diǎn)檢查索引是否越界以及GetArrayLength是否對(duì)空數(shù)組調(diào)用。6.2 GetArrayLength 與空數(shù)組的邊界GetArrayLength對(duì) null 數(shù)組調(diào)用會(huì)返回 0 嗎不會(huì)。如果 arr 為 null調(diào)用GetArrayLength會(huì)拋出空指針異常。所以在 JNI 函數(shù)入口處先判空永遠(yuǎn)是第一件事。這一點(diǎn)在 C/C 側(cè)尤其容易被忽略因?yàn)?C 里傳 nullptr 很常見而 Java 側(cè)可能因?yàn)橐恍┛蚣茏詣?dòng)傳空數(shù)組過來。防御性編程在這里不是可選項(xiàng)而是必選項(xiàng)。另外要小心GetArrayLength返回的長(zhǎng)度類型是jsize它是 int 類型。如果你把它賦值給size_t在 64 位平臺(tái)如果長(zhǎng)度是負(fù)數(shù)不太可能但類型是帶符號(hào)的會(huì)發(fā)生符號(hào)擴(kuò)展的問題。穩(wěn)妥一點(diǎn)統(tǒng)一用jsize或用jsize len env-GetArrayLength(arr);。6.3 在 Clion 中配置 JNI 環(huán)境的幾個(gè)關(guān)鍵點(diǎn)CLion 是常用的 JNI 開發(fā) IDE但默認(rèn)它對(duì) JNI 頭文件的支持并不好。網(wǎng)上搜到這個(gè)熱詞說明踩坑的人不少。簡(jiǎn)易配置步驟安裝 JDK把JAVA_HOME環(huán)境變量設(shè)置好。在 CMakeLists.txt 中添加頭文件路徑和庫路徑find_package(JNI REQUIRED) include_directories(${JNI_INCLUDE_DIRS})或者手動(dòng)指定include_directories( $ENV{JAVA_HOME}/include $ENV{JAVA_HOME}/include/darwin # macOS $ENV{JAVA_HOME}/include/linux # Linux $ENV{JAVA_HOME}/include/win32 # Windows )生成頭文件的命令一般是javac -h ./jnih NativeBridge.java這個(gè)命令在 JDK 8 之后是替代javah的標(biāo)準(zhǔn)方式。在 CLion 里如果你打開項(xiàng)目時(shí)頭文件爆紅確認(rèn)是 JDK 的 include 目錄沒加對(duì)。Linux 和 macOS 的 jni_md.h 路徑不同這是最常見的配置錯(cuò)誤。6.4 數(shù)組相關(guān) JNI 異常速查表問題現(xiàn)象可能原因解決方案數(shù)組內(nèi)容修改后 Java 層沒變化Release 使用了 JNI_ABORT或忘記 Release改用 mode 0 / JNI_COMMIT修改數(shù)組時(shí)崩潰下標(biāo)越界嚴(yán)格用 GetArrayLength 約束循環(huán)尤其注意二維數(shù)組內(nèi)層長(zhǎng)度大量循環(huán)處理對(duì)象數(shù)組后崩潰局部引用表溢出循環(huán)內(nèi)手動(dòng) DeleteLocalRefGetArrayRegion 后數(shù)據(jù)隨機(jī)越界后未處理異常調(diào)用后檢查 ExceptionCheckNewDirectByteBuffer 返回對(duì)象無法 get 地址不是 DirectByteBuffer或內(nèi)存申請(qǐng)失敗檢查類型判空桌面 JVM 報(bào) a JNI error方法簽名不匹配 / 異常掛起核對(duì) javah -h 生成的簽名檢查異常處理6.5 幾條實(shí)操心得最后分享幾個(gè)我自己寫 JNI 數(shù)組操作的固定習(xí)慣。第一能不拿指針就不拿指針。很多數(shù)組讀取用 GetArrayRegion 就夠了不要總是 GetArrayElements。指針拿得越少生命周期管理越簡(jiǎn)單出錯(cuò)可能性越低。代碼可讀性也更高。第二把寫入數(shù)據(jù)和釋放分開思考。釋放的 mode 取決于你是否修改了內(nèi)容而不是取決于你當(dāng)時(shí)的心情。修改了就用 0只讀就用 JNI_ABORT。這是最簡(jiǎn)單的判斷標(biāo)準(zhǔn)。第三對(duì)象數(shù)組的局部引用一定是用完即刪。尤其在 Android 這樣的系統(tǒng)上JNI 局部引用表管理不好不是崩潰就是 GC 壓力大。我見過一個(gè)圖像標(biāo)注項(xiàng)目循環(huán)里讀了 2000 個(gè) String 沒 DeleteLocalRef頻繁調(diào)用后 CPU 占用和內(nèi)存直接飆升最后就是逐行排查引用泄漏才定位到。第四性能調(diào)優(yōu)時(shí)先用 region 統(tǒng)計(jì)別急著上 Critical。先明確數(shù)組到底多大、每次操作頻率多高再用GetPrimitiveArrayCritical。這 API 屬于“高手向”一旦誤用會(huì)出現(xiàn)從死鎖到隨機(jī)崩潰等致命問題。第五JNI 數(shù)組操作的同步問題。默認(rèn)情況下Java 層對(duì)該數(shù)組的并發(fā)修改和 native 層對(duì)它的操作沒有同步保護(hù)。如果多線程同時(shí)操作同一個(gè) JNI 數(shù)組最壞情況下是數(shù)據(jù)競(jìng)態(tài)甚至虛擬機(jī)崩潰。建議在 Java 層通過 synchronized 或讓 native 層自己用 mutex雙保險(xiǎn)。根據(jù)我這些年踩坑的經(jīng)驗(yàn)JNI 數(shù)組操作最大的趨勢(shì)就是“盡可能減少跨邊界的數(shù)據(jù)搬運(yùn)”。Java 與 C 之間本來就是一堵墻數(shù)組是數(shù)據(jù)量最大的跨界形式之一。理解拷貝機(jī)制、掌握臨界區(qū)和直接緩沖區(qū)、警惕局部引用和異常掛起——這四件事做好了數(shù)組這塊基本就穩(wěn)了。