解決Java 部署Tomcat時使用jni和jna呼叫DLL檔案的問題

阿新 • • 發佈：2020-11-26

我的前一篇部落格提到，我們公司專案的restful框架中要用到底層的DLL C++庫，最後經過測試驗證結果選擇採用JNA方法來調DLL庫。

之後基礎框架在IDEA中的jetty服務中除錯成功，但是在部署到Tomcat上時出現了無法載入DLL庫的狀況，只能現學現賣了。

一. 把DLL檔案放在Tomcat下的方法：

在Tomcat中載入dll，供其它介面呼叫：

在Tomcat目錄根下新建一個資料夾，這裡就叫DLL吧，<tomcat_home>/DLL；

把需要用到的dll放入新建的DLL目錄下；

編輯<tomcat_home>/conf/catalina.properties，在common.loader後面追加${catalina.home}/DLL；

編輯<tomcat_home>/bin/目錄下的catalina.bat，在rem Copy CATALINA_BASE from CATALINA_HOME if not defined的段落中增加如下語句：

set LD_LIBRARY_PATH=%CATALINA_BASE%\DLL

set JAVA_OPTS=-Djava.library.path=%CATALINA_BASE%\DLL%JAVA_OPTS%

儲存重新啟動Tomcat，deploy war即可。

二. 把DLL檔案放在java.library.path路徑下，可以通過System.out.println(System.getProperty("java.library.path"));語句檢視都有哪些系統調預設呼叫的檔案路徑。Tomcat會在這些目錄下尋找要載入的檔案、庫等。

三. 在使用JNA呼叫DLL時，總是提示無法載入相應的庫。把DLL檔案放在各種路徑下都不起作用。

無奈之下，我換成JNI工具嘗試了一下，結果提示Can't load IA 32-bit .dll on a AMD 64-bit platform。真相終於浮出了水面，原來是因為JDK和DLL系統不相容（萬萬沒想到問題出在這裡），於是我把DLL重新編譯成64位試了一下，成功部署。

然後我又換成JNA工具後試了一下也成功部署（早該換成JNI試一下，就是因為JNI使用步驟過於繁瑣，所以一直對JNA不死心，結果拖了很長時間），問題解決。

四．使用JNA的時候，大多數網上教程中Native.loadLibrary(“DLL name”,classname.class); 中的第一個引數都是相對路徑。按照程式設計經驗，這裡應該也可以寫成絕對路徑，例如：

Native.loadLibrary(“C:\Program Files (x86)\Java\jdk1.8.0_51\bin\ DLLname.dll”,classname.class);

我這樣試著跑了一下，證明我的猜想是正確的。

五. 把DLL放在Tomcat資料夾下的bin檔案中也可以找到。Linux下放在 /user/local/bin 中。這是我最後採用的方式。

總結：

問題可能出在方方面面，需要學習的還很多，經驗也相當重要。同時應該在自己的程式碼中建立完整的異常報錯體系，和良好的異常處理習慣。但是我又擔心太多的分支處理會影響整體的效能。還是好好修煉內功才是王道啊。

補充知識：正確配置java jdk環境變數方式及配置tomcat後執行startup.bat閃退原因分析

我們用的很多軟體都需要配置環境變數,有的軟體會自動配置環境變數,不需要我們手動配置.而有的必須手動配置環境變數,比如git,eclipse等.

下面分享一下正確配置java環境變數的方法.因為很多軟體的執行都需要基於配置java環境變數的基礎上.

以配置jdk1.8為例：

1 安裝jdk1.8

如圖中所以,開啟jdk-xxx.exe,進行安裝jdk,事先建兩個資料夾jdk,jre,用於分別作為jdk和jre的安裝資料夾

2 配置環境變數

安裝完之後,就是配置環境變數：

JAVA_HOME -- 變數值就是jdk的主目錄,圖中已用藍色標出(配置JAVA_HOME變數值時,末尾一定不要加分號)

Path -- 需要配置兩個,jdk的bin目錄和jdk下的jre的bin目錄,如圖中所示：

即 %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;