Locking on Strings

Question

2 Questions:

1. str field is shared between two instance of A type [line 2]
2. What\'s implications according to following code ?

---

Answer 1

The field itself isn't shared between two instances. They are distinct fields. However, they start off with the same value, as string literals are interned.

That means when the synchronized block acquires the string's monitor in one thread, it will prevent the other thread from acquiring the same monitor. It's important to understand that the synchronized block is acquiring the lock for the monitor associated with the value of the field - it doesn't matter that there are two separate fields involved.

Moral: don't synchronize on strings, particularly literals. Literals are particularly bad, because in this case you could have another class with the same code as A, and that would also try to synchronize using the same monitor.

Answer 2

Locking on strings in this manner can be dangerous. According to Section 3.10.5 of the Java Language Specification:

Literal strings within different classes in different packages likewise represent references to the same String object.

What this means is that if another class contains the same string literal, it will refer to the same String object and could result in a deadlock.

It would be better to use one of the explicit locks from the java.util.concurrent.locks package or even a new Object().

Example:

private final ReentrantLock lock = new ReentrantLock();
String str = "hello";    

public void run(){
    lock.lock(); 
    try{
        System.out.println(str+" "+Thread.currentThread().getName());
        Thread.sleep(100);
        System.out.println(str+" "+Thread.currentThread().getName());
    }
    finally{
        lock.unlock();
    }

}