一個雙肩背包

有多難？

戳一下試試看！

→_→

長摁識別

最近在調試一個項目過程中發現JLINK不工作，基本可以斷定是固件丟失，剛開始按照網上很流行的辦法重新刷寫，沒能成功，所以還是記錄一下，備忘。

1. 問題描述

如圖1所示，JLINK連接到電腦上之后沒有反應，指示燈不亮。猜測是JLINK固件丟失。

圖1

2. 解決辦法

辦法很簡單，就是重新刷寫固件。

2.1 擦除原固件

JLINK上有兩個短接孔，分別是ERASE（擦除）和TST，我的是黑色PCB板，上面焊接了排針，操作起來比較方便。

擦除固件操作分兩個步驟：

Step1：

- 通過USB連接板子和電腦，上電。

- 短接ERASE 10秒以上。

- 斷開ERASE.

- 斷開USB，下電

Step2：

- 短接TST處兩個小孔。

- 連接USB，上電。

- 等待20秒以上(保持TST可靠短接)。

- 斷開USB，下電

- 斷開TST 。

2.2 安裝刷寫工具

第一次是按照網上較為普遍的一份資料，安裝了AT91-ISP v1.13，安裝完成后發現仍舊找不到JLINK芯片驅動。所以又安裝了sam-ba_2.12。

2.3 重新連接JLINK，安裝芯片驅動

如果沒有自動安裝設備驅動，需要手動安裝。到設備管理器下找到新增設備，更新驅動程序時將路徑指定為SAM-BA V2.12安裝路徑下的drv文件夾即可，具體參考下圖。

安裝結束后的界面如下圖所示。

2.4 燒寫程序

利用2.2小節安裝的SAM-BA v2.12軟件進行刷寫。

打開軟件后，選擇正確的芯片型號，如下圖所示。

點擊上圖紅色圓圈內的Connect按鈕，彈出下圖所示的對話框。

按上圖指示選擇固件，點擊Send File進行固件刷寫。過程中首先會彈出下圖所示的對話框，選“是”。

過一會兒又彈出下圖所示的對話框，我選的“否”，不過我覺得選“是”應該也可以。

3. 修復成功的JLINK

測試后，發現JLINK可以正常下載程序了。

討論Java模塊化的一個主要動機一直是當前所謂的物聯網（Internet ofThing，IoT）。對OSGi來說確實如此，它是Java使用最廣泛的第三方模塊系統，于1999年成立，旨在改進嵌入式Java應用程序的開發。

Jigsaw項目也是如此，它開發了JPMS，并且期望通過以下方式使平臺更具擴展性：僅使用（嵌入式）應用程序所需的代碼即可創建尺寸很小的運行時鏡像。

這就是jlink的由來。它是一個Java命令行工具（位于JDK的bin目錄中），可用于選擇需要的平臺模塊，并將它們鏈接到同一個運行時鏡像中。

這樣的運行時鏡像的行為完全類似于JRE，但僅包含所選擇的模塊和需要的依賴項（通過requires指令）。在鏈接階段，可使用jlink進一步優化鏡像大小并改善Java虛擬機性能，尤其是縮短啟動時間。

不過，自Jigsaw項目誕生以來的幾年里，已經發生了很多變化。一方面，嵌入式設備中的磁盤空間不再那么昂貴。

另一方面，我們已經看到了虛擬化的興起，其中最顯著的是Docker，它再次引起了人們對容器大小的關注（盡管這不是主要問題）。容器化的興起也給簡化和自動化部署帶來了壓力，因為現在部署的頻率要高出幾個數量級。

jlink在這里也能提供幫助。它不僅可以鏈接平臺模塊，還可以創建應用程序鏡像：其中包括應用程序代碼，以及類庫和框架模塊。

這使得構建過程可以生成一個完全獨立的可部署單元，該單元由整個應用程序以及所需的平臺模塊組成，根據需要可對鏡像大小和性能進行優化，并且可以簡單地通過調用本地腳本來啟動。

如果你是一位專注于桌面應用程序的開發者，當我提到IoT和Docker時，你可能不太關心，但jlink肯定能讓你興奮。通過jlink，用戶可以非常容易地發布一個無須進一步設置即可啟動的Zip文件。

而且，如果你一直在使用javapackager，那么會很高興聽到它現在在內部調用jlink，因為這會讓你很容易使用它的所有功能（雖然我不打算介紹集成，但javapackager文檔中已經介紹過了）。

因此，開始使用jlink吧！本章先從基于平臺模塊創建運行時鏡像開始，利用該機會深入探索鏈接過程的細節、研究生成的鏡像，并討論如何選擇正確的模塊；然后討論如何包含應用程序模塊和創建自定義啟動器；

接下來討論如何跨操作系統生成鏡像；最后會關注鏡像大小和性能優化。

關于代碼，請查看ServiceMonitor代碼庫中的feature-jlink分支。在本章的最后，你將了解如何為各種操作系統創建優化后的運行時鏡像（其中可能包含整個應用程序）。通過這種方式，你就可以構建一個在服務器或客戶的計算機上可直接部署的單元了。

一 創建自定義運行時鏡像

jlink的一大用例是創建Java運行時鏡像，并且該鏡像僅包含應用程序所需的模塊。創建的結果就是量身定制的JRE，其中完美地僅包含你的代碼所需的模塊，不多不少。然后，你可以像使用其他JRE一樣，通過該鏡像中的java可執行文件啟動應用程序。

自定義運行時鏡像具有一系列優點：可以節省一些磁盤空間（鏡像尺寸較小）、可以節省網絡帶寬（如果遠程部署的話）、通常更安全（類越少意味著攻擊面越小），甚至可以啟動得更快。

注意 話雖如此，但jlink“只是”鏈接了字節碼，不會將其編譯為機器碼。你可能已經聽說，從Java 9開始，Java進行了AOT（aheadof-time）編譯實驗，但jlink與之無關。要了解Java中的AOT，請查看Java增強建議295。

要點 一旦在Java 9及以上版本中運行，便可以創建針對你的應用程序的自定義運行時鏡像，而無須先對其進行模塊化。

為了了解如何使用jlink創建運行時鏡像，本章將從最簡單的鏡像開始，然后檢查結果。接下來，本章將討論服務的特殊處理方式，并且以真實的用例結束該部分：如何創建專用于運行指定應用程序的鏡像。

1 jlink入門

定義：jlink的必要信息

要創建鏡像，jlink需要3條信息，每條信息都有一個對應的命令行選項：

1）哪里可以找到可用的模塊（由--module-path指定）；

2）使用哪些模塊（由--add-modules指定）；

3）在哪個目錄中創建鏡像（由--output指定）。

最簡單的運行時鏡像僅包含基礎模塊。代碼清單14-1顯示了如何使用jlink創建它。

代碼清單14-1 創建僅包含基礎模塊的運行時鏡像

你需要告訴jlink在哪里可以找到平臺模塊，這似乎有些奇怪。對于javac和java來說這不是必需的，那么jlink為什么不知道在哪里找到它們？答案是跨平臺鏈接，下面將對其進行討論。

注意 從Java 10開始，模塊路徑上不再放置平臺模塊。如果不包含任何路徑選項，那么jlink將隱含地從$JAVA_HOME/jmods中加載。

要點 無論平臺模塊是被顯式還是隱式引用，建議你僅從與jlink可執行文件完全相同的JVM版本中加載它們。例如，如果jlink是9.0.4版本，那么請確保它從JDK 9.0.4中加載平臺模塊。

給定這3個命令行選項，jlink會按照前幾篇文章中的描述解析模塊：模塊路徑中的內容被視為可觀察模塊的全集，--add-modules指定的模塊被視為解析過程的根。但是jlink有一些特點。

要點 默認情況下，服務未被綁定。后文節將說明原因，并探討解決方法。

1）通過requires static指定的可選依賴不會被解析。它們需要手動添加。

2）不允許使用自動模塊。這一點在后文中變得很重要，該節將進行詳細說明。

除非遇到諸如丟失或重復模塊之類的問題，否則已解析的模塊（根模塊加上傳遞依賴）將最終出現在新的運行時鏡像中。下面來看看。

2 鏡像內容和結構

要事第一：與263 MB的完整JRE相比，此鏡像在Linux上僅占用約45MB（據說在Windows上甚至更少）——甚至還沒進行下面中將討論的鏡像大小優化。

那么該鏡像什么樣呢？前文曾介紹過新的JDK/JRE目錄結構，jlink創建的運行時鏡像與其相似，如圖14-1所示。這不是巧合：你下載的JDK和JRE也由jlink組裝。

JDK的目錄結構（左）與用jlink創建的自定義運行時鏡像（右）之間的比較。相似并非偶然——JDK是使用jlink創建的請注意，jlink將選取的模塊融合到lib/modules中，然后從最終鏡像中刪除jmods目錄。

這與JRE的生成方式一致，JRE也不包含jmods。原始的JMOD文件僅包含在JDK中，以便jlink可以處理它們：將模塊優化至lib/modules是一個不可逆操作，并且jlink無法從已優化的鏡像中生成其他的鏡像。

查看bin，你可能想知道在其中可以找到哪些可執行文件。事實證明，jlink很聰明，只會在生成的鏡像中包含所需模塊的可執行文件。

例如，用于編譯的可執行文件javac是隨著jdk.compiler模塊一起提供的，如果不包含該模塊，則該可執行文件將不存在。

3 在運行時鏡像中包含服務

如果仔細查看代碼清單14-1，可以看到該鏡像僅包含java.base，這似乎有點奇怪。在前文中，你了解到基礎模塊使用了許多其他平臺模塊提供的服務，并且在模塊解析期間綁定服務時，所有這些提供者都被拉入了模塊圖。所以，為什么它們沒有出現在鏡像中呢？

定義：--bind-services

為了創建小型的、專用的運行時鏡像，默認情況下jlink創建鏡像時不執行任何服務綁定。相反，必須在--add-modules中指定，以便手動包含需要的服務提供者模塊。另外，--bind-services選項可用于包含提供一個服務的所有模塊，該服務是由另一個已解析的模塊所使用的。

讓我們以ISO-8859-1、UTF-8或UTF-16等字符集為例。基礎模塊知道你通常需要的模塊，但是有一個特殊的平臺模塊，其中包含一些其他模塊：jdk.charsets。基礎模塊和jdk.charsets通過服務解耦。以下是其模塊聲明的相關部分。

當JPMS在常規啟動期間解析模塊時，服務綁定將拉入jdk.charsets，因此其字符集在標準JRE中并不總是可用。

但是當你通過jlink創建一個運行時鏡像時，服務綁定并不會將其拉入，所以鏡像默認將不包含charsets模塊。如果你的項目依賴于此，則可能會以非常痛苦的方式發現這個問題。

一旦你確定要依賴一個通過服務解耦的模塊時，就可以使用--addmodules將其包含在鏡像中。

定義：--suggest-providers

手動識別服務提供者模塊可能很麻煩。幸運的是，jlink可以幫助你。--suggest- providers ${service}選項列出了所有提供${service}實現的可見模塊，其中${service}必須指定完全限定名。

假設你已經創建了一個僅包含java.base的最小運行時鏡像，并且由于缺少字符集在執行應用程序時遇到了問題。

你定位到的問題是java.base使用了java.nio.charset.spi.CharsetProvider，現在想知道哪些模塊提供了該服務。下面該--suggest-providers出場了。

另一個可能導致靜默缺失模塊的例子是語言環境（locale）。除英語語言環境外，所有其他語言都包含在jdk.localedata模塊中，并通過服務將它們提供給基礎模塊使用。考慮以下代碼：

上面的代碼將打印什么輸出？Locale("fi", "FI")創建芬蘭語語言環境，而芬蘭語格式使用帶逗號的浮點數，因此結果為0,5——至少在芬蘭語語言環境可用時是這樣。

如果你在不包含jdk.localedata的運行時鏡像上執行此代碼（比如你之前創建的那個鏡像），則得到0.5。因為Java悄無聲息地回退到了默認語言環境。是的，這不是錯誤，而是靜默的不良行為。

和之前一樣，解決方案是顯式包括那些已解耦的模塊，在本例中為jdk.localedata。但是，由于它包含許多語言環境數據，因此使得鏡像大小增加了16 MB。幸運的是，正如你將在后文看到的那樣，jlink可以幫助減少額外的負載。

注意 如果應用程序的行為在通用的Java版本中和在自定義的運行時鏡像上運行時有所不同，則應考慮一下服務。行為不正常是由于JVM的某些功能不可用引起的嗎？也許其中的模塊已通過服務解耦，但現在在運行時鏡像中丟失了。

下面是基礎模塊會使用并由其他平臺模塊提供的一些服務，你可能隱式依賴于它們：

1）jdk.charsets中的字符集

2）jdk.localedata中的語言環境

3）jdk.zipfs中的Zip文件系統

4）java.naming、java.security.jgss、java.security.sasl和java.smartcardio、java.xml.crypto、jdk.crypto.cryptoki、jdk.crypto.ec、jdk.deploy和jdk.security.jgss中的安全服務提供者作為逐個手動標識和添加模塊的替代方法，可以使用更方便的--bindservices選項。

但是，這會將所有提供服務的模塊綁定到基礎模塊，從而創建一個相當大的鏡像——（未經優化下）該鏡像約為150 MB。所以你應該仔細考慮是否要這樣做。

4 用jlink和jdeps調整鏡像大小

到目前為止，你僅創建了由java.base和其他一些模塊組成的小型鏡像。

但是真實世界的用例呢？你如何確定維持大型應用程序所需的平臺模塊？不能再用試錯法了，對吧？

這就引出了另一個工具——JDeps。關于JDeps的完整介紹，請參見附錄D——此時僅需了解以下命令將列出應用程序所依賴的所有平臺模塊即可。

為此，jars目錄必須包含運行應用程序所需的所有JAR（你的代碼以及相關依賴；構建工具將對此提供幫助），而jars/app.jar必須包含用于啟動的main函數。

命令的結果會顯示工件之間的諸多依賴關系，并且還會顯示平臺模塊的依賴。以下示例列出了Hibernate Core 5.2.12使用的平臺模塊及其依賴項。

現在你需要做的就是提取這些行，刪除... ->部分，并且扔掉重復項。對Linux用戶來說，需執行以下代碼。

最終，你得到了應用程序所依賴的完整的平臺模塊列表。將它們輸到jlink --add-modules中，你將獲得支持該應用程序的最小運行時鏡像，如圖14-2所示。

通過給定應用程序JAR（上）及其在平臺模塊上的依賴（下），jlink可以僅基于需要的平臺模塊創建運行時鏡像要點 以下是一些注意事項。

1）JDeps偶爾會報告... -> not found，這意味著在類路徑上沒有某些傳遞依賴。所以，請確保JDeps的類路徑包含運行應用程序時所有需要使用的工件。

2）JDeps無法分析反射，因此，如果你的代碼或你的依賴代碼僅通過反射與JDK中的類進行交互，JDeps則不會對此進行處理。這可能導致所需的模塊無法放入鏡像中。

3）如前文節所述，默認情況下，jlink不綁定服務，但是你的應用程序可能隱式依賴于某些JDK內部提供者。

4）考慮添加支持Java代理所需的java.instrument模塊。如果你的生產環境使用代理來觀察正在運行的應用程序，則這是必須添加的。

即使不是這種情況，你也會發現自己陷入了困境，而Java代理是分析問題的最佳方法。況且它只有150 KB左右，所以沒什么大不了的。

注意 為應用程序創建運行時鏡像后，建議你在其上運行單元測試和集成測試。這將使你確信確實包括了所有必需的模塊。

下一步是在鏡像中包含應用程序模塊——但要做到這一點，你的應用程序及其依賴需要完全模塊化。如果不是這種情況，并且你正在尋找更直接可用的知識。

二 創建獨立的應用程序鏡像

到目前為止，你已經創建了支持應用程序的運行時鏡像，但沒有理由就此止步。jlink使創建包含整個應用程序的鏡像變得容易得多。

這意味著，你最終將獲得一個包含應用程序全部模塊（應用程序本身及其依賴）和支持它的平臺模塊的鏡像。你甚至可以創建一個適合的啟動器，因此可以使用bin/my-app運行你的應用程序！同時，分發應用程序也變得更加容易。

定義：應用程序鏡像

為了清楚地描述我在說的內容，我將包含應用程序全部模塊的鏡像稱為應用程序鏡像（application image，與之相對的是運行時鏡像），盡管其不是官方術語。畢竟，生成的結果更類似于應用程序，而非通常的運行時環境。

要點 請注意，jlink僅在清晰模塊上運行，因此無法將依賴于自動模塊的應用程序鏈接到鏡像中。如果你確實必須為應用程序創建鏡像，請參閱前文中有關如何使第三方JAR模塊化的方法，或使用類似ModiTect這樣的工具。

對清晰模塊的這種限制沒有技術依據——這是由設計所決定的。應用程序鏡像應該是自包含的，但是如果它依賴于不表達依賴關系的自動模塊，則JPMS無法進行驗證，因此可能會導致NoClassDefFoundError。這與模塊系統所追求的可靠性相違背。

先決條件解決了，讓我們開始吧。首先創建一個包含應用程序模塊的鏡像，然后通過創建啟動程序來簡化工作，最后考慮一下應用程序鏡像的安全性、性能和穩定性。

1 在鏡像中包含應用程序模塊

創建應用程序鏡像所要做的就是將應用程序模塊添加到jlink模塊路徑中，并從中選擇一個或多個作為根模塊。生成的鏡像包含所有需要的模塊（再無其他模塊，如圖14-3所示），可以使用bin/java --module${initial-module}命令啟動。

給定應用程序模塊（上）及與平臺模塊的依賴關系（下），jlink可以僅使用所需的模塊（包括應用程序和平臺代碼）創建運行時鏡像。

作為示例，再次回到ServiceMonitor應用程序。因為它依賴于自動模塊spark.core和hibernate.jpa，但jlink不支持，所以我不得不去掉這些功能。這就給我們留下了7個模塊，所有的模塊都只依賴于java.base：

1）monitor

2) monitor.observer

3) monitor.observer.alpha

4) monitor.observer.beta

5) monitor.persistence

6) monitor.rest

7) monitor.statistics

我將這些模塊放入名為mods的目錄中，并創建了一個鏡像，如代碼清單14-2所示。不幸的是，我忘記了觀察者的實現，即monitor.observer.alpha和monitor.observer.beta模塊，已經通過服務與應用程序的其余部分進行了解耦，并且在默認情況下不受約束（。

因此，我必須在代碼清單14-3中再次嘗試顯式添加?；蛘?，也可以使用--bind-services選項，但我不喜歡由于包含了所有JDK內部服務提供者而導致鏡像變得過大。

代碼清單14-2 創建包含ServiceMonitor的應用程序鏡像。

代碼清單14-3 創建包含服務的應用程序鏡像。

定義：系統模塊

總的來說，鏡像包含的平臺和應用程序模塊稱為系統模塊。稍后你

將看到，在啟動應用程序時仍然可以添加其他模塊。

01. 當心模塊解析的獨特性

請記住，在前文節中，jlink創建了一個最小鏡像：

1）它不綁定服務；

2）它不包含可選依賴。

要點 盡管你會記得檢查自己的服務是否存在，但可能會忘記依賴（例如SQL驅動）或平臺模塊（語言環境數據或不常用的字符集）。

對于可選的依賴也是如此，你可能想要包含這些依賴項，但是忘記了一個事實，即可選依賴不會因為出現在模塊路徑上而被解析。務必確保真正包含了所有需要的模塊！

ServiceMonitor應用程序使用芬蘭語語言環境格式化其輸出，因此需要向鏡像中添加jdk.localedata模塊（參見代碼清單14-4）。這將使鏡像大小增加16 MB（達到61 MB）。后文將介紹如何減小鏡像大小。

代碼清單14-4 用語言環境數據創建ServiceMonitor應用程序鏡像。

02. 在啟動應用程序時使用命令行選項

一旦創建了鏡像，就可以像往常一樣使用java --module${initial-module}啟動應用程序（使用鏡像bin目錄中的java可執行文件）。但因為你在鏡像中包含了應用程序模塊，所以不需要指定模塊路徑——JPMS可以在鏡像中找到它們。

在jdk-monitor中創建ServiceMonitor鏡像之后，就可以使用一個簡短的命令啟動應用程序了。

但如果你愿意，則可以使用模塊路徑。在這種情況下，請記住系統模塊（鏡像中的模塊）始終覆蓋模塊路徑上的同名模塊——就好像模塊路徑上的模塊不存在一樣。

你能夠對模塊路徑所做的是向應用程序中添加新模塊。添加的模塊可能是額外的服務提供者，這樣不但可以發布應用程序的鏡像，還能讓用戶在本地輕松地擴展鏡像。

假設ServiceMonitor發現了一個需要觀察的新的微服務，即monitor.observer.zero模塊。此外，該模塊實現了所有正確的接口，其描述符聲明它可以提供ServiceObserver。

然后，如代碼清單14-5所示，你可以使用之前的鏡像，并添加monitor.observer.zero模塊。

代碼清單14-5 用額外的服務提供者啟動應用程序鏡像

要點 如果你想替換系統模塊，那么必須將它們放在升級模塊路徑上。除了模塊路徑的特殊情況外，本書提到的所有其他java選項，在自定義應用程序鏡像中都是相同的。

2 為應用程序生成一個本地啟動程序

如果把創建一個包含應用程序及其一切所需的鏡像（而不包含其他東西）看作一塊蛋糕，那么自定義添加啟動程序就像是蛋糕上的糖衣。

自定義啟動程序是鏡像bin目錄中的可執行腳本（Unix系統上的shell；Windows系統上的batch），并且預先配置了使用具體模塊和主類來啟動JVM。

定義：--launcher

要創建一個啟動程序，需使用--launcher${name}=${module}/${main-class}選項：

1）${name}是你為可執行文件選擇的文件名；

2）${module}是想要啟動的模塊名稱；

3）${main-class}是模塊的主類名。

后兩項通常放在java --module之后，在這種情況下，如果模塊定義了一個主類，那么就可以省略/${main-class}。

如代碼清單14-6所示，通過使用--launcher runmonitor=monitor，你可以讓jlink在bin中創建一個run-monitor腳本，該腳本將以與java --module monitor等價的方式啟動應用程序。

因為monitor聲明了主類（monitor.Main），所以不必再通過--launcher指定。如果你想要指定主類，可以使用--launcher runmonitor=monitor/monitor.Main。

代碼清單14-6 使用啟動程序創建應用程序鏡像并稍加留意

注意 你是否注意到代碼清單14-6中的JLINK_VM_OPTIONS？如果想為應用程序指定任何命令行選項，例如調優垃圾收集器，可以將相應的選項放在這里。

不過，使用啟動程序有一個缺點：啟動JVM的所有選項都會被解釋為放在--module選項之后，并視為程序的參數。這意味著在使用啟動程序時，你不能臨時配置模塊系統，例如，不能像前面討論的那樣添加其他服務。

但有一個好消息：java命令仍然可用，因而你不必使用啟動程序。即使創建了一個啟動程序，代碼清單14-5的工作方式也完全相同——只要不用它就好了。

3 安全性、性能和穩定性

創建應用程序鏡像可以通過最大限度地減少JVM中的代碼量來提高應用程序的安全性，從而減少攻擊面。正如前文節將討論的，其還會改善啟動耗時。

盡管聽起來很簡單，但它只適用于可以對應用程序完全控制并定期重新部署的情況。如果你將鏡像交付給客戶，或者無法控制何時以及多久替換新鏡像，那么情況就會發生變化。

要點 用jlink生成的鏡像并不適合修改，它沒有自動更新功能，手動打補丁也是不現實的。如果用戶更新了系統的Java，你的應用程序鏡像則不會受到影響?？傊?，它永遠綁定到鏈接期間平臺模塊的Java版本。

好處是Java補丁更新不會影響應用程序，但更嚴重的壞處是，應用程序不能從Java新版本帶來的安全補丁或性能改進中受益。如果在新的Java版本中修補了一個關鍵的漏洞，那么客戶在部署你提供的新應用程序鏡像之前，仍將暴露在該漏洞所帶來的威脅之下。

注意 如果你決定交付應用程序鏡像，建議你將其作為一種附加的交付機制，而不是唯一的交付機制。讓用戶決定是要部署鏡像，還是在自己的運行時上運行JAR，這樣他們可以完全控制運行時環境，并且可以獨立更新。

三 生成跨操作系統的鏡像

盡管應用程序和類庫JAR包含的字節碼獨立于任何操作系統，但是它需要一個特定于操作系統的JVM來執行。這就是為什么要下載專門針對Linux、macOS或Windows的JDK和運行時。重要的是，要認識到jlink是在特定于操作系統上操作的！圖14-4顯示了特定于操作系統的部分。

與應用程序、類庫和框架JAR（上）不同，應用程序鏡像（右）就像JVM（下），是特定于操作系統的。

仔細想想就會發現：jlink用于創建鏡像的平臺模塊來自特定于系統的JDK或JRE，因此生成的鏡像也是特定于操作系統的。因而，運行時或應用程序鏡像總是綁定到某個具體的操作系統。

這是否意味著，你必須在一堆不同系統的機器上執行jlink才能創建所需的各種運行時或應用程序鏡像？

幸運的是，不需要這樣做。正如你在前文節中看到的，在創建鏡像時，可以將jlink指向你希望包含的平臺模塊。實際情況是：這些不一定是執行jlink所在的操作系統！

要點 如果你下載并解壓了一個不同操作系統的JDK，那么在系統JDK上運行jlink時，可以將它的jmods目錄放在模塊路徑上。鏈接器將確定要為該操作系統創建鏡像，并創建在該操作系統上工作的鏡像（當然，不是在另一個操作系統上）。

因此，給定應用程序支持的所有操作系統的JDK，就可以在同一臺機器上為不同系統生成運行時或應用程序鏡像。

我使用Linux，但是我想生成一個在macOS上運行的ServiceMonitor應用程序鏡像。jlink可以方便地支持這些場景——所需的只是一個用于目標操作系統的JDK。

事實證明，最難的部分是將JDK在不同的系統上解包。在這種情況下，我必須解壓Oracle為macOS發布的*.dmg文件——在這里不做詳細介紹，但在搜索引擎上，可以找到關于{Linux、macOS、Windows}和{rpm/tar.gz, dmg, exe}各種組合的建議。

最后，我在某個目錄中保存了macOS JDK，將其表示為${jdk-9-mac-os}。

接下來要做的事情與前文相同，將JDK 9目錄（${jdk-9}）替換為包含macOS JDK的目錄（${jdk-9-mac-os}）。這意味著我使用的jlink可執行程序來自Linux JDK，但jmods目錄來自macOS JDK。

上面代碼的運行應該沒問題。