在调试模式下运行 JVM 的副作用
我想在调试模式下释放 Java 应用程序，以便在客户端出现随机或难以重现的问题时更轻松地进行调试。
但是，我想了解这样做的潜在副作用？从Java HotSpot文档看来，有 应该不会造成性能损失。
从链接
全速调试
Java HotSpot VM 现在使用 全速调试。在之前的 调试时虚拟机的版本 启用后，程序执行使用 只有口译员。现在，完整的 HotSpot的性能优势 技术可用于程序， 即使使用编译后的代码。改进后的 性能允许长时间运行 程序更容易调试。 它还允许测试继续进行 全速。一旦有一个 例外，调试器启动时使用 对代码源的完全可见性。
这是准确的还是存在隐藏的警告，内存占用情况如何，以及使用调试模式时是否存在任何其他隐藏的问题。
PS：我发现 这篇文章证实了我最初的怀疑，即 oricale 的原始文章并未显示完整的故事。
I'd like to realease a Java application in debug mode to allow for easier debugging when random or hard to reproduce problems occur on the customer side.
However, I want to get a heads up on potential side effects of doing this? From the Java HotSpot Documentation it seems that there should be no performance penalty.
From the link
Full Speed Debugging
The Java HotSpot VM now uses
full-speed debugging. In previous
version of the VM, when debugging was
enabled, the program executed using
only the interpreter. Now, the full
performance advantage of HotSpot
technology is available to programs,
even with compiled code. The improved
performance allows long-running
programs to be more easily debugged.
It also allows testing to proceed at
full speed. Once there is an
exception, the debugger launches with
full visibility to code sources.
Is this accurate or are there hidden caveats, what about memory footprint and are there any other hidden gotchas while using debug mode.
PS: I found this article from AMD which confirmed my initial suspiciion that the original article from oricale doesn't show the full story.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不能代表 HotSpot，也不会正式代表 IBM，但我会说，肯定存在合法类型的优化，如果中间需要反编译，则无法完全撤消这些优化，因此“当您可能使用的生产 JVM 中要求进行调试时，将启用该选项。
想象一下这样一种情况：优化器发现程序的一部分被证明是不需要的，并且根据各种语言规则（包括 JSR 133）可以合法删除，JVM 将希望删除它。一个问题是调试：删除代码对于人类单步执行它来说看起来很奇怪（变量不更新，单步执行时可能不会停止在行上），因此选择是在这些情况下禁用所述优化。对于堆栈分配对象等选项也可能如此。因此，虽然 JVM 说它是“全速”，但实际上更接近“几乎全速，其中一些更时髦的选项无法完全撤消删除” 。
I can't speak for HotSpot, and won't officially for IBM, but I will say there are certainly legal kinds of optimization that aren't possible to undo fully should a decompilation be required in the middle of them, and thus aren't enabled when debug is being asked for in the production JVMs you are likely to use.
Imagine a situation where the optimizer discovers a part of the program is provably not required and by the various language rules (including JSR 133) is legal to remove, the JVM will want to get rid of it. The one wrinkle is debug: removing the code will look odd to the human stepping through it (variables not updating, possibly not stopping on lines when stepping) so the choice is to disable said optimizations in those cases. The same might also be true for opts like stack allocated objects, etc.. so while the JVM says it's "full speed" it's actually closer to "nearly full speed, with some of the funkier opts that can't quite be undone removed".
这个问题很老了，但是当我搜索如果您只是保留 -agentlib:jdwp... 时对性能的影响，但没有积极调试时，就出现了。
摘要：从调试选项开始但不连接现在不会影响速度（Java 7+）。
在java 6（ish）之前，您使用-Xdebug，这产生了一定的影响，它关闭了JIT！
在 java 6 中，他们将其更改为 -agentlib 并使其变得更好。虽然存在一些错误，但确实导致了性能损失。这是针对 openjdk 提交的错误之一，我的猜测是 oracle/sun 版本也存在类似的问题： https://bugs.openjdk.java.net/browse/JDK-6902182
但请注意，所声明的目标是仅通过打开端口来启用调试不会导致任何性能损失。
看起来，至少在 openjdk 中，这些 bug 已经被 java 7 清理掉了。之后我没有看到任何关于性能的影响。
如果您进一步研究并发现负面结果，请记下进行测试的 java 版本 - 我看到的所有内容都指 7 之前的版本。
我很想听听是否有人在最近刚刚离开的虚拟机中遇到性能问题端口已启用。
This question is old but came up while I was searching for any performance impact if you just leave -agentlib:jdwp... on but are not actively debugging.
Summary: Starting with debugging options but not connecting shouldn't impact the speed now (Java 7+).
Before java 6 (ish) you used -Xdebug and this had a definite impact, it shut off the JIT!
In java 6 they changed it to -agentlib and made it better. there were some bugs though that did cause a performance penalty. Here is one of the bugs that was filed against openjdk, My guess is that there were similar problems with The oracle/sun version: https://bugs.openjdk.java.net/browse/JDK-6902182
Note however that the stated goal is that simply enabling debugging by opening the port should not cause any performance penalty.
It looks like, at least in openjdk, the bugs were cleaned up by java 7. I didn't see anything about performance impacts after that.
If you research this further and find negative results, take note of the java version the testing was done under--everything I saw was referring to versions before 7.
I'd love to hear if anyone encountered performance problems in a recent VM just leaving the port enabled.
如果您计划在启用远程调试的情况下运行应用程序，它也会影响安全性。远程调试会在您的计算机上打开一个端口，通过连接到它，我可以对您的应用程序执行各种有趣的操作。
If you plan to run the app with remote debugging enabled, it can affect security also. Remote debugging leaves a port open on your machine, and by connecting to it, I can do all sorts of fun things with your application.
该程序在调试模式下肯定不仅仅只是运行，因此很明显性能不可能相同。但是，如果您仔细阅读该声明，它表示新版本即使在调试模式下也可以运行完全优化的代码，而这在以前是不可能的。因此，新的 jvm 比以前的 jvm 快得多，以前的 jvm 只能在没有优化的解释模式下运行。
The program definitely does lot more than simply running when in debugging mode, so it is obvious that performance can not be same. However if you read the statement carefully, it says that new release can run fully optimized code even if in debugging mode which was not possible earlier. Thus the new jvm is much more faster than previous one which could only run in interpreted mode which no optimization.