JVM崩溃时：如何调查最严重错误的根本原因

当应用程序崩溃时，您可以学到什么？

我认为，“后见之明是20 /”是最喜欢的短语之一托马斯·罗梅尔，工程ZeroTurnaround的副总裁。好吧，我实际上不确定在他的短语中占什么位置，但是我已经听过他几次说了。鉴于这意味着回顾过去，您可以对事情进行推理比预测将来发生的事情要好得多，通常发生在我们未能正确预测事情并反映行动结果的情况下。如果您经常听到此短语，则意味着您经常对事情进行反思，并且您知道每一次失败，每一次错误都会提供一个教训。

好吧，可能是您没有犯错误，或者您没有犯任何会传播到最终产品以及最终用户的重要错误。我确实偶尔制作它们，不止一次，我对服务器进行了多次轰炸，并且无数次提交了损坏的代码。有时它也会滑入最终产品。每当我写的破损代码再次咬我时，我都会学到一些东西。每次我必须调查造成错误的原因是什么，将其复制到我的机器上并进行修复。

在这篇文章中，我想看看可以帮助您获得有关错误的相关信息并帮助您重现和修复它们的工具和技术。

新帖：JVM崩溃时：如何调查最严重错误的根本原因http://t.co/bvHVYhT2m4 pic.twitter.com/dKhgiKMhT5

— Takipi（@takipid） 2015年4月27日

结构化日志

弄清楚某些代码中发生了什么的默认goto方法是阅读源代码。当该来源实际上是您每天工作8-10个小时而仍然找不到罪魁祸首时，则您必须在错误发生时添加一些有关上下文的情境意识。自然地，您可以从日志中获取该上下文。我毫不怀疑您一直在使用日志，但这是您可以做的一个很好的技巧，可以使日志更加有用。

线程名称

如果配置线程名称以反映应用程序中发生的事情，则可以获得有关上下文的更多信息。线程名称几乎总是包含在日志中，并且打印线程名称不会带来任何明显的性能开销。例如，找出记录器的调用方类需要花费时间，因为您必须构造和遍历堆栈跟踪。但是访问线程名称既快速又便宜。另外，线程名很少用于其他任何事情，因此，在您认为合适的地方充填尽可能多的信息：系统组件名称，事务ID，发出请求的用户名等。稍后在调试问题时，您将感谢这些详细的日志，轻轻松松。

现代开发人员工具

等一下您是否要告诉我，在21世纪，没有什么比找出日志并从早期石器时代采用取证技术更好的方法来弄清您的应用程序中发生了什么？好吧，不是真的。但是我不知道有什么通用工具可以为您提供最佳的见解，以了解代码中发生了什么以及为什么发生这种情况。

在开发环境中，情况变得更容易，您拥有大量的备用计算资源，并且可能会冒险附加不需要经过Ops批准流程的各种工具。

例如，以Plumbr的IvoMägi的帖子为例，他讨论了他们的内存泄漏检测工具是否适合操作人员或开发人员。理想情况下，该工具是有用且稳定的，因此您既可以在开发过程中享受其性能和功能，又不必担心将其附加到实时系统中。但是这种情况很少发生，您不需要在生产环境中进行调试，也不想与JRebel即时交换类，等等。

但是，这并不意味着您根本不应该使用任何现代工具，而应该将自己限制在老式的，但已被证实的发现邪恶根源的方法上：日志。毫无疑问，日志仍将是您将获得的最有用的取证信息来源，但是您可以做得更好。

通常，开发过程包括大量盯着代码，思考并有时在此处和此处更改功能位。这是一项艰苦的工作，需要集中精力解决问题和系统逻辑。如果您知道使事情变得更轻松的方法论或一些神奇的秘诀，请在Twitter上与我分享智慧： @shelajev 。在此之前，我们将以软件工程需要集中精力为前提。这意味着任何工具都有两个主要的非功能性要求：在功能上必须强大，并且必须具有非侵入性，因此您不必在如何实现所需的功能上费心。

重现某些条件的最有效方法是对其进行测试。当它不可用时，下一个最好的事情就是使用一个录制调试器，例如Takipi进行生产调试或Chronon 。

使用Chronon，您可以记录代码中发生的操作，它们产生的结果，每给定时刻堆栈中的内容以及产生程序执行的事务日志的记录。稍后，您可以将此日志提供给另一个程序运行，并来回逐步执行。

如果您要查明性能问题，则可以使用Java Mission Control的 Java Flight Recorder收集有关程序执行配置文件，垃圾收集统计数据，堆使用情况数据（例如对象分配，锁和IO详细信息）的信息。如果要运行附加到生产节点上的Java Mission Control，您必须支付许可证的费用，但是对于开发环境，则没有这样的问题。

再说一次，如果要监视生产环境，则可能需要一个错误管理解决方案，该解决方案专门为获取尽可能多的错误信息而创建。

塔基皮分析