What's the benefit of creating a "Lock" class (which extends Object and does nothing)?

Question

Hi all whenever I use the synchronized statement, I often use this pattern:

private static Object lock = new Object();

public void F(){
    //..
    synchronized (lock){
        //..
    }
    //..
}

However, in the source of java.lang.Reference, I see that they employ this pattern instead:

static private class Lock { };
private static Lock lock = new Lock();

public void run() {
//..
synchronized(lock){
    //..
}
//..
}

I was wondering what's the benefit of declaring a new class Lock (which basically extends Object and do nothing else) ?

Or rather, why didn't they simply use private static Lock lock = new Object(); ?

having a non `final` object to synchronize on is very bad practice as it doesn't guarantee that every client thread is acquiring the same lock. — , Dec 05 '11 at 16:57

Chris Dennett · Accepted Answer · 2011-12-05T17:04:07.597

The following code:

synchronized(lock){
}

doesn't actually use the Lock mechanics, you're just using the built-in synchronisation features on an Object. In this case, you might as well use a plain old Object. A benefit of a lock object that extends Object is so that it shows up in debugging tools with the class name rather than just a plain Object, which is more helpful when hunting down deadlocks.

See here for the Lock API.

The benefit of Lock is that you get more features, such as being able to 'try' locking, then continuing to execute code if that fails. Also, it has different properties than a synchronized block, because it's not reentrant (a thread can't hold multiple locks on the same lock, then release them). If you wanted something that was like that, you'd use ReentrantLock.

You also have cooler locks such as ReentrantReadWriteLock, which support multiple readers, but as soon as a writer locks it, no readers are permitted. There's a big lock ecosystem in there for different types of application.

Yes that's what I was talking about, why not simply use a plain old `Object` ? Instead of creating a class (that does nothing) and then creating an instance of that class which does nothing.. it seems very roundabout way of doing things. What's the difference between that and simply doing `new Object()` ? — Pacerier, Dec 05 '11 at 17:20

score 4 · Answer 2 · answered Dec 05 '11 at 16:51

4

I was wondering what's the benefit of declaring a new class Lock (which basically extends Object and do nothing else) ?

Readability. I believe that creating an instance of Object is at least weird, so having a separate, well named class for that purpose seems like a good idea.

BTW field containing a lock should always be final, otherwise you are asking for trouble.

answered Dec 05 '11 at 16:51

Tomasz Nurkiewicz

334,321
69
703
674

I'd think they're doing it more because they need the Conditionals and Co elsewhere. While I agree that it's probably more intuitive having a plain object called `lock` is rather idiomatic in Java so no problem in practice – Voo Dec 05 '11 at 16:55
I don't know why they didn't put in the `final` keyword. – Pacerier Dec 05 '11 at 16:56
@Voo what do you mean by a Co ? – Pacerier Dec 05 '11 at 16:56
@Voo: Read the code in question carefully. They are not using [`java.util.concurrent.Lock`](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Lock.html) object, they are creating private `Lock` object that extends `java.lang.Object` and does nothing. – Tomasz Nurkiewicz Dec 05 '11 at 16:58
And please explain the downvote, whoever it was :-). If I am mistaken, please correct me! – Tomasz Nurkiewicz Dec 05 '11 at 16:59
@Tomasz Wasn't me that was downvoting. And you're right, I thought they were just using the existing Lock class.. but great example by me! I think doing this leads to more confusion than the simple solution. I expect a class named `Lock` in Java to be the same as `j.u.c.Lock`. – Voo Dec 05 '11 at 18:01

score 1 · Answer 3 · edited May 23 '17 at 12:09

The name of the lock object's class appears in thread dumps. This makes it easier to interpret such dumps.

For instance, here is an example using Reference.Lock. You can see immediate what sort of lock it is and not confuse it with, say, a lock in ReferenceQueue. This was more important in earlier versions of the Sun JRE where the object identity hash wasn't displayed.

"Reference Handler" daemon prio=10 tid=0x000000000068f400 nid=0xbf5 in Object.wait() [0x000000004055d000..0x000000004055dca0]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00007f651aa10338> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
    - locked <0x00007f651aa10338> (a java.lang.ref.Reference$Lock)

As for

private static Lock lock = new Object();

that doesn't compile (and should be using final!).

What's the benefit of creating a "Lock" class (which extends Object and does nothing)?

3 Answers3