• 查看本机内存与 Java 对象之间的链接 — 也就是说，哪个 Java 对象消耗的内存最多。
• 列出应用程序中出现的所有 JNI 引用。
• 在已分配内存中搜索已知值。
• 查看应用程序本机内存使用情况的汇总报告。

工件分析器

工件分析器处理指定工件的完整内容，查找各种常见错误，例如多线程应用程序中的死锁线程。它们可以构成一幅 JVM 全图，在 JVM 终止时提供对其状态的统计分析。此信息可用于确定 Java 对象的数量和类型，它们可以帮助您确定 Java 堆的空间是否已耗尽。处理这些数据本身就有许多挑战，并且需要在最终的 API 设计中考虑它们。特别重要的一点是，引入对可用于检索对象的对象查询语言的支持。API 可以支持使用列表对象来改进此方法。

Java Debug Interface (JDI) 连接器

一般生成的后期工件都是硬盘上的内核文件，运行 JVM 的进程的完整内容都将写入到其中。在其他一些编程语言中，您可以将一个调度器附加到这个文件，然后使用它查看内容并初步了解出现问题的原因。Java 语言目前定义了一些接口和标准，它们定义了如何将调试器连接到运行中的 JVM。后期 JDI 连接器的作用是允许您使用这些标准接口连接到内核文件，而不用运行 JVM。这样，您便可以在 jdb、Eclipse 或 NetBeans 等标准 Java 调试器中调试工件。

帮助定义标准

虽然 JSR 和 Apache 项目已经开始，但它们都还处于早期阶段。JSR 326 和 Apache Kato 项目都在寻找人员定义一个用于分析后期工件的 API，或者为参考实现和工具贡献代码。参与 API 开发和贡献代码的机会很多。这是参与这个全新的开源项目的难得机会，它与比较成熟的 Apache Software Foundation 项目有所不同。

为 JSR 326 做贡献

JSR 326 完全是关于解决实际问题的。如果您遇到了问题，我建议您通过邮件列表与 Expert Group 共享它们。（这些关于构建该 API 的讨论将保存在与 Apache Kato 项目相关的邮件列表上；请参见 参考资料）。这样，专家组便能确保定义的 API 将考虑到所有应用和情形。它对于 Expert Group 采用最佳方法处理这些问题非常重要。他们尤其欢迎来自以下人员的反馈：

• 使用后期诊断的人员（比如说故障查看人员或堆管理人员）。专家组希望了解您需要解决的问题类型，以及您所使用的工具。了解工具是否能实际解决问题也是很有用的（以及为何不能解决问题）。
  
  
• 后期诊断工具提供商（商业和开源应用程序）。关于您为 Java 开发创建诊断工具的体验以及希望标准 API 能解决哪些问题的反馈是很有价值的。

您还可以加入专家组，但需要具备规范指定领域的一些知识。

为 Apache Kato 做贡献

您现在已经知道，Apache Kato 项目并不仅仅是 JSR 326 的一个参考实现。它还包括使用 API 的最佳实践，以及一个 wiki 和其他文档资源。如果您希望为此项目做贡献，我建议您上网了解当前正在开发哪些项目，以及哪些领域明确需要帮助（参见 参考资料）。

结束语

我希望本文能够让您了解 JSR 326 和 Kato 涵盖的一些方面。一些相关方面更加具有通用性，但不属于本文的讨论范围。还需要考虑的一些方面包括：

• 处理大量数据，确保实现良好的性能，并且最终解决方案能够按需执行。这将涉及到传输和扫描数据等。
• 开发缓存策略和它们的后续实现。
• 使用轻量级、延迟加载的对象确保性能。
• 能够整合一种对象查询语言。

本系列的第二篇文章将探究各种后期分析场景，以及如何使用 Apache Kato 项目提供的各种工具和技术解决它们。此外，还将深入讨论项目如何利用 JSR 326 实现所需的结果，同时解决第 1 部分讨论的基本问题，比如大数据集导航。 （责任编辑：A6）