如题所述
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 API
Invocation API 是 JNI 的一部分，它可以用来将 Java 虚拟机（JVM）嵌入到本机应用程序中，从而允许程序员从本机代码内部调用 Java 代码。同时也可以用其他语言通过 JNI 函数接口来调用 Java 代码。
JVMTI agent
JVMTI（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，因此一般没有地址空间耗尽的问题。仅在极少数情况下可能因系统物理内存
在与 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 API
Invocation API 是 JNI 的一部分，它可以用来将 Java 虚拟机（JVM）嵌入到本机应用程序中，从而允许程序员从本机代码内部调用 Java 代码。同时也可以用其他语言通过 JNI 函数接口来调用 Java 代码。
JVMTI agent
JVMTI（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，因此一般没有地址空间耗尽的问题。仅在极少数情况下可能因系统物理内存
温馨提示：答案为网友推荐，仅供参考
