第一次用java.lang.foreign做原生調(diào)用那陣子我跑一個(gè)連strlen都算不上復(fù)雜的最小示例結(jié)果控制臺(tái)沒輸出反而甩出來一段警告WARNING: A restricted method in java.lang.foreign has been called.后面還跟著一句提示意思是“請(qǐng)考慮在啟動(dòng)參數(shù)里加上--enable-native-access”。我當(dāng)時(shí)腦子里全是問號(hào)代碼里沒設(shè)密碼、沒建用戶組、沒碰安全策略文件怎么突然就冒出來一個(gè)“檢查權(quán)限”的提示這和我理解的文件權(quán)限、用戶權(quán)限完全不是一回事。后來把整條鏈路啃明白之后才發(fā)現(xiàn)這個(gè)“檢查權(quán)限”背后是一套既簡單又容易被忽略的機(jī)制。它不問“你是誰”而問“你所在的模塊有沒有被明確授權(quán)”。如果你也在用 FFM API或者正在把舊代碼從 JNI 遷移到j(luò)ava.lang.foreign這篇文章應(yīng)該能幫你省下大量排查時(shí)間。1. 報(bào)錯(cuò)信息里藏著的那道檢查門1.1 一次并不罕見的踩雷經(jīng)歷先還原一下當(dāng)時(shí)的場(chǎng)景。我用的是較新的 JDK寫了一個(gè)非常標(biāo)準(zhǔn)的strlen調(diào)用import java.lang.foreign.*; import java.lang.invoke.MethodHandle; public class NativeDemo { public static void main(String[] args) throws Throwable { Linker linker Linker.nativeLinker(); SymbolLookup lookup linker.defaultLookup(); MethodHandle strlen linker.downcallHandle( lookup.find(strlen).orElseThrow(), FunctionDescriptor.of(JAVA_LONG, ADDRESS) ); try (Arena arena Arena.ofConfined()) { MemorySegment message arena.allocateFrom(hello); long len (long) strlen.invoke(message.address()); System.out.println(len len); } } }代碼本身沒有任何問題正常編譯正常啟動(dòng)?？墒窃跓o條件運(yùn)行的時(shí)候終端里出現(xiàn)了警告在某些新版本里干脆直接拋出一個(gè)IllegalCallerException堆棧信息大致是這個(gè)形貌Exception in thread main java.lang.IllegalCallerException: Illegal caller第一次看到這個(gè)異常名稱很容易往“Java 安全檢查”方向想。但注意這里沒有SecurityManager沒有AccessController也沒有任何配置文件。它檢查的不是沙箱策略而是模塊系統(tǒng)里的一項(xiàng)授權(quán)標(biāo)記。1.2 什么是 restricted method它到底在檢查什么java.lang.foreign里有一批方法被官方標(biāo)注為“受限方法restricted method”。典型代表就是上面用到的Linker.downcallHandle此外還包括MemorySegment.reinterpret、MemorySegment.address這類能直接操作原始地址的方法。為什么要給它們單獨(dú)做一層標(biāo)記因?yàn)檫@類方法一旦被調(diào)用實(shí)際上就跳過了 Java 的世界直接進(jìn)入原生層。原生層沒有數(shù)組越界檢查、沒有 GC 托底、沒有類型安全一個(gè)指針寫錯(cuò)就能讓整個(gè) JVM 進(jìn)程崩潰甚至污染進(jìn)程內(nèi)存。所以 JDK 在這里加了一道“調(diào)用者核驗(yàn)”的門調(diào)用受限方法時(shí)JVM 會(huì)檢查“當(dāng)前調(diào)用代碼到底屬于哪個(gè)模塊”然后看這個(gè)模塊有沒有被顯式授權(quán)訪問原生層。如果沒有授權(quán)表現(xiàn)就是開頭那種警告或者在新版本里直接拋IllegalCallerException。這里要特別強(qiáng)調(diào)它檢查的“權(quán)限”不在代碼類上也不在某個(gè)對(duì)象上而在模塊上。你用 IDE 直接右鍵運(yùn)行一個(gè)普通 Java 類它屬于“未命名模塊unnamed module”你用module-info.java打了一個(gè) jar 包跑起來它屬于某個(gè)命名模塊。這兩類模塊在原生訪問授權(quán)上的待遇完全不同。2. 三種檢查從模塊聲明到 JVM 參數(shù)再到內(nèi)存段2.1 第一道門模塊系統(tǒng)對(duì)調(diào)用者身份的核驗(yàn)很多人會(huì)把注意力全放在--enable-native-access參數(shù)上但我要先潑一盆冷水這個(gè)參數(shù)只是第一道門的一部分。Java 9 引入模塊系統(tǒng)之后“你的代碼住在哪個(gè)模塊”就成了一切授權(quán)的前提。對(duì)java.lang.foreign來說從 JDK 22 正式版開始API 已經(jīng)移到了java.base模塊里所以你在module-info.java里通常不需要顯式寫requires java.lang.foreign——因?yàn)樗驮诨A(chǔ)模塊里。這一點(diǎn)和早期孵化版不一樣。早期版本包名是jdk.incubator.foreign那時(shí)候模塊聲明里必須加module my.module { requires jdk.incubator.foreign; }很多人從老教程里抄來這段結(jié)果在新版本里發(fā)現(xiàn)jdk.incubator.foreign這個(gè)模塊根本不存在或者包名對(duì)不上于是開始懷疑自己的模塊配置。真正和“檢查權(quán)限”強(qiáng)相關(guān)的是這個(gè)事實(shí)即使 API 本身在java.base訪問原生函數(shù)的行為仍然被額外控制。JVM 在調(diào)用受限方法時(shí)取的是調(diào)用者模塊而不是 API 聲明所在模塊。換句話說API 放在哪個(gè)包里不重要重要的是“誰在調(diào)用”。判斷調(diào)用者模塊的過程實(shí)現(xiàn)層用了StackWalker去掃描調(diào)用棧。這也是為什么在堆棧信息里官方建議信息寫的是“Please consider adding--enable-native-accessto the command line for your module”。它不是在指 JDK 內(nèi)部模塊而是在指你自己的模塊名。2.2 第二道門--enable-native-access的顯式授權(quán)這是整個(gè)機(jī)制里最核心的一道開關(guān)。它的作用就是提前告訴 JVM我允許某些模塊里的代碼執(zhí)行原生訪問。命令行寫法是這樣的java --enable-native-accessALL-UNNAMED -cp . NativeDemoALL-UNNAMED是一個(gè)特殊標(biāo)記代表“所有未命名模塊”。只要你沒有寫module-info.java代碼就跑在未命名模塊里這個(gè)參數(shù)就能讓普通的 classpath 應(yīng)用被授權(quán)。如果項(xiàng)目已經(jīng)模塊化了模塊名是com.example.app可以精確授權(quán)java --enable-native-accesscom.example.app -p mods -m com.example.app/com.example.app.Main授權(quán)范圍是累加的可以用逗號(hào)分隔多個(gè)模塊java --enable-native-accesscom.example.core,com.example.app -p mods -m com.example.app/com.example.app.Main如果完全沒有加這個(gè)參數(shù)在 JDK 22/23 里首次調(diào)用受限方法時(shí)會(huì)打印警告程序還能繼續(xù)跑但在 JDK 24 及之后的版本未授權(quán)模塊會(huì)直接收到IllegalCallerException。這也是為什么網(wǎng)上文章和代碼片段給出的結(jié)論經(jīng)常互相矛盾——大家用的 JDK 版本不一樣看到的默認(rèn)行為當(dāng)然不一樣。還有個(gè)細(xì)節(jié)很容易被忽略--enable-native-access只在啟動(dòng) JVM 時(shí)有效不能靠代碼里的System.setProperty去動(dòng)態(tài)開啟。你想要授權(quán)就必須在java命令、IDE 運(yùn)行配置、構(gòu)建工具的 JVM 參數(shù)里把它寫進(jìn)去。2.3 第三道門MemorySegment 生命周期與訪問模式檢查除了入口處的受限方法檢查java.lang.foreign內(nèi)部還有另一類“權(quán)限感”很強(qiáng)的檢查那就是MemorySegment的訪問約束。Arena分為受限 Arenaconfined和共享 Arenashared。用Arena.ofConfined()創(chuàng)建的受限 Arena只能在創(chuàng)建它的線程里訪問別的線程一旦碰它立刻拋出WrongThreadException。這就是一種強(qiáng)制的線程擁有權(quán)檢查。Arena 關(guān)閉之后所有由它分配出來的MemorySegment會(huì)立刻變成無效狀態(tài)。繼續(xù)訪問會(huì)拋IllegalStateException錯(cuò)誤消息類似“Segment is already closed”。這相當(dāng)于資源生命周期上的權(quán)限鎖你拿著一個(gè)已經(jīng)釋放的內(nèi)存段的地址去訪問在下層原生代碼里可能就是釋放后再使用use-after-free漏洞Java 層這里直接攔住。我在遷移 JNI 代碼的時(shí)候?qū)@種設(shè)計(jì)特別有感觸。JNI 里只要DeleteLocalRef時(shí)機(jī)不對(duì)經(jīng)常會(huì)遇到摸不著頭腦的崩潰而java.lang.foreign的 Arena 模型把分配、使用、釋放圈在同一個(gè)作用域里不合規(guī)就報(bào)異常不會(huì)讓你帶著壞引用一路沖到原生層。3. 完整配置姿勢(shì)讓原生訪問合法放行3.1 命令行與構(gòu)建工具怎么寫先明確一點(diǎn)不要用“每次運(yùn)行前手動(dòng)敲參數(shù)”這種方式當(dāng)長期方案要把它固化到構(gòu)建配置里。我用 Maven 時(shí)會(huì)這樣配exec-maven-pluginplugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId version3.2.0/version configuration mainClasscom.example.NativeDemo/mainClass arguments argument--enable-native-accessALL-UNNAMED/argument /arguments /configuration /plugin等等上面這種寫法是錯(cuò)的。exec-maven-plugin的arguments是傳給程序主類的參數(shù)不是 JVM 參數(shù)。JVM 參數(shù)要寫在jvmArguments里或者通過MAVEN_OPTS傳。正確配置是plugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId version3.2.0/version configuration mainClasscom.example.NativeDemo/mainClass jvmArguments--enable-native-accessALL-UNNAMED/jvmArguments /configuration /plugin這個(gè)區(qū)分很重要我見過不止一個(gè)人把參數(shù)寫到arguments里結(jié)果程序收到的仍然是空參數(shù)警告照舊。如果你用 Gradle可以直接在JavaExec任務(wù)里加tasks.named(run) { jvmArgs --enable-native-accessALL-UNNAMED }測(cè)試場(chǎng)景同樣要處理。用 JUnit 跑單元測(cè)試時(shí)Surefire 默認(rèn)會(huì) fork 一個(gè) JVM這時(shí)候必須給 fork 的進(jìn)程加參數(shù)不然主運(yùn)行配置配好了測(cè)試?yán)镎諛訄?bào)警告plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration argLine--enable-native-accessALL-UNNAMED/argLine /configuration /pluginGradle 的 Test 任務(wù)也要單獨(dú)設(shè)置tasks.withType(Test).configureEach { jvmArgs --enable-native-accessALL-UNNAMED }注意到一個(gè)反向業(yè)務(wù)了嗎這不是“給程序加個(gè)開關(guān)”這么簡單凡是會(huì)啟動(dòng)新 JVM 的場(chǎng)景都得分別配一遍運(yùn)行、測(cè)試、jlink出來的鏡像、IDE 的調(diào)試會(huì)話一個(gè)都不能漏。3.2 module-info.java 中的聲明細(xì)節(jié)如果你的項(xiàng)目還是 classpath 應(yīng)用ALL-UNNAMED就夠了。但一旦你決定模塊化就要考慮如果每次都用ALL-UNNAMED其實(shí)是一種很粗放的授權(quán)方式——它把所有未命名代碼都放進(jìn)了白名單。更好的做法是給每個(gè)模塊精確授權(quán)。假設(shè)項(xiàng)目結(jié)構(gòu)是這樣src/ com.example.core/ // 核心模塊封裝原生調(diào)用 com.example.app/ // 應(yīng)用模塊只調(diào)用 core 的接口core模塊里的module-info.java可能是module com.example.core { exports com.example.core.nativebridge; }core模塊內(nèi)部真正調(diào)用Linker.nativeLinker()的類必須能訪問java.lang.foreign。前面講過JDK 22 之后 API 在java.base所以不需要額外requires。但如果你為了兼容還在用 JDK 17/21 的孵化 APImodule-info.java就要加module com.example.core { requires jdk.incubator.foreign; exports com.example.core.nativebridge; }啟動(dòng)時(shí)精確授權(quán)的寫法是java --enable-native-accesscom.example.core \ -p mods \ -m com.example.app/com.example.Main注意應(yīng)用模塊com.example.app本身沒碰受限方法所以不需要給它授權(quán)。這道門只認(rèn)“真正調(diào)用受限方法的那個(gè)模塊”。3.3 多模塊項(xiàng)目里授權(quán)范圍的選擇這里要談一個(gè)實(shí)際經(jīng)驗(yàn)?zāi)膫€(gè)模塊該被授權(quán)我的判斷標(biāo)準(zhǔn)是誰直接調(diào)用java.lang.foreignAPI誰就需要被授權(quán)。如果模塊 A 里寫了Linker.nativeLinker()那就給 A 授權(quán)。如果模塊 B 只是通過普通 Java 接口調(diào) A 的方法B 跟原生層沒有任何直接接觸不需要授權(quán)。最忌諱的做法是為了省事把所有模塊全部塞進(jìn)名單或者干脆--enable-native-accessALL-UNNAMED一勞永逸。短期沒問題長期會(huì)降低問題的可定位性——一旦有依賴庫偷偷調(diào)用原生代碼你不會(huì)知道是從誰那里進(jìn)來的。還有種特殊情況如果你把某個(gè) jar 放在 classpath 而不是 module path那它就是自動(dòng)模塊。自動(dòng)模塊的名字默認(rèn)從 jar 文件名推導(dǎo)而且自動(dòng)模塊默認(rèn)也會(huì)讀取所有模塊屬于“特權(quán)階級(jí)”。我不建議為了規(guī)避授權(quán)問題而故意把 jar 丟到 classpath 去當(dāng)自動(dòng)模塊那相當(dāng)于關(guān)掉了模塊系統(tǒng)的邊界和你安裝這個(gè) API 的安全初衷相悖。4. 這道檢查究竟在防什么4.1 原生內(nèi)存不是 Java 的游樂場(chǎng)“為什么不直接讓我調(diào)”這是很多人的第一反應(yīng)。答案其實(shí)很實(shí)在原生層一個(gè)問題就能讓 JVM 原地消失。Java 世界里你寫array[100]越界了拋ArrayIndexOutOfBoundsException你寫segment.get(ValueLayout.JAVA_INT, 99999)Java 層會(huì)根據(jù) segment 范圍做邊界檢查非法訪問照樣拋異常。但一旦把MemorySegment.address()傳給原生函數(shù)原生函數(shù)內(nèi)部的行為 Java 完全管不住。它可能按錯(cuò)誤的偏移量寫一片內(nèi)存可能踩在堆管理結(jié)構(gòu)上甚至可能寫壞另一個(gè) Java 對(duì)象背后的數(shù)據(jù)。我在一次測(cè)試?yán)锕室庾屧瘮?shù)越界寫了幾字節(jié)結(jié)果不是報(bào)錯(cuò)而是直接 core dump。那一刻我才真正理解為什么 JVM 要卡住“未授權(quán)模塊的受限方法調(diào)用”。這不是為了給你添麻煩而是為了確保每個(gè)要進(jìn)入原生層的人都明確知道你正在離開 Java 的安全托底區(qū)。這套檢查和普通 Java 方法調(diào)用的開銷還不太一樣。它發(fā)生在方法入口用模塊元數(shù)據(jù)做一次一次性的狀態(tài)判斷而不是在每一次內(nèi)存訪問時(shí)都做細(xì)粒度的權(quán)限枚舉。實(shí)際調(diào)用鏈路里真正高頻的指針讀寫是不做逐次權(quán)限檢查的性能敏感路徑?jīng)]有受拖累。4.2 和傳統(tǒng) SecurityManager 權(quán)限的區(qū)別如果你經(jīng)歷過 Java 老版本可能會(huì)想起SecurityManager里的checkLink、checkPropertyAccess這些方法。那是另外一套體系由全局安全管理器去讀策略文件逐條詢問“這次加載原生庫的操作合規(guī)嗎”。java.lang.foreign的檢查跟它完全不是一個(gè)物種。SecurityManager 是運(yùn)行時(shí)策略系統(tǒng)需要顯式安裝安全管理器維護(hù)策略文件而且能做的事很多很細(xì)。而 native access 檢查更接近“構(gòu)建期契約”你的模塊要么一開始就被 JVM 參數(shù)點(diǎn)名授權(quán)要么就不能調(diào)用受限方法。沒有中間地帶不需要運(yùn)行時(shí)問詢也沒有策略文件熱加載。換句話說SecurityManager 像小區(qū)保安逐個(gè)盤問訪客而--enable-native-access更像是發(fā)門禁卡。發(fā)卡名單在啟動(dòng)那一刻就定了進(jìn)不來的從一開始就進(jìn)不來。4.3 從警告到硬性報(bào)錯(cuò)的演進(jìn)邏輯理解這個(gè)機(jī)制最好的方式是順著 JDK 的演進(jìn)看一遍。JDK 22 正式把 Foreign Function Memory API 放進(jìn)java.lang.foreign同時(shí)規(guī)定了受限方法規(guī)則。但為了給生態(tài)過渡時(shí)間默認(rèn)行為只是打印警告。你什么都不配代碼也能跑只是終端里會(huì)有一條礙眼的 WARNING。到了 JDK 24事情變了。未授權(quán)模塊一旦調(diào)用受限方法直接拋IllegalCallerException不再給警告放行。為什么這么硬我個(gè)人的理解是警告是可以被忽略的但異常是不能被忽略的。如果在正式環(huán)境里某個(gè)第三方庫悄悄用了原生調(diào)用只打警告的話運(yùn)維日志可能被刷屏但服務(wù)還在跑問題被淹沒。一旦變成硬異常庫作者就必須在文檔里寫明“請(qǐng)?jiān)趩?dòng)時(shí)加上授權(quán)參數(shù)”應(yīng)用方也必須認(rèn)真對(duì)待每一次原生調(diào)用。這屬于典型的“用技術(shù)手段逼出明確的依賴關(guān)系”。我見過不少團(tuán)隊(duì)在 JDK 21 上升級(jí)到新 API日志里出現(xiàn)警告也沒當(dāng)回事等項(xiàng)目換到 JDK 24 突然崩了才反過頭配置參數(shù)。早一點(diǎn)把規(guī)則看懂后面就能少一次線上事故。5. 一個(gè)報(bào)錯(cuò)的完整排查鏈路5.1 最小復(fù)現(xiàn)場(chǎng)景與錯(cuò)誤輸出假設(shè)你從網(wǎng)上抄了一段代碼在本地跑起來終端里出現(xiàn)類似下面的輸出WARNING: A restricted method in java.lang.foreign has been called. WARNING: Please consider adding --enable-native-access to the command line.如果是在 JDK 24 上會(huì)變成Exception in thread main java.lang.IllegalCallerException: Illegal caller at java.base/java.lang.foreign.Linker.downcallHandle(Linker.java:186) at com.example.NativeDemo.main(NativeDemo.java:12)堆棧指向你項(xiàng)目里的主類但異常類型是IllegalCallerException。這時(shí)候第一反應(yīng)是去查Linker.java是不是有 bug——沒有真正的問題在你自己模塊。5.2 從報(bào)錯(cuò)到定位再到補(bǔ)授權(quán)先別急著加參數(shù)。第一步用下面這條命令確認(rèn)自己當(dāng)前代碼所在模塊java --module-path mods --list-modules | grep com.example或者直接在代碼里打印模塊信息System.out.println(NativeDemo.class.getModule().getName());如果沒有打印出模塊名說明代碼在未命名模塊里跑那授權(quán)目標(biāo)是ALL-UNNAMED如果有模塊名就用模塊名授權(quán)。第二步看堆棧里的調(diào)用點(diǎn)。堆棧最頂層可能顯示Linker.downcallHandle下面跟著你的調(diào)用類。調(diào)用類所在模塊就是要授權(quán)的模塊。如果堆棧里出現(xiàn)一層代理、一層反射就以代理對(duì)象所屬模塊為準(zhǔn)還是那句老話誰直接調(diào)受限方法誰拿授權(quán)。第三步補(bǔ)授權(quán)。未命名模塊java --enable-native-accessALL-UNNAMED -cp . NativeDemo命名模塊java --enable-native-accesscom.example.app -p mods -m com.example.app/com.example.Main5.3 修完后如何驗(yàn)證配置好以后重新啟動(dòng)。如果終端里那條 WARNING 消失了說明授權(quán)生效。如果你想確認(rèn)某個(gè)模塊到底有沒有被授權(quán)可以在代碼里臨時(shí)打印一下System.out.println(NativeDemo.class.getModule().isNativeAccessEnabled());Module.isNativeAccessEnabled()這個(gè)方法直接返回布爾值是最快速的驗(yàn)證方式。不過我建議把這種臨時(shí)調(diào)試輸出刪干凈因?yàn)樯a(chǎn)日志里塞個(gè)true/false沒有意義。還有個(gè)小坑如果你用 IDE 啟動(dòng)改了命令行參數(shù)但沒重啟 IDE 的 Java 進(jìn)程配置可能不生效。正常的調(diào)試流程是先看 IDE 的“Run Configuration”里 JVM 參數(shù)有沒有同步更新再跑一次。6. 版本差異與實(shí)際使用經(jīng)驗(yàn)6.1 不同 JDK 版本下的默認(rèn)行為對(duì)照這是我踩過坑以后整理出的對(duì)照直接給你JDK 版本包名/模塊未授權(quán)調(diào)用受限方法需要添加的啟動(dòng)參數(shù)JDK 16-18jdk.incubator.foreign基本沒有強(qiáng)約束孵化期行為一直在調(diào)整早期版本無需JDK 19-21jdk.incubator.foreignAPI 重新設(shè)計(jì)部分版本已經(jīng)開始提示推薦參數(shù)推薦--enable-native-accessJDK 22-23java.lang.foreign正式版打印 WARNING不阻止執(zhí)行--enable-native-access模塊名或ALL-UNNAMEDJDK 24java.lang.foreign正式版直接拋IllegalCallerException必須提前配置這個(gè)表格里最關(guān)鍵的分水嶺是 JDK 22 和 JDK 24。JDK 22 是 API 正式化JDK 24 是強(qiáng)制化。如果你的目標(biāo)運(yùn)行環(huán)境跨度比較大最穩(wěn)妥的做法是“永遠(yuǎn)顯式寫參數(shù)”不要依賴默認(rèn)行為。另外提醒一句老教程里常用的CLinker在 JDK 22 之后已經(jīng)改名成Linker包名從jdk.incubator.foreign變成java.lang.foreign。你要是還抄著舊代碼編譯都不會(huì)過更別提權(quán)限檢查了。6.2 實(shí)戰(zhàn)里的幾個(gè)提醒我自己的項(xiàng)目里輔了好幾個(gè)易踩的小坑單獨(dú)整理一下。第一測(cè)試進(jìn)程和主進(jìn)程要分開配置。主程序配了--enable-native-access不代表 Maven Surefire fork 出來的測(cè)試 JVM 也帶這個(gè)參數(shù)。在單元測(cè)試?yán)锱茉{(diào)用經(jīng)常發(fā)生在本地沒測(cè)出問題、CI 上莫名失敗的情況。第二jlink生成的運(yùn)行時(shí)也要帶參數(shù)。很多項(xiàng)目部署時(shí)用jlink裁剪 JDK生成獨(dú)立鏡像。此時(shí)命令不再是你原來的java而是build/bin/java。JVM 參數(shù)同樣需要傳build/bin/java --enable-native-accessALL-UNNAMED -m com.example.app/com.example.Main如果你把參數(shù)寫在啟動(dòng)腳本里一定要確保腳本實(shí)際執(zhí)行的是裁剪后的那個(gè) Java 運(yùn)行時(shí)。第三反射調(diào)用受限方法時(shí)調(diào)用者模塊以反射調(diào)用方的模塊為準(zhǔn)。如果你通過MethodHandle、反射代理再繞一層很容易搞混授權(quán)目標(biāo)。排查時(shí)優(yōu)先打印最接近Linker.downcallHandle的調(diào)用棧幀看那一幀歸屬哪個(gè)模塊。第四警惕自動(dòng)模塊。把不是模塊化的 jar 放到 module path它會(huì)變成自動(dòng)模塊自動(dòng)模塊默認(rèn)讀取所有模塊并且自動(dòng)獲得一堆權(quán)限。在授權(quán)模型里自動(dòng)模塊的行為比較特殊最好不要依賴它來“繞開”授權(quán)限制。正確姿勢(shì)永遠(yuǎn)是顯式管理好模塊依賴。6.3 和 JNI 共存的一點(diǎn)個(gè)人看法在java.lang.foreign成熟之前Java 調(diào)原生只能靠 JNI。很多存量庫的 JNI 代碼寫得很臟到處都是全局引用泄漏、奇怪的緩存維護(hù)成本高得嚇人。FFM API 的出現(xiàn)最大的價(jià)值不是“跑得更快”而是提供了更安全、更現(xiàn)代的內(nèi)存管理和調(diào)用模型。我自己的遷移策略是新寫的原生橋接層直接用java.lang.foreign存量 JNI 庫如果是穩(wěn)定狀態(tài)、改動(dòng)很頻繁就繼續(xù)保留 JNI只有需要大幅度重構(gòu)或者反復(fù)出現(xiàn)崩潰的 JNI 代碼才考慮逐步重寫。有一個(gè)判斷點(diǎn)很實(shí)用看你的數(shù)據(jù)要跨邊界多少次。FFM API 里MemorySegment可以把一段內(nèi)存的分配、釋放都收在 Arena 作用域中比 JNI 里手動(dòng)NewByteArray、ReleaseByteArrayElements要清爽得多。如果每次調(diào)用都會(huì)產(chǎn)生大量臨時(shí)數(shù)據(jù)選 FMA 的收益會(huì)更明顯。說到底--enable-native-access不是一道多余的坎它相當(dāng)于 JVM 在把你往原生世界推之前讓你先簽一份“我已閱讀風(fēng)險(xiǎn)提示”的確認(rèn)書。前期多花十分鐘把模塊授權(quán)配好后面就不會(huì)因?yàn)橐痪?WARNING 或者一次IllegalCallerException卡住整個(gè)上線流程。我自己的體會(huì)是越早把“模塊 授權(quán)”這個(gè)心智模型建立起來越不容易被版本差異繞暈。以后不管 JDK 怎么改都會(huì)發(fā)現(xiàn)萬變不離其宗原生訪問是特權(quán)操作特權(quán)必須明確授予而授予的憑證就是啟動(dòng)參數(shù)里那串模塊名單。