What is the purpose of specifying the object to lock on?
Often, it is easier to synchronize on this
or on the Class
instance (for static methods). But, there are cases where you will need to synchronize on a specific object instead of the implicit lock (this
). Such cases include:
- You want to synchronize access to primitives without using
this
. You can only synchronize on Object
s as each Object
is associated with an implicit monitor in Java. Primitives do not have such implicit monitors, and therefore you need to use a lock object. Using the wrapper classes are a poor and incorrect choice, especially if you end up modifying the lock object in the guarded block.
- You want to synchronize on an object that actually protects the critical section, when synchronizing on
this
would not offer a guarantee of thread safety. For instance, if you are synchronizing access to a ArrayList
instance shared across instances of class A
, then synchronizing on an instance of A
is useless. A thread might create a new instance of A
and gain access to the list, while another thread is modifying it. If you use a different lock that all threads must contend for then you can protect the list; this lock could be the one associated with A.class
, but it could be any object that will offer the same guarantees.
- You want to perform lock splitting to ensure that different guarded blocks are protected by different locks instead of the same lock. In other words, if it is thread-safe to allow different threads to acquire different locks to access different critical sections, then you can have a different lock for every critical section.
The following is an example of split lock usage:
private Object method1Lock = new Object();
private Object method2Lock = new Object();
public void method1(){
synchronized(method1Lock){
....
}
}
public void method2(){
synchronized(method2Lock){
....
}
}
You would use split locks when you can ensure that the concurrent execution of method1
and method2
do not violate the class invariants. This way, you can improve performance across threads that need access to the same object, but will be invoking different methods.
On your other question,
For example, in the second example, will threads still be able to execute the code inside the synchronized block because the lock is not related to the 'this' instance?
In the second example, any thread entering the guarded region must acquire the lock associated with aStringBufferObject
. If a different thread is holding that lock, then the current thread will not proceed further. When you specify this
, then the thread must acquire the lock associated with the current object. In both cases, a thread must acquire a lock; the examples are only different in the object that is being used as a lock.
synchronized(this)
because it also synchronizes withsynchronized
methods and you might get deadlocks. You might get deadlocks too if someone uses the object as a lock somewhere else in the code. I remember reading a comment by one the Java creator saying that they should not have allowed locking on objects, but only the use of dedicated locks (i.e.java.util.concurrent.locks
). – Flinch