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，因此一般沒有地址空間耗盡的問題。僅在極少數情況下可能因系統物理記憶體
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，因此一般沒有地址空間耗盡的問題。僅在極少數情況下可能因系統物理記憶體