In Java, how do I test if an object's monitor is locked using traditional low-level locking mechanisms?

Question

In Java, how do I test if an object's monitor is locked? In other words, given a object obj, does any thread own obj's monitor?

I do not care which thread owns the monitor. All I need to test is if ANY thread owns a given object's monitor. Since a thread other than the current thread could own the monitor, Thread.holdsLock( obj ) is not enough as it only checks the current thread.

I am trying to figure the simplest solution possible.

This is not a duplicate because:

1. I cannot use higher-level/newer concurrency/locking mechanisms. I cannot use Lock, etc. I must use low-level/old/traditional currency/locking mechanisms such as synchronized, wait(), etc.
2. I am not trying to find a time to execute code when has monitor has become unlocked. I am trying to execute code when a monitor is locked. In fact, to give a little bit of background, this part of a unit test where I am trying to start run two threads which both need to lock the same object.
3. I cannot call internal private JVM dependent methods such as sun.* .

As a result, in order to test for correct handling of concurrency. I need to

1. Create the two threads.
2. Start thread 1 .
3. As soon as thread 1 owns the monitor, suspend thread 1 .
4. Start thread 2 .
5. As soon as thread 2 is blocked by thread 1, suspend thread 2 .
6. Resume thread 1 .
7. Join thread 1 .
8. Run some assertions.
9. Resume thread 2 .
10. Join thread 2 .
11. Run some assertions.

What I am trying to figure out is the best way to do #3, primarily, determining when thread 1 owns the monitor.

Answer 1

If you really want to do this using thread suspension, you can have thread 1 set a thread safe flag when it has the monitor and observe the flag from your test thread.

However, I doubt that's the best way to put together your test. If you just want to test the business logic in your threads, you can run thread 1, join it, run your first set of assertions, then run thread 2, join it, and run your second set of assertions. Better yet, you could put the business logic in Runnables and test them in your test thread by invoking the run() method directly.

If there's an issue with thread synchronization that you are trying to get at, my experience is that using time delays is a better way to test those issues than interacting directly with the threads, as interacting directly with the threads may introduce or hide synchronization issues. For more on that, see my answer on the general question of testing threaded code here:

How should I unit test threaded code?

Answer 2

Your original question was how to check if any thread owns a lock. The ThreadMxBean should help you out. You can obtain an instance by calling

ManagementFactory.getThreadMXBean()

You should first check if you platform supports monitoring of object monitor usage by calling isObjectMonitorUsageSupported. If that is the case you can get information about all threads including lock info by calling

ManagementFactory.getThreadMXBean().dumpAllThreads(true,true)

This returns an array of ThreadInfo objects on which you can call the getLockedMonitors method which will give you hints on the locked objects, namely the result of calling System.identityHashCode on that object which should uniquely identify that object. Pretty clunky alltogether but at least a way to go.

Apart from the virtual answer to your question I don't think your approach is a sensible one. Your original goal is still not clear to me why I can't give you conrete advise. Maybe you should investigate best practices on testing multithreading?