如果调试行为与正常执行不同,该怎么办?

两种解决方案:

b) 编写一个试图重现问题的测试用例。即使您无法通过这种方式找到它,这也会清理您的代码,有时还会解决问题。

我试着验证我的假设,并再次验证它们。

在某些情况下,过度日志记录可能会有所帮助,但并不总是如此。对我来说,这没什么帮助。

我的个人解决方案是特定于Java的。自JDK1.5以来,Java类加载器没有完全加载类。在调试会话中,必须完全加载它。因此,一些变量没有很好地初始化,并且输出与正常运行不同。

调试多线程应用程序确实很困难。

您可以尝试使用旧的System.out.println技术进行调试,而不是使用调试器。。。可能这将允许您在具有您提到的不同行为的同时进行调试。

先检查一些简单的东西。崩溃版本是否获得相同的命令行参数?还是特殊的环境变量?还是用户ID?或者其他一些你知道很重要的因素。换句话说,您是否真的使用相同的输入来运行它。 它一直在崩溃吗?它在同一个地方坠毁吗?如果你能在崩溃后连接一个调试器,它可能会提供一些线索。最近的一些变化可能是罪魁祸首吗?如果是这样,请尝试移除它,看看会发生什么。

否则,请停止微分分析并解决问题。也就是说,直接看看崩溃中出了什么问题,而不是重述可能的原因。

下面是一些书籍特例,可以帮助您“在没有调试器的情况下进行调试”。

Chapter 5, "Debugging" from "The Practice of Programming"

The 9 rules from "The 9 Indispensable Rules for Finding the Most Elusive Software and Hardware Problems

祝你好运

注意:不需要多线程相关。

对我来说,设置不同的断点有时会有所帮助。

其次,您的“假”断点可能会抑制并行性和竞争条件。

我遇到了类似的事情。

Set.iterator debug 而且 run

当然,我的代码有一个错误,它间接地依赖于集合元素的顺序。