Java: slow performance or hangups when starting debugger and stepping

Debugger performance can be affected by the following:

  • Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate. Remove method breakpoints and consider using the regular line breakpoints. To verity that you don't have any method breakpoints open .idea/workspace.xml file in the project root directory (or <project>.iws file if you are using the old project format) and look for any breakpoints inside the method_breakpoints node.
  • Watch method return values option is enabled in the Debugger Panel. Try disabling this option to improve the performance.
  • Enable alternative views for Collections classes and Enable toString()’ object view options enabled in Settings | Debugger | Data Views. If toString() methods take a long time to complete, disable this option. Note that custom toString() methods can also change the semantics of the application when running under debugger in case the code inside these methods changes the state of your application.
  • Memory tab in the debugger toolwindow. It is updated on every debugger stop, try to minimize it to improve stepping performance.

My debugger suddenly started to fail to start. I deleted all my breakpoints (~20) & that fixed it.


"If toString() methods take a long time to complete, disable this option". After doing this I was able to step through the code without experiencing slowness.


Removing the method breakpoint made my debugging faster.. Before that is was none responsive.


I must also chime in to say that removing the method breakpoint was the key for me.

It went from a deployment that took (no joke) about 30 minutes, to under 30 seconds.


All of these settings are correct locally and I still get freezes from 5 to 10 seconds on every debug run.

I've allocated huge amounts of memory in both gradle, intellij natively, and also set my local host manually in /etc/hosts and still nothing.


I'm experiencing the same problem running IntelliJ on my Mac.  Starting a java debugging session hangs IntelliJ 10+ seconds on every start.


Thank you Serge that fixed it for me.


git clone

java -jar ./bin/inetTester.jar

Find the hostname that's output from the .jar

sudo nano /etc/hosts and add these two entries <output-host-name>.local

::1 <output-host-name>.local


If you continue to have problems with a slowdown of intellij debugging even after applying the fix to /etc/hosts then run the inetTester again. My localhost name changed on me all of a sudden and the debugger started hanging predictably again.

Just run the inetTester again and add your new hostname to /etc/hosts with the mapping and it should fix it again.

Edited by jdavis413

The bizarre but effective solution offered by jdavis413 sure helped me not totally wanna shift back to Eclipse, which breezes through during the SAME debugging. The response time has MAYBE improved 50% which might be psychological, as I do wanna stick to IJ, but nevertheless, still slower than E.

Why does Eclipse not react so weirdly to entries in the hosts ?? Why is IJ so peculiar about it ?

Update -I had to restart browser/server/vm for it to have any effect.

 Update - I had some version of IJ when I got my CentOS VM, then it updated and crazy things started to happen. I then just wiped it out and reinstalled and things are hunky-dory now. I am even starting to get along with the new Find window:)

Edited by rojajet

Changing transport of debugger from socket to shared memory solved the issue for me


I made some research regarding Method Breakpoint slowness ( ).
To make the long story short, it seems that the root issue is that Method Breakpoints are implemented by using JDPA's Method Entry & Method Exit feature. This implementation requires the JVM to fire an event each time any thread enters any method and when any thread exits any method.

If this is the case, I would like to propose an improvement. When a user tries to set a breakpoint on a method's signature, the debugger can try to find the method and (behind the scenes) set a breakpoint at its first instruction. In practice, this means you can handle method breakpoints exactly like regular breakpoints.

Only breakpoints for method exit would require using the expensive Method Exit feature. 

From my understanding eclipse's developers improved Method Breakpoint implementation as described.

I would like to know how Method Breakpoints are implemented by intellij.

Edited by Gabi Beyo

Gabi, in IDEA this is called emulated method breakpoints. Implemented in 2017.1.


My debugger seemed to start hanging randomly after working well for almost a year. I'm on a Windows 7 machine with IDEA 2017.1.4.

I do not have any method breakpoints (I've removed ALL breakpoints except one to test with, which is not a method breakpoint), and I disabled the toString option mentioned above, yet the problem persists.  I've tried switching to Shared Memory instead of a socket, and that didn't help either.  Any other suggestions?

Edited by Atjaden

Please report at with the thread dumps ( and the debugger logs attached. See Specify the Java versions used to run IntelliJ IDEA and your code.

See if you can reproduce it with the current version available at

Does it happen with any project?


Ticket created:

It seems to happen with any project.

Unfortunately, I'm not able to test this issue on a newer version of IDEA due to security restrictions on my workstation. However, this problem was not happening at one time using this version of IDEA.




We have the same situation as Atjaden has.

Our application works in Run mode and hangs in Debug mode. Without break points. Idea 2017.3.2(Ultimate edition) under Linux.

Application is hanging on ( according to jstack):

"AWT-EventQueue-0" #25 prio=6 os_prio=0 tid=0x00007f1edcd26800 nid=0x7dc8 runnable [0x00007f1ea5c28000]

java.lang.Thread.State: RUNNABLE

at java.lang.Class.getDeclaredConstructors0(Native Method)

at java.lang.Class.privateGetDeclaredConstructors(

at java.lang.Class.getConstructor0(

at java.lang.Class.newInstance(

at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(








There is no one deadlock in this jtsack. It seems like it depends on count call of the method:<T>)

For example 10 times in works, but on 11 it hangs. And it has to be different classes.

I don't have permission to Atjaden's ticket. Have I to create new ticket?   


That sounds like a different problem than what I was having.  Mine hung only after stepping over a breakpoint.  It turned out to be a duplicate of  Perhaps restoring the debugger view will fix your issues as well, but if not, I would advise making a ticket so the JetBrains team can evaluate it more closely.


I am experiencing a similar problem (Ultimate 2017.3, MacOS High Sierra):

1. When paused at a breakpoint, and stepping (any stepping way: over, into, out), often my application hangs.

2. When paused at a breakpoint, many variables often show 'Collecting Data...'. They never complete the collection. Same if trying to evaluate an expression.


My problem was solved by adding parameter:



Webstorm debugger on Chrome sometimes works slowly with 3-4 delay between actions when connected to localhost, connecting to solves the problem.

This problem is intermittent, I still can't figure out under which conditions it would start but when it starts, it won't go away until you restart the workstation (Chrome or Webstorm restart doesn't work)



May be related to problems resolving localhost name. Are you on Mac OSX? Make sure that you have       localhost 

in /etc/hosts and that it's the only localhost mapping there


I had the same issue that drove me crazy. Finally fixed by changing the “project bytecode version” to 1.8 in Settings … Java compiler


Websphere 8.5 would hang/crash after stepping over a break point. Closing the memory tab fixed the issue. 


Happens on Windows + Webstom + Chrome debugger. Since connecting the client to instead of localhost no delays observed. Everything else including IntelliJ works fine on this workstation.


Please sign in to leave a comment.

Have more questions?

Submit a request