modbus调试时间超时_Java调试器和超时

modbus调试时间超时

在代码中存在超时的情况下如何使用调试器。

我的调试器王国！

因此，您一直忙于编写一个项目，一切顺利，直到出现错误为止。您可以进入开发人员的工具箱，然后拔出调试器。很棒–您可以设置断点，可以在出现异常时中断，还可以在运行时检查表达式。无论等待什么挑战，您都可以肯定，调试器将为您提供帮助！

不幸的是生活并不那么轻松。许多代码都需要某种形式的超时 -一段时间后发生的事件。问题在于超时会破坏调试体验。您坐在那里看着断点，想着“现在为什么x是2而不是1？” of！超时开始，您将无法继续。更糟糕的是，JVM本身退出了！因此，您要经历增加超时，调试和解决问题的过程。之后，您要么将超时返回到其原始设置，然后必须再次执行相同的繁琐过程，要么将修复意外地提交到源代码树中，从而破坏了测试甚至是生产。在我看来，这似乎并不理想。

“出于某种原因，这是超时病，不信任任何朋友”

人们引入超时有很多原因。我在下面列出了一些优点和缺点，而且我敢肯定，您自己还会想到一些。

检查在一定时间内是否已响应异步事件。
避免饿死基于时间的资源，例如线程池。
您的比赛条件需要快速解决。
您正在等待事件发生，并决定用硬编码假设将花费多长时间。（在测试中最常见）

现在很明显，如果你超时被引入作为一个黑客那么它是一个很好的时间来清洁的童子军的代码。如果您需要依赖于测试中发生的事件，则应将这些测试视为API的客户端，并能够知道事件何时发生。这可能涉及注入在事件发生时被调用的模拟程序，或订阅事件流。如果您有比赛状况，请解决它！我知道这很痛苦而且很辛苦，但是您是否真的想让代码库中的定时炸弹准备好在凌晨3点生成支持电话？

管理超时

前面已经说过，我们应该删除超时的不良用法，很显然，超时是完全合法的用法。它们在事件驱动和异步代码中尤其常见。能够与他们一起调试仍然会很好。不管其他因素如何，良好实践都是为了使超时标准化为可在运行时设置的配置属性。这样，当您在本地IDE与生产环境中运行时，可以轻松更改它们。它还可以帮助管理从不同的硬件设置中遇到的不同性能属性。

将超时从代码中外部化为配置后，然后可以检测代码是否在调试器中运行，并在这种情况下将超时设置为明显更长的时间。这样做的技巧是认识到调试器涉及运行Java代理，该代理会修改运行该程序的程序的命令行参数。您可以检查这些命令行参数是否包含正确的代理匹配器。下面的代码片段显示了如何执行此操作，并且已经过测试，可以在Eclipse和Intellij IDEA下工作。

RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean();
String jvmArguments = runtimeMXBean.getInputArguments().toString();
boolean hasDebuggerAttached = jvmArguments.contains("-agentlib:jdwp");

我可以理解为什么有些人也将其视为黑客，您通过查看自己的命令行参数然后围绕它进行调整，从而积极地发现有关您环境的某些信息。从我的角度来看，我发现这是一种有用的技术。它确实使在存在超时的情况下调试起来更加容易。