java 调试 工具

Java调试是一个复杂的空间。 调试器的类型很多，工具也很多。 在此页面中，我们将介绍7种类型的调试器之间的区别，并查看每个类别中的主要工具，以帮助您为正确的工作选择正确的工具。

以下是我们介绍的调试器类型：

• CLI调试器
• IDE调试器
• 构建自己的调试器
• 堆转储
• 历史调试器
• 动态追踪
• 生产调试
• 塔基皮

定义

使用广泛的定义，错误是实例，其中我们编写的代码与我们获得的输入不匹配。 这些的不同影响可以大致分为–

1. 意外的流控制 ，导致异常或代码中我们不希望出现的位置。 在这里，调试器通常用于检查代码和状态的相关性。
2. 意外的堆分配 。 在这种情况下，我们要么分配了太多的对象，要么分配了太大的对象。 保留对这些内容的长期引用只会增加乐趣。 这就是堆分析器起作用的地方。
3. 延迟流量控制 。 这很可能与我们将错误的输入传递给外部调用（即“ SELECT * FROM everything”）或卡在长循环或无限循环中有关。 这是性能分析器通常会出现的地方。

当然，工具和类别之间存在重叠，因为它们本质上都具有相同的目的-让我们看到我们所期望的状态，以便我们可以修复代码，并使其达到期望。

1.命令行调试器

主要工具 ：主要参与者是jdb ，它是JDK附带的，与JVM等效，是gdb。 它具有命令行界面，可以连接到正在运行的JVM。 像gdb一样，它的功能也很强大，您可以使用jdb进行任何功能，就像使用功能强大的IDE调试器一样。 jdb有一个补充-jstack-它使您可以在给定时刻打印实时JVM的线程调用堆栈。 但是，这不会捕获变量或堆状态。

在以下情况下使用 ：jdb的最大优点是其可移植性。 您可以相当快地将其安装到服务器上，而不必远程连接调试器。 如果您正在处理服务器上的恶劣环境，并且有能力让JVM检查它，那么jdb是您最好的朋友。

缺点 ：jdb和jstack的缺点是，与其他命令行工具一样，它们在日常使用中效率不高。 这将我们带入下一个类别。

2. IDE调试器

主要工具 ：Eclipse和NetBeans是该类别中的两个工具。 两者都使用与jdb类似的技术来附加或启动新的JVM。 尽管不是很轻便，但您确实会遇到麻烦，这可以使调试更短，更有趣。

在以下情况下使用 ：假设您每天都不是Dexter（ 神童 ，而不是连环杀手）。

缺点 ：作为高端桌面应用程序，它们不是您要在生产计算机上运行的东西。 始终存在进行远程调试的可能性，但是在复杂的环境中，解决该问题的可能性很小。

3.构建自己的调试器

到目前为止，我们已经描述的所有调试器都基于相同的JVM开放调试体系结构，最常见的是使用JDWP（Java调试器有线协议）与正在运行的JVM通信。 JSwat是在此框架之上构建的独立调试器的示例。 是否想学习如何构建自己的Java / Scala调试器？ 请点击这里 。

在以下情况下使用 ：构建自定义JVM扩展，或者对JVM的工作方式非常感兴趣。

缺点 ：这是一件很复杂的事情，尤其是当您不想影响目标JVM的状态时，这是非常正确的事情，因此，您需要一个非常有说服力的理由来说明为什么不能使用经过考验的现有工具。

4.堆转储

主要工具 ：jmap，MAT。 在许多情况下，就像Rick Grimes一样 ，您正在与死者打交道。 在这些情况下，您正在查看的是JVM堆的快照，而不是已停滞的实时JVM的快照。 JDK附带的jmap允许您从实时JVM生成堆转储。 有很多工具可以让您浏览和分析转储。 JDK附带的jhat和visualVM在这方面做得很好。 Eclipse插件MAT和NetBean的HeapWalker是很好的选择，因为它们利用了已经强大的IDE UI。

在以下情况下使用 ：发生复杂错误且无法应用常规调试技术（例如，该应用程序在客户的服务器上运行）。 另一种选择是通过打开JVM -HeapDumpOnOutOfMemoryError标志来使用堆转储来分析内存泄漏，以使JVM在堆耗尽后自动转储堆的内容。

缺点 ：使用堆转储的最大缺点是它们的重量与堆本身的重量一样大（这很可能意味着堆在GB中）。 然后必须将其转回给您进行分析。 在生产中捕获它们也不是在公园中漫步。

5.历史调试器

主要工具 ：这类工具取决于您是否能够或不想停止JVM来收集状态或进行堆快照。 Chronon DVR是这种方法的一个很好的例子。 在此，调试器使用字节码检测从代码本身内部记录数据。 这通常包括诸如调用方法的顺序以及传递给它们的参数之类的事情。 这使调试器可以“重播”代码，并让您了解执行时的流控制。 重播解决方案（由CA收购）是另一种使用不同方法的示例，其中记录了对JVM的IO输入，然后将其“重播”回活动实例–模拟执行后的代码。

在 以下情况下使用 ：此类工具的主要途径通常是在质量检查期间，通过捕获实际的运行时状态，它们可以帮助使错误更易于重现。 另一种情况是让客户或支持工程师临时运行该工具，以在应用程序在生产中表现异常时从JVM捕获状态。

缺点 ：这些工具的最大缺点是日志记录会花费您很多，而日志记录会花费很多。 这意味着历史悠久的调试器可以将应用程序的速度降低50％到一个数量级，从而限制了可以使用这些应用程序的生产方案的数量。

6.动态跟踪

主要工具 ：BTrace。 使用此类别中的工具，您可以从正在运行的JVM中有选择地打印（“跟踪”）状态信息，而无需暂停它，也不必记录正在发生的一切。 可以将它视为动态编织到一段新代码中，该新代码从代码本身中打印值以供您查看。 BTrace是一个杰出的工具，它引入了自己的语法，可让您定义要在代码中跟踪的位置和内容。 该语法还设计为仅支持只读操作，以防止您实际更改程序的状态或引起无限循环。

在以下情况下使用 ：最常用于尝试针对特定问题调试服务器（例如，连接池已耗尽）或在不停止JVM执行的情况下临时收集特定统计信息的情况。

缺点 ：与调试器一样，通常不建议从生产服务器进行动态跟踪（并且很多时间是不允许的）。 还有一个小的学习曲线，可以在服务器环境中有效地使用动态跟踪。

7.生产调试

主要工具 ：用于记录状态的日志记录框架（log4j，Logback）和用于大规模分析数据的日志分析器（Logstash，Splunk…）。

在以下情况下使用 ：这是一个相当困难的区域，因为当您处理生产系统时，使JVM停顿以查看状态或进行堆转储通常是很大的禁忌。 那是因为您实际上是要关闭服务器来调试它，这通常仅在极端情况下才能完成。

我们通常在运行时从JVM中提取状态而不停止状态的方法是通过有选择地将变量值记录到文件中（通常是在Java记录框架的帮助下）。 稍后，我们可以使用各种工具来解析数据，从简单到尾部，一直到可扩展的日志分析器，例如开源Logstash和企业Splunk。

缺点 ：这里最大的缺点是我们当然需要事先知道（并有效地执行）登录。 日志也可以很快被填满，并且无需开发团队的大量纪律，还可能包含很多不必要的数据或错过了一些关键数据。

科学家观察到，将日志文件中的数据拼凑在一起以了解导致错误的变量状态，这是夜间和假日消遣的一种非常受欢迎的开发人员。

我们在构建Takipi时考虑了一个简单的对象。 我们想让开发人员轻松知道何时以及为何中断生产代码。 这意味着，无论何时开始发生新的异常或日志错误，我们都会捕获它并通知您。 第二部分是跟踪部署，以说明问题从哪个开始以及发生的频率。 最后（也是最有趣的部分）是生产调试部分。 对于每个异常或错误，Takipi会在错误发生时向您显示确切的源代码和变量状态（包括本地值和对象值），就像发生错误时您在那儿一样。

翻译自: https://www.javacodegeeks.com/2013/12/java-debugger-the-definitive-list-of-tools.html

java 调试 工具