blocks|key|317372|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|317373|一些CPU密集型例程在通过调试器运行时会显著变慢。为什么会这样呢？|blockquote|317374|317375|317376|因为在启用调试时，JITter不会对代码进行过多优化(通常根本不会优化)。|317377|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|J|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|K|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]]|I|$]]

<blockquote>
 Some CPU intensive routines get dramatically slower when run through a debugger. Why is this?
</blockquote>

Because the JITter won't optimize code as much (often, not at all) when debugging is enabled.

blocks|key|317405|text|它还依赖于“断点样式”。例如，在变量上设置观察点或在接口级设置断点(调试器将在所有方法实现执行时停止)，通常会显着减慢处理时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|317406|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It also depends on the "breakpoints-style". E.g. having watchpoints on variables or putting breakpoints on interface level (debugger will stop on all method-implementations when they're executed) often dramatically slows down the process time.

blocks|key|3063948|text|调试时，除了运行应用程序外，还运行调试器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3063949|代码在调试模式下使用有关局部变量的元数据符号和其他源代码级信息进行编译。调试器读取以了解源代码的哪一行对应于当前指令。这个过程被称为符号调试。存储的符号增加了代码大小，解释它们增加了执行时间。|offset|length|style|BOLD|3063950|一些调试器实际上在运行时解释代码，这几乎总是一个主要的性能影响。|3063951|关于Java调试编译模式的更多信息，由javac和执行，在类文件：Java+Language+Compiler+Options中包含了调试信息。例如：-g生成所有调试信息，包括局部变量。|CODE|3063952|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javac.html#options^0|0|3|4|1U|4|0|0|J|5|23|2|P|7|X|U|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@$D|W|E|X|F|G]|$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|11|8|@$D|12|E|13|F|L]|$D|14|E|15|F|L]|$D|16|E|17|F|G]]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|M|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

When debugging, in addition to running your application, you are also running a debugger.

The code is compiled in debug mode with metadata symbols about local variables and other source-level information. The debugger reads to know which line of source code corresponds with the current instruction. The process is called symbolic debugging. The stored symbols increase code size and interpreting them increases execution time.

Some debuggers actually interpret the code on the fly, which is almost always a major performance hit.

More information about Java's debug compilation mode, which is performed by <code>javac</code> and includes debug information in class files: <a href="http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javac.html#options" rel="nofollow noreferrer">Java Language Compiler Options</a>.
For example: <code>-g</code> generates all debugging information, including local variables.

blocks|key|3277041|text|您确实需要考虑到另一个程序--调试器--被挂接到您的程序中，并且正在监视它是否有异常之类的东西。它还监视当前行，以便对断点或用户请求的中断(如暂停请求或监视条件)做出反应。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3277042|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You do need to consider that another program -- the debugger -- is hooked into your program and is watching it for things like exceptions. It's also monitoring the current line in order to react to breakpoints or user requested interruptions (like a pause request or watch condition).

blocks|key|320223|text|顶级提示:在IDEA中，您可以使用ALT%2BF9运行到光标所在的位置，而不是设置额外的断点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|320224|据我所知，如果你在遍历有大量数据可从堆栈访问的代码，那么在我看来，调试会变得非常慢。不要忘记，IDEA收集这些数据(当前在词法范围内的任何数据)，并将其作为对象树呈现给您，以供您浏览，无论您是否正在“观看”，并且在后续的每个步骤中都会在中执行此操作(也许它每次都会重新创建树？)。|offset|length|style|BOLD|320225|例如，当有一个大型集合作为“当前”对象的实例变量时，这一点尤其明显。|320226|entityMap^0|0|3A|M|0|0|Y|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@$D|Q|E|R|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

Top Tip: in IDEA you can use ALT+F9 to run to where you have the cursor placed rather than set an extra breakpoint.

I have found anecdotally that debugging becomes very slow in IDEA if you are walking through code where there is a lot of data accessible from the stack. Don't forget, IDEA collects this data (anything currently in the lexical scope) and presents it up to you as a tree of objects to browse whether you are "watching" or not and does this at every subsequent step (maybe it re-creates the tree each time?).

This is especially apparent when, for example, there is a large collection as an instance variable of the "current" object.

blocks|key|317478|text|调试由JIT生成的优化代码将非常困难，因为在一系列本机指令和一行Java代码之间没有直接关系，就像一系列Java字节码和一行Java代码之间没有关系一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|317479|因此，进入调试器中的函数会强制JVM取消对您正在单步执行的方法的优化。Hotspot根本不生成本机代码，只解释方法的字节码。|317480|在JDK1.4.1之前，在启用调试的情况下启动会强制JVM只使用解释器：http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_3.html#full|offset|length|317481|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_3.html#full^0|0|0|10|32|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Debugging the optimized code produced by the JIT would be very hard, because there isn't a direct relationship between a range of native instructions and a line of Java code like there is a relationship between a range of Java bytecode and a line of Java code.

So breaking into a function in the debugger forces the JVM to deoptimize the method you are stepping through. Hotspot doesn't generate native code at all and just interprets the bytecode of the method.

Prior to JDK 1.4.1 starting with debugging enabled forced the JVM to only use the interpreter: <a href="http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_3.html#full" rel="nofollow noreferrer">http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_3.html#full</a>

blocks|key|315450|text|如果使用Java+5，则调试参数为：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315451|-agentlib:jdwp=transport=dt_socket、server=y、suspend=n、address=|315452|以及Java+5之前的版本|315453|-Xdebug+-Xrunjdwp:transport=dt_socket，主板，address=5005，server=y，主板，suspend=n|315454|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

If you use Java 5, the parameter for debugging is :

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=

and before Java 5 

-Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n

Some CPU intensive routines get dramatically slower when run through a debugger. Why is this? 

Currently I'm just using IntelliJ to step through code running in JBoss. When I start JBoss, I use these options: 

<pre><code>set JAVA_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=256m -Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n %JAVA_OPTS%
</code></pre>

Is there a way to speed up the execution? Or to speed up certain method executions that I don't need to step through?

<hr>

Update: Seems if I don't step over/into the CPU intensive routines (ie: Just run til a breakpoint set right after the routine), then the execution time is as if not in a debugger.

Why does Java code slow down in debugger?

调试器

解释器

Java

一些CPU密集型例程在通过调试器运行时会显著变慢。为什么会这样呢？目前，我只是使用IntelliJ单步执行在JBoss中运行的代码。当我启动JBoss时，我使用以下选项：set JAVA_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=256m -Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,s

问为什么Java代码在调试器中变慢了？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java代码在调试器中变慢了？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java代码在调试器中变慢了？
EN