IBM的Java诊断，第5部分 - 编程入门网

图 14. 命令行选项清单

Health Center 还能分析可能具有不良后果的 Java 配置和标记选项。例如，在部署的测试阶段添加 的选项可能没有在进入生产阶段之前删除。特别是，几个调试选项（如 -Xdebug 和 -Xcheck 选项）可能 对于在测试过程中发现问题很方便。但是，这些选项会增加性能开销，如果要获得最优性能，应该避免使 用这些选项。其他选项（如 -Xnoclassgc）也许能够提供一些性能好处，但面临扩展内存需求不确定的风 险。

我有足够的信息来诊断应用程序崩溃吗？

并不是所有的配置问题都与 Java 命令行 相关，有些问题的原因是底层系统属性。最显著的因素与 Linux® 和 AIX® 系统对一个进程使用 的资源的限制有关。CPU 使用、消耗的虚拟内存量、文件大小和内核文件大小可以使用 ulimit 命令限制 。尽管这个命令很有用，但它也可能会阻碍问题诊断。如果内核文件因为 ulimit 设置过低而被截短，则 几乎不可能从它们提取有意义的信息。在某些系统上，默认的 ulimit 设置几乎总是导致截短内核文件。 （内核文件是进程意外结束时操作系统自动创建的进程映像。对于诊断多种应用程序问题，特别是崩溃问 题，内核文件起到关键作用）。

由于内核文件只在问题出现时才生成，因此当找到有问题的 ulimit 设置时通常为时已晚：JVM 已经 崩溃，带走了诊断问题所需的所有信息。通常，确保 ulimit 不会阻止生成完整的内核文件的惟一方法是 猜测 ulimit 设置可能会出现问题，然后手动检查 ulimit 设置。遗憾地是，这并不是理想的方法，因为 它涉及相当模糊的知识和大量防御系统管理工作。Health Center 能够自动探测这种常见的服务能力问题 。使用 Health Center，没有必要亲自检查 ulimit 设置 — 它将在 ulimit 需要调整时发出一条 警告。

IBM的Java诊断，第5部分(10)

示例 3：评估系统稳定性

尽管在 Java 环境中崩溃并不常见，但 Java 应用程序仍然可能意外终止。这种崩溃有几个原因。一 个常见原因是：Java 代码通过 Java Native Interface (JNI) 调用本机代码，本机代码中的一个不安全 的内存访问触发了一个常规保护错误（General Protection Fault，GPF）。另一个常见原因是 Java 应 用程序已经耗尽内存堆，不能继续执行。Java 应用程序也有可能耗尽本机内存，这也会导致崩溃。由于 内存耗尽（Java 堆或本机内存）而导致的崩溃的特征是一个 OutOfMemoryException。

诊断一个内存漏洞

大多数崩溃都是不可预见的，但某些崩溃则不然。特别是，Health Center 试图预测由于 Java 堆耗 尽而导致的崩溃。Health Center 不能预测由于企图实例化一个过大的对象而导致的 OutOfMemoryException，但是大多数 OutOfMemoryException 的原因是内存泄漏：对不再需要的内存的引 用。这个内存不能被垃圾收集器释放。如果不需要的对象持续增加，最终将没有空间容纳需要的对象，这 时就会出现一个 OutOfMemoryException。图 15 展示了 Health Center 对一个存在内存泄漏的应用程序 使用的堆的形象化显示。应用程序的内存需求一直在持续上升，Health Center 发出一条警告，指出最终 可能会导致崩溃。

图 15. 可疑内存泄漏图

IBM的Java诊断，第5部分(11)

Heath Center 识别出漏洞后，如何修复漏洞呢？关键是要确定哪些对象正在使用泄露的内存。这种分 析最好从一个堆或系统转储进行。系统转储为堆中的每个对象创建一条记录，记录对象使用的内存量，哪 些对象正在引用该对象。持有对不再需要的对象的引用是 Java 应用程序中产生内存泄漏的最普遍原因。

没有工具支持的话，几乎不可能执行堆分析，好在我们有一些优秀的工具可

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!