长时间运行方法中的Java调试性能较慢

更新：一年多前我问了这个问题，但仍然没有答案。出于好奇，我用IntelliJ IDEA重现了我今天在Eclipse中观察到的问题

问题 我最近调试了一个类，该类包含一个执行大量操作的阻塞和长时间运行的方法。有趣的是，调试速度时而变化极大。我有一种感觉，速度与不同的调试方法（逐步进入、逐步结束、逐步返回、恢复）相关

用作实验的最小可重复性示例 我写了一个简单的例子，可以在以下课程的帮助下再现和测量我的感受：

测试类只是测量计数器在“长时间运行”操作中增加的频率。为了验证这个假设，我在调用

longRunningOperation

之前设置了一个断点来停止程序，然后应用了不同的调试方法

给定所示的断点，我使用不同的调试策略，在没有特定顺序的情况下执行了多次重复测量（以最小化系统错误的可能性）：

运行：只需执行程序（性能控制组）

不带断点：在调试模式下运行程序而不带断点

恢复：在断点处停止，然后继续执行（IntelliJ F9）

结束：在断点处停止，然后跨过长时间运行的方法（IntelliJ F8）

Into+Return：在断点处停止，然后进入长时间运行方法并退出（IntelliJ F7，然后SHIFT+F8）

进入+恢复：在断点处停止，然后进入长时间运行方法并恢复（IntelliJ F7，然后是F9）

实验结果 |#|运行|不带断点|恢复|结束|进入+返回|进入+恢复| |-----------|-----------|----------------|-----------|----------|-------------|-------------| | 1 | 863342711 | 862587196 | 872204399 | 14722473 | 12550871 | 870687830 | | 2 | 868929379 | 864245840 | 872166407 | 14139145 | 12487883 | 870626416 | | 3 | 865544040 | 852645848 | 872988659 | 14352193 | 12459235 | 871062770 | | 4 | 868100763 | 863198685 | 867518560 | 12261625 | 14696307 | 871365658 | | 5 | 865157647 | 866257267 | 862671156 | 12524087 | 14620150 | 868541690 | | 6 | 865348827 | 863449576 | 864416490 | 14410005 | 14592026 | 868784314 | | 7 | 866957323 | 865379147 | 873324542 | 14326951 | 12648924 | 868621635 | | 8 | 860129057 | 868993541 | 867785706 | 14434965 | 14380032 | 875011465 | | 9 | 865961737 | 857872085 | 871137322 | 12440011 | 12262172 | 871357411 | | 10 | 865517465 | 864911063 | 865109071 | 14544906 | 12391397 | 871574154 | | | | | | | | | |平均数| 865498895 | 862954025 | 868932231 | 13815636 | 13308900 | 870763334| |偏差| 0,00%| 0,29%|-0,40%| 98,40%| 98,46%|-0,61%| 每个调试策略都执行了10次，

System.out.println（res）

的结果显示在相应的列中。

Mean

行包含每个策略的10个测量值的平均值。

偏差

行包含与运行策略的相对偏差。结果是通过IntelliJ IDEA获得的，但在Eclipse中类似

问题: 结果表明，与其他选项相比，在调试过程中使用“跨步”或“跨步进入+跳出”来执行长时间运行的方法要慢10倍以上。然而，我无法解释为什么会发生这种情况？调试器在内部如何产生这种行为

注意：我使用Java 8和IntelliJ IDEA 2016.2在Windows 10上执行了测量

---

---

为了在您的机器上重现这种行为，我将这个小类放入了一个数组中。

我也观察到了这一点。在eclipse中必须是一个错误的步骤。我通常在一个复杂的方法之后设置断点，并使用恢复跳转到那里，而不是使用单步执行，因为通常恢复要快得多

由于单步执行可以在内部编程，与我设置断点并按恢复时的操作相同，这可能只是以一种不好的方式实现的

---

编辑：刚意识到这不一样。当您按下resume并跳转到断点时，您可能会在由其他线程触发的断点处停止。

我仍然遇到同样的问题，我相信这与其说是实现，不如说是Java调试（如果这是实现的错误，IntelliJ必须同样糟糕地实现它，而且两个IDE实现得如此糟糕对我来说似乎不太可能）

我在这里发现，这让我怀疑，当跳过代码时，Java从来不会一步一步地离开未优化的解释字节码。继续下去时，我相信它会检查到它可以运行到哪一点，并以优化的方式运行，这使它的运行速度大大加快。
但是请注意，这只是我个人的怀疑，我没有任何事实证明这一点（除了这些操作的执行情况）

然而，我确实找到了这个问题的“解决方案”，即：

运行到行

此功能将使代码一直运行到光标当前所在的行。因此，它的效果似乎与向该行添加断点、继续执行然后再次删除断点的效果完全相同。使用此方法，可以通过将光标放置在下一行并单击“hi”来“跨过”一行 | # | Run | W/O Breakpoint | Resume | Over | Into+Return | Into+Resume | |-----------|-----------|----------------|-----------|----------|-------------|-------------| | 1 | 863342711 | 862587196 | 872204399 | 14722473 | 12550871 | 870687830 | | 2 | 868929379 | 864245840 | 872166407 | 14139145 | 12487883 | 870626416 | | 3 | 865544040 | 852645848 | 872988659 | 14352193 | 12459235 | 871062770 | | 4 | 868100763 | 863198685 | 867518560 | 12261625 | 14696307 | 871365658 | | 5 | 865157647 | 866257267 | 862671156 | 12524087 | 14620150 | 868541690 | | 6 | 865348827 | 863449576 | 864416490 | 14410005 | 14592026 | 868784314 | | 7 | 866957323 | 865379147 | 873324542 | 14326951 | 12648924 | 868621635 | | 8 | 860129057 | 868993541 | 867785706 | 14434965 | 14380032 | 875011465 | | 9 | 865961737 | 857872085 | 871137322 | 12440011 | 12262172 | 871357411 | | 10 | 865517465 | 864911063 | 865109071 | 14544906 | 12391397 | 871574154 | | | | | | | | | | Mean | 865498895 | 862954025 | 868932231 | 13815636 | 13308900 | 870763334 | | Deviation | 0,00% | 0,29% | -0,40% | 98,40% | 98,46% | -0,61% |