Question

While reading about synchronization, I came across “monitor pattern” to encapsulate mutable states.

The following is the sample code

   public class MonitorLock {
      private final Object myLock = new Object();
      Widget widget;
      void someMethod() {
        synchronized(myLock) {
         // Access or modify the state of widget
        }
    }

}

Is it better in any way to have a private lock instead of the intrinsic lock?

Answer 1

Yes – it means you can see all the code which could possibly acquire that lock (leaving aside the possibility of reflection).

If you lock on this (which is what I assume you’re referring to by “the intrinsic lock”) then other code can do:

MonitorLock foo = new MonitorLock();
synchronized(foo) {
    // Do some stuff
}

This code may be a long way away from MonitorLock itself, and may call other methods which in turn take out monitors. It’s easy to get into deadlock territory here, because you can’t easily see what’s going to acquire which locks.

With a “private” lock, you can easily see every piece of code which acquires that lock, because it’s all within MonitorLock. It’s therefore easier to reason about that lock.