Reference : http://www.janeg.ca/scjp/threads/synchronization.html
- every instance of class Object and its subclass's has a lock
- primitive data type fields (Scalar fields) can only be locked via their enclosing class
- fields cannot be marked as synchronized however they can be declared volatile which orders the way they can be used or you can write synchronized accessor methods
- array objects can be synchronized BUT their elements cannot, nor can their elements be declared volatile
- Class instances are Objects and can be synchronized via static synchronized methods
Synchronized blocks
- allow you to execute synchronized code that locks an object without requiring you to invoke a synchronized method
synchronized( expr ) {
// 'expr' must evaluate to an Object
}
Synchronized methods
- declaring a method as synchronized ie synchronized void f() is equivalent to
void f() { synchronized(this) {
// body of method
}
}
- the synchronized keyword is NOT considered part of a method's signature. IT IS NOT AUTOMATICALLY INHERITED when subclasses override superclass methods
- methods in Interfaces CANNOT be declared synchronized
- constructors CANNOT be declared synchronized however they can contain synchronized blocks
- synchronized methods in subclasses use the same locks as their superclasses
- synchronization of an Inner Class is independent on it's outer class
- a non-static inner class method can lock it's containing class by using a synchronized block
synchronized(OuterClass.this) {
// body
}
Locking
- locking follows a built-in acquire-release protocol controlled by the synchronized keyword
- a lock is acquired on entry to a synchronized method or block and released on exit, even if the exit is the result of an exception
- you cannot forget to release a lock
- locks operate on a per thread basis, not on a per-invocation basis
- Java uses re-entrant locks ie a thread cannot lock on itself
class Reentrant {
public synchronized void a() {
b();
System.out.println("here I am, in a()");
}
public synchronized void b() {
System.out.println("here I am, in b()");
}
}
- in the above code, the synchronized method a(), when executed, obtains a lock on it's own object. It then calls synchronized method b() which also needs to acquire a lock on it's own object
- if Java did not allow a thread to reacquire it's own lock method b() would be unable to proceed until method a() completed and released the lock; and method a() would be unable to complete until method b() completed. Result: deadlock
- as Java does allow reentrant locks, the code compiles and runs without a problem
- the locking protocol is only followed for synchronized methods, it DOES NOT prevent unsynchronized methods from accessing the object
- once a thread releases a lock, another thread may acquire it BUT there is no guarantee as to WHICH thread will acquire the lock next
Class fields and methods
- locking an object does not automatically protect access to static fields
- protecting static fields requires a synchronized static block or method
- static synchronized statements obtain a lock on the Class vs an instance of the class
- a synchronized instance method can obtain a lock on the class
synchronized(ClassName.class) {
// body
}
- the static lock on a class is not related to any other class including it's superclasses
- a lock on a static method has no effect on any instances of that class (JPL pg 185)
- you cannot effectively protect static fields in a superclass by adding a new static synchronized method in a subclass; an explicit block synchronization is the preferred way
- nor should you use synchronized(getClass()); this locks the actual Class which might be different from the class in which the static fields are declared
