56

I know the difference between synchronized method and synchronized block but I am not sure about the synchronized block part.

Assuming I have this code

class Test {
  private int x=0;
  private Object lockObject = new Object();

  public void incBlock() {
    synchronized(lockObject) {
      x++;
    }
    System.out.println("x="+x);
  }

  public void incThis() {  // same as synchronized method
    synchronized(this) {
      x++;
    }
    System.out.println("x="+x);
  }
}

In this case what is the difference between using lockObject and using this as the lock? It seems to be the same to me..

When you decide to use synchronized block, how do you decide which object to be the lock?

Gray
  • 115,027
  • 24
  • 293
  • 354
GantengX
  • 1,471
  • 2
  • 16
  • 28
  • 6
    I found the answer to my question in http://stackoverflow.com/questions/3047564/java-synchronized-method-lock-on-object-or-method If you look at the answer, it's very clear that if there are 2 threads (t1 and t2) where t1 calls x.addA() and t2 calls x.addB(). If both addA and addB use this as the lock, then x.addA() and x.addB() can't run concurrently. Whereas if if addA and addB uses different object for the lock, both method can run concurrently – GantengX Jul 30 '10 at 07:11
  • 2
    Just to check something: In the example above, when you use lockObject to effectively guard access to x is there not a situation where another thread could get in after the synchronised block but before the println and increase x again? I.e. do you really need the println within the synchronised block? – Component 10 Jul 30 '10 at 08:40
  • 1
    ah true, i should've put it in the synchronised block, but i've already answered my own question :D – GantengX Aug 04 '10 at 11:34
  • 1
    @GantengX Let me get this clear. Using a private object as a lock guarantees you that threads that use *the same instance* of your Test class will get synchronized, if they try to access the method at the same time. If there is more than one instance of the Test class, lock objects will be different. i.e. threads that that use separate instances will not get synchronized (unless more than one uses the same instance). Is this correct? – Preslav Rachev May 19 '15 at 10:07
  • 1
    @user1107412 yes, that's correct. The reason why using private object is preferable is that other object can't use the same lock (unlike using `this`) – GantengX May 19 '15 at 23:00

5 Answers5

73

Personally I almost never lock on "this". I usually lock on a privately held reference which I know that no other code is going to lock on. If you lock on "this" then any other code which knows about your object might choose to lock on it. While it's unlikely to happen, it certainly could do - and could cause deadlocks, or just excessive locking.

There's nothing particularly magical about what you lock on - you can think of it as a token, effectively. Anyone locking with the same token will be trying to acquire the same lock. Unless you want other code to be able to acquire the same lock, use a private variable. I'd also encourage you to make the variable final - I can't remember a situation where I've ever wanted to change a lock variable over the lifetime of an object.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • can you elaborate more? Say class `A` having instance of Class `B`. Now `B` has some member variable. When `A` calls any method of `B`, it gets lock on this/instance member...right? Means gets lock on instance of `B` itself or its member... can u just explain the difference? – Parth Jul 30 '10 at 07:08
  • 1
    @Paarth: Your comment isn't clear - do you mean *should* `B` lock on the private lock for every method? That depends on the purpose of the class itself. Most classes don't need to try to be thread-safe at all, to be honest. – Jon Skeet Jul 30 '10 at 07:24
  • yah, so i it needs to make sync method, it shuold use private member object instead of 'this' ... right? ok... – Parth Aug 04 '10 at 05:13
  • synchronised(new Object ) vs synchronised(this ) what is the actual difference between this two, when to use which one – Maheshwar Ligade Feb 10 '16 at 12:27
  • 1
    @MaheshwarLigade: You should *never* create a new object just for a single `synchronized` block like that - there'd be no other code that could synchronize against the same object. You'd normally create a final variable within the class, e.g. `private final Object lock = new Object();` and synchronize against *that* instead. That's better than synchronizing against `this` as you know that *only* your code has access to that monitor to synchronize on it. – Jon Skeet Feb 10 '16 at 12:35
14

I had this same question when I was reading Java Concurrency In Practice, and I thought I'd add some added perspective on the answers provided by Jon Skeet and spullara.

Here's some example code which will block even the "quick" setValue(int)/getValue() methods while the doStuff(ValueHolder) method executes.

public class ValueHolder {
    private int value = 0;

    public synchronized void setValue(int v) {
        // Or could use a sychronized(this) block...
        this.value = 0;
    }

    public synchronized int getValue() {
        return this.value;
    }
}

public class MaliciousClass {

    public void doStuff(ValueHolder holder) {
        synchronized(holder) {
            // Do something "expensive" so setter/getter calls are blocked
        }
    }
}

The downside of using this for synchronization is other classes can synchronize on a reference to your class (not via this, of course). Malicious or unintentional use of the synchronized keyword while locking on your object's reference can cause your class to behave poorly under concurrent usage, as an external class can effectively block your this-synchronized methods and there is nothing you can do (in your class) to prohibit this at runtime. To avoid this potential pitfall, you would synchronize on a private final Object or use the Lock interface in java.util.concurrent.locks.

For this simple example, you could alternately use an AtomicInteger rather than synchronizing the setter/getter.

Phil M
  • 6,633
  • 1
  • 23
  • 12
6

Item 67 of Effective Java Second Edition is Avoid excessive synchronization, thus I would synchronize on a private lock object.

Manuel Selva
  • 18,554
  • 22
  • 89
  • 134
  • 3
    It does not answer the question (use `synchronized` or `Locks`), no real explanation, broken link ([archived version](http://web.archive.org/web/20090904194857/http://java.sun.com/docs/books/effective/index.html)). Downvoted. – try-catch-finally Aug 12 '17 at 06:24
2

Every object in Java can act as a monitor. Choosing one is dependent on what granularity you want. Choosing 'this' has the advantage and disadvantage that other classes could also synchronize on the same monitor. My advice though is to avoid using the synchronize keyword directly and instead use constructs from the java.util.concurrency library which are higher level and have well defined semantics. This book has a lot of great advice in it from very notable experts:

Java Concurrency in Practice http://amzn.com/0321349601

Sam Pullara
  • 618
  • 4
  • 10
0

In this case it does not matter which object you choose for lock. But you must consistently use the same object for locking to achieve correct synchronization. Above code does not ensure proper synchronization as you once use the 'this' object as lock and next the 'lockObject' as lock.

Gopi
  • 10,073
  • 4
  • 31
  • 45
  • I understand that it's not a proper synchronization since it uses different lock for different method, I'm just trying to understand the difference between using 'this' and 'lockObject' for the lock – GantengX Jul 30 '10 at 07:06
  • oh.. sorry for misunderstanding your question. So for that, the answer would be same as what Jon Skeet has answered. – Gopi Jul 30 '10 at 07:09