崩溃或致命错误导致进程异常终止。有各种可能的理由导致崩溃。例如，崩溃可能是由于HotSpot VM、系统库、Java SE 库或API、程序本地代码、甚至操作系统里的 bug。极端因素如操作系统资源耗尽也可以导致崩溃。

因 HotSpot VM 或 Java SE库代码导致的崩溃是罕见的。本章提供如何检查崩溃的建议。有时候可以变通崩溃直到导致崩溃的源被诊断和修复（也就是可以避开崩溃）。

通常，崩溃的第一步是定位致命错误日志。这是HotSpot VM生成的文本文件。附录C-致命错误日志 解释了如何定位文件和文件的详细描述。

4.1 崩溃样本

本节展示一些样本来说明错误日志是如何用于启发崩溃原因的。

4.1 测定哪里发生崩溃

错误日志头显示了有问题的帧。见 C.3 格式头。

如果顶层帧是本地帧且不是操作系统本地帧，这表明问题可能发生在本地库，而不是在JVM里。解决崩溃的第一步是研究本地库发生崩溃的源。有三个选择，取决于本地库的源。

如果本地库是由你的程序提供，研究你的本地库的源代码。选项 -Xcheck:jni 可以帮助查找本地 bug。见 B.2.1 -Xcheck:jni 选项。

如果你的程序使用的本地库是由其他供应商提供，报告bug，提供致命错误日志信息。

继续阅读 →

本章为挂起或循环进程的故障排除在特定程序上提供了信息和指导。

问题在涉及挂起或循环进程时发生。挂起可能因为多种原因发生，但经常是源于程序代码、API代码或库代码里的死锁。挂起甚至是因为 HotSpot VM的bug。

有时候，一个表面上是挂起的可能是个循环。例如，VM进程里的bug导致一个或多个线程进入死循环，会消耗掉所有可得CPU周期。

诊断挂起的最初步骤是找出VM进程是空闲还是消耗了所有可得CPU周期，为做这个要求使用操作系统工具。如果进程表现为繁忙且消耗了所有可得CPU周期，那么问题很可能是循环线程而不是死锁。

继续阅读 →

内存泄露故障排除

如果你的应用程序执行的时间越来越长，或如果操作系统执行越来越慢，这可能是内存泄露的指示。换句话说，虚拟内存被分配但在不需要时没有归还。最终应用程序或系统没有可用内存，应用程序非正常终止。

这篇文章提供了一些涉及内存泄露的问题诊断的建议。

3.1 OutOfMemoryError 的含义

一个最常见的内存泄露的指示是 java.lang.OutOfMemoryError 错误。这个错误在Java堆或堆的特定区域没有足够空间用于分配对象时抛出。垃圾收集器不能创造更多可用空间来容纳一个新的对象，堆也不能扩展。

当 java.lang.OutOfMemoryError 错误抛出时，栈轨迹也会被打印。

java.lang.OutOfMemoryError 也可以被本地库代码抛出，当本地分配不能满足时，例如，交换空间很低。

诊断 java.lang.OutOfMemoryError 的一个早期步骤是确定错误的含义。它是否意味着Java堆满了，或意味着本地堆满了？为帮助你回答这个问题，下面的子章节解释了一些可能的错误信息，还有连接到更详细信息的链接：

继续阅读 →