jvm崩溃原因官方（eclipse 打开java 崩溃）

本文目录

• eclipse 打开java 崩溃
• JVM崩溃是什么原因
• 如何在 IBM i 上分析 J9 虚拟机崩溃问题

eclipse 打开java 崩溃

这句话：
# The crash happened outside the Java Virtual Machine in native code.
是在说，进程崩溃发生在 JVM 之外的 native 代码，因此这是第三方的 dll / so 库的问题，不是 Java 的毛病。具体原因不清楚，本身这个 dump core 错误只是给 JVM 的开发支持人员看的，我们作为应用程序开发人员是看不懂它的日志的，除非你同时也精通 C / C++ 或汇编。
看上去你使用 -server 方式启动 eclipse，是想让 eclipse 得到更好的性能，它本身会导致 jvm 申请更多的内存，可能会挤压其它应用程序的内存需求，比如当你在同一台机器又开另一个程序来 debug 时。一般来说 -server 方式是给专职服务器用的，它们基本上不存在把进程在前台和后台之间频繁切换，也不存在多个应用程序抢内存的事情。
当内存紧张时 JVM 本身的内置的 API 的 dll 部分也经常会报告错误，比如读取一个 jar 会打开一个文件输入流都可能出现未知异常，但一般 jvm 知道这件事，它不会说：崩溃发生在 jvm 之外。

JVM崩溃是什么原因

Java的应用有时候会因为各种原因Crash，这时候会产生一个类似java_errorpid.log的错误日志。可以拿到了
这个日志，怎样分析Crash的原因呢？下面我们来详细讨论如何分析java_errorpid.log的错误日志。
一. 如何得到这个日志文件
如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。缺省情况下，这个
文件会产生在工作目录下。但是，可以在Java启动参数通过下面的设置，来改变这个文件的位置和命名规则。例如：
java -XX:ErrorFile=/var/log/java/java_error_%p.log
就将这个错误文件放在/var/log/java下，并且以java_error_pid.log的形式出现。
二.产生错误的原因
造成严重错误的原因有多种可能性。Java虚拟机自身的Bug是原因之一，但是这种可能不是很大。在绝大多数情况下，是由于系统的库文件、API或第三方的库文件造成的；系统资源的短缺也有可能造成这种严重的错误。在发生了Crash之后，如果无法定位根本原因，也应该迅速找到Work Around的方法。
三.对日志文件的分析
首先要检查日志的文件头：例如，下面是从一个客户发过来的错误日志的文件头

如何在 IBM 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 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，因此一般没有地址空间耗尽的问题。仅在极少数情况下可能因系统物理内存