i上分析J9虛擬機崩潰問題？

Java 虛擬機非正常地停止運行可能是多種原因引起的，例如 Java 程序產生了無法處理的異常，虛擬機運行過程中產生不可恢復的錯誤，虛擬機所在的進程崩潰等。對于 Java 異常和虛擬機內部產生的錯誤，一般會有對應的錯誤消息指示發生了哪種問題，相對容易找到問題的根源。而對于虛擬機崩潰問題相對比較復雜。崩潰通常由以下幾種原因產生：在與 JNI 相關的本地代碼中崩潰JNI 是 Java Native Interface 的縮寫，即 JAVA 本地調用。從 Java1.1 開始，Java Native Interface(JNI) 標準成為 java 平臺的一部分，它允許 Java 代碼和其他語言寫的代碼進行交互。本地代碼在多種情況下都會用到 JNI。 而 JNI 的使用中有許多需要注意的問題（詳見”使用 Java Native Interface 的最佳實踐“）。這些本地代碼對 JNI 不正確的使用往往會造成 J9 所在的 JOB 崩潰。使用 JNI 的方式包括：Java 本地方法在 IBM i 上一個 Java 方法可以用 ILE 或者 PASE 環境下的其他語言來實現。使用 Invocation APIInvocation API 是 JNI 的一部分，它可以用來將 Java 虛擬機（JVM）嵌入到本機應用程序中，從而允許程序員從本機代碼內部調用 Java 代碼。同時也可以用其他語言通過 JNI 函數接口來調用 Java 代碼。JVMTI agentJVMTI（JVM Tool Interface）是 Java 虛擬機所提供的本地編程接口，是 JVMPI（Java Virtual Machine Profiler Interface）和 JVMDI（Java Virtual Machine Debug Interface）的更新版本。JVMTI 提供了可用于 debug 和 profiler 的接口；同時也支持監聽（Monitoring），線程分析（Thread analysis）以及覆蓋率分析（Coverage Analysis）等功能。JVMTI 提供一套本地代碼接口，因此使用 JVMTI 需要我們與 C/C++ 以及 JNI 打交道。開發時一般采用建立一個 Agent 的方式來使用 JVMTI，它使用 JVMTI 函數，設置一些回調函數，并從 Java 虛擬機中得到當前的運行態信息，并作出自己的判斷，最后還可能操作虛擬機的運行態。把 Agent 編譯成一個動態鏈接庫之后，我們就可以在 Java 程序啟動的時候來加載它（啟動加載模式），也可以在 Java 5 之后使用運行時加載（活動加載模式）。在 J9 內部崩潰J9 自身也可能存在 bug，從而導致虛擬機崩潰。其他與 J9 無關的本地代碼崩潰IBM i 引入 Java 虛擬機后，許多程序通過增加 Java 代碼來實現新功能。原有功能仍然由本地代碼實現。這些本地代碼中可能存在對內存的直接訪問 ( 如 C/C++ 代碼 )，不正確的指針訪問可能導致 JVM 崩潰。內存覆蓋導致的崩潰除了有可能造成直接崩潰以外，上面所提到的各種本地代碼在對不正確的內存地址進行寫入時，可能會覆蓋正確的內存數據，從而導致后面訪問了這些錯誤數據的代碼崩潰。收到異常信號J9 內部安裝了自己的信號處理函數，當收到某些信號比如 ABORT 時，J9 會產生 core dump 并使當前 JOB 退出。本地內存耗盡目前在 IBM i 上支持運行 32 位或 64 位的 J9 版本。對于 32 位的 J9 來說，由于地址模型的限制，J9 所使用的內存最多為 4GB。Java 堆以及本地內存都存放于這 4G 的地址空間中。當 Java 堆或本地內存地址耗盡時，一般情況下 J9 會拋出 java.lang.OutOfMemoryError 異常。但在本地內存不足時，有時也會造成 job 崩潰。例如創建線程或調用其他需要分配本地內存的 API 的時候。對于 64bit 的 J9，其地址空間達到 1 EB，因此一般沒有地址空間耗盡的問題。僅在極少數情況下可能因系統物理內存