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.
Well, my guess is that it is unstable, or the JVM maintainers (Sun-now-Oracle) simply don't want to maintain it as a supported feature. You can tell this simply by the -XX: prefix:
Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice.
- from Java HotSpot VM Options
Also from that page, that option can be dynamically enabled or disabled via the JDK management interface, so you can enable it via an MXBean if you need.
Flags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, Figure 3 shows an example. The manageable flags can also be set through jinfo -flag.
Finally, the jstack Stack Trace tool can perform the same functionality at any time without requiring it enabled all the time.
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.
Because, only ReentrantLocks know which threads they are related. To get this information on Runtime realization of this method go over heap to find all locks and their threads.
来源：https://stackoverflow.com/questions/7071643/why-is-this-hotspot-jvm-option-not-the-default-xxprintconcurrentlocks