Home/ Questions/Q 6468689
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T05:54:47+00:00

By default, with Hotspot, a CTRL-Break thread dump will not list what threads are

  • 0

By default, with Hotspot, a CTRL-Break thread dump will not list what threads are holding java.lang.concurrent locks. And I understand that with these locks, Hotspot cannot have information about at which stack frame a lock was acquired. If you add the JVM option -XX:+PrintConcurrentLocks, then a CTRL-Break stack dump will list (after a thread’s stack trace) any concurrent locks held by that frame. For example:

"D-Java-5-Lock" prio=6 tid=0x00000000069a1800 nid=0x196c runnable [0x000000000770f000]
   java.lang.Thread.State: RUNNABLE
      at com.Tester.longDelay(Tester.java:41)
      at com.Tester$D.run(Tester.java:88)

   Locked ownable synchronizers:
      - <0x00000007d6030898> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

Without this option, it isn’t possible to figure out what thread is holding this lock in a post-mortem. Why is this option not the default? Is there some non-obvious performance or stability penalty? When I search to find discussion of this, nothing comes up.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I asked Oracle (my employer has a support contact) and the answer is basically that the option is safe to use and that many purely-diagnostic features are disabled by default and this is one of those options. IMO, if a diagnostic feature is safe and stable and doesn’t introduce a performance penalty, then it should be on by default. It appears that this is not the view at (then) Sun and (now) Oracle.

    • 0