Why can't we acquire lock when it's private?

Question

Why does making the lock object private encapsulate the lock so that client code cannot acquire it ?

Object's Intrinsic Lock

   public class A{
        private final Set<Integer> set = new HashSet<Integer>();

        public synchronized void addInt(int i){
            set.add(i);
        }
   }

Private Lock

   public class B{
        private final Set<Integer> set = new HashSet<Integer>();

        public void addInt(int i){
             synchronized(set){
                  set.add(i);
             }
        }
   }

`this` is inherently unassignable, so it by default protects from bugs where you use a non-`final` monitor field and potentailly end up locking on two separate objects. PS [both of these use *intrinsic locks*](http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html) — obataku, Aug 19 '12 at 16:46
See more reasons [here](http://stackoverflow.com/a/442601/591495). — obataku, Aug 19 '12 at 16:48
possible duplicate of [Avoid synchronized(this) in Java?](http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java) — Matt Ball, Aug 19 '12 at 16:49
Now I feel this is duplicate of http://stackoverflow.com/questions/3369287/synchronized-block-lock-object-question — Amit Deshpande, Aug 19 '12 at 17:10

yshavit · Accepted Answer · 2012-08-19T17:19:12.903

3

Well, another class can't access set at all, because it's private. Of the many things everyone else can't do because they don't have access to that reference, synchronizing on it is one.

If a getter returns that reference directly (without wrapping or copying the object), someone else can synchronize on it, defeating the benefits of a lock on a private object.

edited Aug 19 '12 at 17:19

answered Aug 19 '12 at 17:08

yshavit

42,327
7
87
124

score 1 · Answer 2 · edited Jun 20 '20 at 09:12

In both of the examples you provided, an intrinsic monitor is used. The second example, however, uses the intrinsic lock of the set field. Take care when using this practice: if you publish a reference to set, code outside your class could synchronize on its monitor, which could lead to dead lock.

I think the distinction you're getting at is synchronized versus using the java.util.concurrent.Lock API. Most of what you get is added flexibility (from the Lock docs):

The use of synchronized methods or statements provides access to the implicit monitor lock associated with every object, but forces all lock acquisition and release to occur in a block-structured way: when multiple locks are acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in which they were acquired.

While the scoping mechanism for synchronized methods and statements makes it much easier to program with monitor locks, and helps avoid many common programming errors involving locks, there are occasions where you need to work with locks in a more flexible way. For example, some algorithms for traversing concurrently accessed data structures require the use of "hand-over-hand" or "chain locking": you acquire the lock of node A, then node B, then release A and acquire C, then release B and acquire D and so on. Implementations of the Lock interface enable the use of such techniques by allowing a lock to be acquired and released in different scopes, and allowing multiple locks to be acquired and released in any order.

There are also two method calls which give you more ways to acquire a lock with the Lock API:

lockInterruptibly: acquire the lock unless the thread is interrupted.
tryLock: acquire the lock only if it is free at the time of invocation (optional timeout).

The canonical reference for concurrency in Java is 'Java Concurrency in Practice'.

Sorry that i changed the question slightly due to some duplicate content, so the question that I have now is actually from 'Java Concurrency in Practice' that it says client cannot acquire the lock if the lock is private, why is that ? — peter, Aug 19 '12 at 17:09
*"if you publish a reference to set, code outside your class could synchronize on its monitor, which could lead to dead lock"*: If you synchronize on this, it could be the case too. — assylias, Aug 19 '12 at 17:30

score 0 · Answer 3 · answered Aug 19 '12 at 19:36

Why does making the lock object private encapsulate the lock so that client code cannot acquire it ?

To be honest I have no idea what is the meaning of this question.
The difference between your code snippets is the lock used. In the first case the whole method is synchronized (using the A's intrinsic lock) while in the second case you lock on the collection you are trying to modify. I.e. 2 threads can enter the method concurrently but 1 will block trying to get lock for the add.
This method has 2 advantages: 1) it defines the granularity of locking (for long methods where you would need the lock only for a short time, locking for the entire duration of the method call would degrade performance) and 2) by locking on the collection you make it thread safe.
Note that you could use any object as a lock: Object lock = new Object();
synchronized(lock){ //do something }

Why can't we acquire lock when it's private?

3 Answers3