Java web項目中使用JNI技術(shù)（如何在運行時改變java.library.path并生效）

記錄結(jié)構(gòu)：JNI技術(shù)入門詳解，注意：手記與接下來要記錄的web項目中使用JNI技術(shù)是無縫連接的。應(yīng)用場景：當(dāng)我們根據(jù)不同的平臺生成不同的JNI libaray時，例如：linux .so，mac jnilib，windows .dll。我們想在打包web應(yīng)用程序時讓程序動態(tài)調(diào)用c，或者c ++對Java Native Inteface的具體底層實現(xiàn)時，有一種方法是借助配置在idea中的vm選項中設(shè)置庫文件所在的路徑，即-Djava.path.library，剛哥手記最后一部分有說明。精準(zhǔn)定位問題：

1.那么有沒有另外一種方式使得Java的程序在調(diào)用本地inteface中抽象本地方法自動加載所需要的代碼呢？也就是說應(yīng)用程序自動加載的.so || （或） .jnilib || .dll ?. 2.我們知道Java應(yīng)用程序在調(diào)用底層代碼生成的庫文件時，需要指定庫文件所在的路徑。那么我們的問題就清楚了，問題的痛點在于如何讓應(yīng)用程序在程序運行期間動態(tài)加載庫文件所在的路徑，進(jìn)而加載所需的庫文件。網(wǎng)上的一種說法是：在使用的System.loadLibrary（ “具體庫文件所在的路徑的相對路徑”），之前使用System.load（“具體庫文件所在的根目錄的全路徑“），本人試了一下，發(fā)現(xiàn)并不起作用。

java.library.path 系統(tǒng)屬性指示JVM在哪里搜索本地庫。您必須使用-Djava.library.path = / path / to / lib將它指定為JVM參數(shù) ，然后當(dāng)您嘗試使用System.loadLibrary（“foo”）加載庫時，JVM將搜索庫路徑指定的庫。如果找不到，你會得到一個異常，如下所示：

大致的意思是：

系統(tǒng)屬性 - java.library.path指引JVM去尋找底層的庫文件，你必須為JVM聲明一個屬性，類似于Djava.library.path = / path / to / lib，當(dāng)你需要使用System.loadLibrary（“foo “）加載底層foo的庫文件的時候，JVM會按照你聲明的路徑去加載這個庫文件，如果你不聲明的話，會出現(xiàn)下面錯誤：

線程“main”中的異常java.lang.UnsatisfiedLinkError：java.library.path中沒有foo 在java.lang.ClassLoader.loadLibrary（ClassLoader.java:1734） 在java.lang.Runtime.loadLibrary0（Runtime.java:823） 在java.lang.System.loadLibrary（System.java:1028）

。這個錯告訴我們富并不庫在我們所要加載的路徑下面接下來說明原因：

當(dāng)JVM啟動時，java.library.path 只讀一次。如果使用System.setProperty更改此屬性，則不會有任何區(qū)別。

意思是：java.library.path只會在JVM啟動的時候被都到，如果你直接使用System.setProperty（“java.path.libarary”，“庫所在路徑”）這樣是不起作用的，因為JVM已經(jīng)啟動了所以這個JVM后期不能找到這個庫文件所在的路徑，所以就報如上錯誤。源碼中ClassLoader.loadLibrary有這樣一句代碼：

if（sys_paths == null）{ usr_paths = initializePath（“java.library.path”）; sys_paths = initializePath（“sun.boot.library.path”）;}

為什么就定位問題到上述幾行代碼，我們得從源碼的角度來分析，看下源碼：首先是System.loadLibaray（），借助想法看下源碼：

/ ** *加載由<code> libname </ code>指定的本地庫 *參數(shù)。<code> libname </ code>參數(shù)不能包含任何平臺 *特定的前綴，文件擴(kuò)展名或路徑。如果一個本地庫 *稱為<code> libname </ code>是靜態(tài)鏈接到虛擬機(jī)，然后是 調(diào)用庫導(dǎo)出的JNI__ <code> libname </ code>函數(shù)。 *有關(guān)更多詳細(xì)信息，請參閱JNI規(guī)范。 * *否則，從系統(tǒng)庫加載libname參數(shù) *位置并映射到實現(xiàn)中的本地庫圖像 - *依賴的方式。 * <p> *調(diào)用<code> System.loadLibrary（name）</ code>是有效的 *相當(dāng)于通話 * <blockquote> <pre> * Runtime.getRuntime（）。loadLibrary（name） * </ pre> </ blockquote> * * @param libname庫的名稱。 * @exception SecurityException如果存在一個安全管理器及其 * <code> checkLink </ code>方法不允許 *加載指定的動態(tài)庫 * @exception UnsatisfiedLinkError如果是libname參數(shù) *包含文件路徑，本地庫不是靜態(tài)的 *與VM鏈接，或者庫無法映射到一個 *主機(jī)系統(tǒng)的本地庫圖像。 * @exception NullPointerException如果<code> libname </ code>是 * <code> null </ code> * @see java.lang.Runtime＃loadLibrary（java.lang.String） * @see java.lang.SecurityManager＃checkLink（java.lang.String） * / @CallerSensitive public static void loadLibrary（String libname）{ Runtime.getRuntime（）。loadLibrary0（Reflection.getCallerClass（），libname）; }

可以 看到方法調(diào)用中出現(xiàn)Runtime.getRuntime（）。loadLibrary0（），從這行代碼我們知道庫文件是在運行時被加載起來用的。我們繼續(xù)看loadLibrary0（）

/ ** *加載由<code> libname </ code>指定的本地庫 *參數(shù)。<code> libname </ code>參數(shù)不能包含任何平臺 *特定的前綴，文件擴(kuò)展名或路徑。如果一個本地庫 *稱為<code> libname </ code>是靜態(tài)鏈接到虛擬機(jī)，然后是 調(diào)用庫導(dǎo)出的JNI__ <code> libname </ code>函數(shù)。 *有關(guān)更多詳細(xì)信息，請參閱JNI規(guī)范。 * *否則，從系統(tǒng)庫加載libname參數(shù) *位置并映射到實現(xiàn)中的本地庫圖像 - *依賴的方式。 * <p> *首先，如果有一個安全管理器，它的<code> checkLink </ code> *以<code> libname </ code>作為參數(shù)調(diào)用方法。 *這可能會導(dǎo)致安全異常。 * <p> *方法{@系統(tǒng)＃loadLibrary（字符串）}是傳統(tǒng)的 *和調(diào)用此方法的便捷方法。如果是本機(jī) *方法被用于執(zhí)行一個類，一個標(biāo)準(zhǔn) *策略是把本地代碼放在一個庫文件中（稱之為 * <code> LibFile </ code>），然后放入一個靜態(tài)初始化程序： * <blockquote> <pre> * static {System.loadLibrary（“LibFile”）; } * </ pre> </ blockquote> *在類聲明中。當(dāng)這個類被加載和 *初始化，本地必需的本地代碼實現(xiàn) *方法將被加載。 * <p> *如果這個方法被同一個庫調(diào)用多次 *名稱，第二個和后續(xù)的調(diào)用被忽略。 * * @param libname庫的名稱。 * @exception SecurityException如果存在一個安全管理器及其 * <code> checkLink </ code>方法不允許 *加載指定的動態(tài)庫 * @exception UnsatisfiedLinkError如果是libname參數(shù) *包含文件路徑，本地庫不是靜態(tài)的 *與VM鏈接，或者庫無法映射到一個 *主機(jī)系統(tǒng)的本地庫圖像。 * @exception NullPointerException如果<code> libname </ code>是 * <code> null </ code> * @查看java.lang.SecurityException * @see java.lang.SecurityManager＃checkLink（java.lang.String） * / @CallerSensitive public void loadLibrary（String libname）{ loadLibrary0（Reflection.getCallerClass（），libname）; } synchronized void loadLibrary0（Class <？> fromClass，String libname）{ SecurityManager安全性= System.getSecurityManager（）; if（security！= null）{ security.checkLink（LIBNAME）; } if（libname.indexOf（（int）File.separatorChar）！= -1）{ 拋出新的UnsatisfiedLinkError（ “目錄分隔符不應(yīng)出現(xiàn)在庫名稱中：”+ libname）; } ClassLoader.loadLibrary（fromClass，libname，false）; }

題外話：loadLibrary（），loadLibrary0（）這兩個方法的命名還是挺不符合規(guī)范的，歷史遺留問題吧。在loadLibrary中我們看到了ClassLoader.loadLibrary（fromClass，libname，false） ;方法繼續(xù)追溯

對于上述代碼的解釋我們可以從這篇博客中獲取到答案：

如果將sys_paths設(shè)置為null，則當(dāng)您嘗試加載庫時，庫路徑將被重新初始化。

意思是說，如果我們通過代碼將sys_paths，設(shè)置為null，那么java.library.path將被重新加載一次。那么問題來了，通過剛才的源代碼追溯，我們知道System.loadLibray（）調(diào)用ClassLoader.loadLibrary （）方法，我們應(yīng)該如何將sys_paths設(shè)置為空？通過上述情景描述，我們要更改sys_paths的值為空，只能在sys_paths初始化之前做手腳（反射在程序動態(tài)運行期間更改程序中的屬性值）。代碼如下：

追溯上述代碼，調(diào)試結(jié)果如下圖所示：

上圖紅色注釋為java.library.path，注釋有誤特此說明。最終程序的正常運行。

在程序中實現(xiàn)了程序運行時動態(tài)更改的java.library.path并生效的效果。我在網(wǎng)絡(luò)項目中的應(yīng)用是這樣的：程序封裝，對JNI的使用封裝成jniutil工具類：