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