Java™ 应用程序出现故障时生成的工件可以帮助您分析故障的根源。Java Community Process 正在开发一个标准 API 来帮助执行后期分析，正在开发的 Apache Kato 项目将为此 API 生成参考实现和工具。本文是本系列文章的第 1 部分，主要介绍 Post mortem JVM Diagnostics API (JSR 326) 并概述 Kato 如何帮助您利用它。第 2 部分将更加深入地探索后期分析场景。

本文是本系列文章的第 1 部分，主题是介绍如何使用应用程序意外终止时生成的工件分析 Java 代码的问题。Java Specification Request (JSR) 326 正在开发之中，它将定义一个行业标准 API 来实现此操作。您将了解 Apache Kato 项目所交付的参考实现和示例工具，以演示如何使用此 API。借助这些工具，您将能够分析各种问题，比如内存不足错误，或者只是浏览可用的工件。本文将提供关于 JSR 326 和 Kato 项目的一些背景知识，然后讨论一些常见的后期分析场景，并概述所涉及的问题。第 2 部分将更加详细地研究各个场景，扩展待解决问题，并展示如何使用 API 解决它们。

实时监控和后期分析

两个主要类别定义了如何诊断运行中的 Java 应用程序的问题。第一种类别是实时监控：您观察运行中的虚拟机的行为，比如说监控创建对象的频率以及它们在垃圾收集之前的生存期。目前存在许多开源及商业的实时监控工具（参见 参考资料）。第二种类别是后期分析。当运行中的 JVM 遇到致命错误时，它所使用的进程将终止，并且将生成一系列工件。根据错误的严重程度，JVM 可以在其关闭时创建这些工件，或者由操作系统来创建它们。后期分析就是在 JVM 出现故障后分析这些工件。

生成后期工件 运行中的进程并非一定要终止才能生成后期工件，这还得取决于不同的 JVM 提供商。当您意识到在许多情况下都是 JVM 本身在创建工件时，则不难理解此进程可以在任意时间触发。这带来了有趣的诊断功能，比如说指示 JVM 创建抛出特定异常时所需的工件，然后使用适当的工具诊断异常的根源。

实时监控工具支持连接到所有 JVM 提供商都支持的大量标准 API 和接口（比如 JVM Tool Interface），因为它们是 Java 语言规范的一部分。相反，后期工件通常是不透明的数据块。典型的例子包括内核文件、堆块和各种内部格式及结构仅为供应商所知的系统块，但一些格式是公共文档。这让编写诊断工具的人难以创建仅适用于有限 JVM 实现的工具。幸运的是，社区正在努力解决这个问题。

JSR 326 和 Apache Kato

JSR 326 正在努力定义用于访问包含在后期工件中的数据的标准 API。它旨在通过 4 种方式解决 Java 社区的需求：

• 促进工具生态系统的发展，增加可用工具的数量。
• 提高不同 JVM 提供商的工具的质量和功能。
• 允许开发人员解决自己的问题，而不需要依靠第三方的支持。
• 解决影响当前分析执行方式的长期问题。

JSR 326 Expert Group 将定义 API 用于解决的问题和场景。然后，这些用户场景将用于形成 API 的外观和行为。Expert Group 将考虑一些比较有趣的设计挑战包括：

• 有效在大数据集中导航。
  
  
• 管理异常处理战略和规则，管理检测到或未检测到的异常的使用。
  
  
• 要使用的记录机制。
  
  
• 实现的可选择性。在设计用于与大量独立定义的后期工件交互的 API 时，各实例中呈现的信息应该有所区别。这意味着您必须定义一个机制，它能让 API 的实现指示所请求的信息不可用。因此，可以编写一些工具来合理地处理缺少的数据。
  
  
• 发行版之间的向后兼容性。

无论您对于后期诊断是否有特别的兴趣，我们讨论的设计基础都具备比较通用的特性，并且能为您提供帮助。无论如何，请参见 参考资料 获取所有必要的链接，以查看 JSR 326 或为其做贡献。

未来问题 JSR 326 的需求之一是解决将影响后期诊断的未来问题或行业趋势。第一个问题是，已有后期工件的大小将会增加。随着计算机行业向 64 位、多核和多处理器服务器发展，工件可以包含的信息量可能会大大超过可用大容量存储器的支持。即便能够 存储它们，还需要面对处理数据或将它们发送给能处理它们的目标的后续问题。另一个问题是，当工件包含来自不同提供商的多个 JVM 的信息时，应该如何处理这种情况。