Java synchronized method lock on object, or method?
If I have 2 synchronized methods in the same class, but each accessing different variables, can 2 threads access those 2 methods at the same time? Does the lock occur on the object, or does it get as specific as the variables inside the synchronized method? Example:
class X < private int a; private int b; public synchronized void addA()< a++; >public synchronized void addB() < b++; >> Can 2 threads access the same instance of class X performing x.addA( ) and x.addB() at the same time?
11 Answers 11
If you declare the method as synchronized (as you’re doing by typing public synchronized void addA() ) you synchronize on the whole object, so two thread accessing a different variable from this same object would block each other anyway.
If you want to synchronize only on one variable at a time, so two threads won’t block each other while accessing different variables, you have synchronize on them separately in synchronized () blocks. If a and b were object references you would use:
public void addA() < synchronized( a ) < a++; >> public void addB() < synchronized( b ) < b++; >> But since they’re primitives you can’t do this.
I would suggest you to use AtomicInteger instead:
import java.util.concurrent.atomic.AtomicInteger; class X < AtomicInteger a; AtomicInteger b; public void addA()< a.incrementAndGet(); >public void addB() < b.incrementAndGet(); >> If you synchonize on the method you lock the whole object, so two thread accessing a different variable from this same object would block each other anyway. That’s a bit misleading. Synchronizing on the method is functionally equivalent to having a synchronized (this) block around the body of the method. The object «this» doesn’t become locked, rather the object «this» is used as the mutex and the body is prevented from executing concurrently with other code sections also synchronized on «this.» It has no effect on other fields/methods of «this» that aren’t synchronized.
Yes, it is truly misleading. For real example — Look at this — stackoverflow.com/questions/14447095/… — Summary : Locking is only at synchronized method level and object’s instance variables can be accessed by other thread
The first example is fundamentally broken. If a and b were objects, e.g. Integer s, you were synchronizing on instances you are replacing with different objects when applying the ++ operator.
Maybe this anwser should be updated with the explained in this other one about synchronizing on the object itself: stackoverflow.com/a/10324280/1099452
Synchronized on the method declaration is syntactical sugar for this:
On a static method it is syntactical sugar for this:
I think if the Java designers knew then what is understood now about synchronization, they would not have added the syntactical sugar, as it more often than not leads to bad implementations of concurrency.
Not true. synchronized method generates different bytecode than synchronized(object). While functionality equivalent, it is more than just syntactic sugar.
I don’t think that «syntactical sugar» is strictly defined as byte-code equivalent. The point is it is functionally equivalent.
If the Java designers had known what was already known about monitors they would have/should have done it differently, instead of basically emulating the innards of Unix. Per Brinch Hansen said ‘clearly I have laboured in vain’ when he saw the Java concurrency primitives.
This is true. The example given by OP would appear to lock each method but in fact they all lock on the same object. Very deceptive syntax. After using Java for 10+ years I didn’t know this. So I would avoid synchronized methods for this reason. I always thought that an invisible object was created for each method that was defined with synchronized.
First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
From «The Java™ Tutorials» on synchronized blocks:
Synchronized statements are also useful for improving concurrency with fine-grained synchronization. Suppose, for example, class MsLunch has two instance fields, c1 and c2, that are never used together. All updates of these fields must be synchronized, but there’s no reason to prevent an update of c1 from being interleaved with an update of c2 — and doing so reduces concurrency by creating unnecessary blocking. Instead of using synchronized methods or otherwise using the lock associated with this, we create two objects solely to provide locks.
Suppose you have 2 non-interleaving variables. So you want to access to each one from a different threads at the same time. You need to define the lock not on the object class itself, but on the class Object like below (example from the second Oracle link):
public class MsLunch < private long c1 = 0; private long c2 = 0; private Object lock1 = new Object(); private Object lock2 = new Object(); public void inc1() < synchronized(lock1) < c1++; >> public void inc2() < synchronized(lock2) < c2++; >> > Intrinsic Locks and Synchronization
Synchronization is built around an internal entity known as the intrinsic lock or monitor lock. (The API specification often refers to this entity simply as a «monitor.») Intrinsic locks play a role in both aspects of synchronization: enforcing exclusive access to an object’s state and establishing happens-before relationships that are essential to visibility.
Every object has an intrinsic lock associated with it. By convention, a thread that needs exclusive and consistent access to an object’s fields has to acquire the object’s intrinsic lock before accessing them, and then release the intrinsic lock when it’s done with them. A thread is said to own the intrinsic lock between the time it has acquired the lock and released the lock. As long as a thread owns an intrinsic lock, no other thread can acquire the same lock. The other thread will block when it attempts to acquire the lock.
When a thread releases an intrinsic lock, a happens-before relationship is established between that action and any subsequent acquisition of the same lock.
Locks In Synchronized Methods
When a thread invokes a synchronized method, it automatically acquires the intrinsic lock for that method’s object and releases it when the method returns. The lock release occurs even if the return was caused by an uncaught exception.
You might wonder what happens when a static synchronized method is invoked, since a static method is associated with a class, not an object. In this case, the thread acquires the intrinsic lock for the Class object associated with the class. Thus access to class’s static fields is controlled by a lock that’s distinct from the lock for any instance of the class.
Synchronized Statements
Another way to create synchronized code is with synchronized statements. Unlike synchronized methods, synchronized statements must specify the object that provides the intrinsic lock:
public void addName(String name) < synchronized(this) < lastName = name; nameCount++; >nameList.add(name); >
In this example, the addName method needs to synchronize changes to lastName and nameCount , but also needs to avoid synchronizing invocations of other objects’ methods. (Invoking other objects’ methods from synchronized code can create problems that are described in the section on Liveness.) Without synchronized statements, there would have to be a separate, unsynchronized method for the sole purpose of invoking nameList.add .
Synchronized statements are also useful for improving concurrency with fine-grained synchronization. Suppose, for example, class MsLunch has two instance fields, c1 and c2 , that are never used together. All updates of these fields must be synchronized, but there’s no reason to prevent an update of c1 from being interleaved with an update of c2 and doing so reduces concurrency by creating unnecessary blocking. Instead of using synchronized methods or otherwise using the lock associated with this , we create two objects solely to provide locks.
public class MsLunch < private long c1 = 0; private long c2 = 0; private Object lock1 = new Object(); private Object lock2 = new Object(); public void inc1() < synchronized(lock1) < c1++; >> public void inc2() < synchronized(lock2) < c2++; >> >
Use this idiom with extreme care. You must be absolutely sure that it really is safe to interleave access of the affected fields.
Reentrant Synchronization
Recall that a thread cannot acquire a lock owned by another thread. But a thread can acquire a lock that it already owns. Allowing a thread to acquire the same lock more than once enables reentrant synchronization. This describes a situation where synchronized code, directly or indirectly, invokes a method that also contains synchronized code, and both sets of code use the same lock. Without reentrant synchronization, synchronized code would have to take many additional precautions to avoid having a thread cause itself to block.
Synchronized Methods
The Java programming language provides two basic synchronization idioms: synchronized methods and synchronized statements. The more complex of the two, synchronized statements, are described in the next section. This section is about synchronized methods.
To make a method synchronized, simply add the synchronized keyword to its declaration:
public class SynchronizedCounter < private int c = 0; public synchronized void increment() < c++; >public synchronized void decrement() < c--; >public synchronized int value() < return c; >>
If count is an instance of SynchronizedCounter , then making these methods synchronized has two effects:
- First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
- Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.
Note that constructors cannot be synchronized using the synchronized keyword with a constructor is a syntax error. Synchronizing constructors doesn’t make sense, because only the thread that creates an object should have access to it while it is being constructed.
Warning: When constructing an object that will be shared between threads, be very careful that a reference to the object does not «leak» prematurely. For example, suppose you want to maintain a List called instances containing every instance of class. You might be tempted to add the following line to your constructor:
But then other threads can use instances to access the object before construction of the object is complete.
Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object’s variables are done through synchronized methods. (An important exception: final fields, which cannot be modified after the object is constructed, can be safely read through non-synchronized methods, once the object is constructed) This strategy is effective, but can present problems with liveness, as we’ll see later in this lesson.
Java synchronize on object
- Introduction to Java
- The complete History of Java Programming Language
- C++ vs Java vs Python
- How to Download and Install Java for 64 bit machine?
- Setting up the environment in Java
- How to Download and Install Eclipse on Windows?
- JDK in Java
- How JVM Works – JVM Architecture?
- Differences between JDK, JRE and JVM
- Just In Time Compiler
- Difference between JIT and JVM in Java
- Difference between Byte Code and Machine Code
- How is Java platform independent?
- Decision Making in Java (if, if-else, switch, break, continue, jump)
- Java if statement with Examples
- Java if-else
- Java if-else-if ladder with Examples
- Loops in Java
- For Loop in Java
- Java while loop with Examples
- Java do-while loop with Examples
- For-each loop in Java
- Continue Statement in Java
- Break statement in Java
- Usage of Break keyword in Java
- return keyword in Java
- Object Oriented Programming (OOPs) Concept in Java
- Why Java is not a purely Object-Oriented Language?
- Classes and Objects in Java
- Naming Conventions in Java
- Java Methods
- Access Modifiers in Java
- Java Constructors
- Four Main Object Oriented Programming Concepts of Java
- Inheritance in Java
- Abstraction in Java
- Encapsulation in Java
- Polymorphism in Java
- Interfaces in Java
- ‘this’ reference in Java