119

What does this java code mean? Will it gain lock on all objects of MyClass?

synchronized(MyClass.class) {
   //is all objects of MyClass are thread-safe now ??
}

And how the above code differs from this one:

synchronized(this) {
   //is all objects of MyClass are thread-safe now ??
}
Andrew Tobilko
  • 48,120
  • 14
  • 91
  • 142
  • Related: http://stackoverflow.com/questions/437620/java-synchronized-methods-lock-on-object-or-class – finnw Feb 05 '10 at 21:32

4 Answers4

168

The snippet synchronized(X.class) uses the class instance as a monitor. As there is only one class instance (the object representing the class metadata at runtime) one thread can be in this block.

With synchronized(this) the block is guarded by the instance. For every instance only one thread may enter the block.

synchronized(X.class) is used to make sure that there is exactly one Thread in the block. synchronized(this) ensures that there is exactly one thread per instance. If this makes the actual code in the block thread-safe depends on the implementation. If mutate only state of the instance synchronized(this) is enough.

Thomas Jung
  • 32,428
  • 9
  • 84
  • 114
  • 7
    "as many threads may enter the block as there are instance" implies that the second form acts as a semaphore which is not true. You should say something like: "synchronised(this) ensures that only one thread can enter the block for a given instance of the class". – liwp Jan 13 '10 at 12:08
  • Corrected. I intended to say that. – Thomas Jung Jan 13 '10 at 12:23
  • 2
    what is the class instance vs the instance? – Weishi Z Jun 19 '16 at 09:09
  • So, if you have a static method and we don't want to synchronize all of its body, then we synchronized(this) is not good, instead synchronized(Foo.class) is appropriate. Is that right? – krupal.agile May 15 '19 at 13:37
  • `synchronized(X.class) is used to make sure that there is exactly one Thread in the block.` this is false, it depends on how many classloaders you have – Enerccio Nov 26 '21 at 13:04
95

To add to the other answers:

static void myMethod() {
  synchronized(MyClass.class) {
    //code
  }
}

is equivalent to

static synchronized void myMethod() {
  //code
}

and

void myMethod() {
  synchronized(this) {
    //code
  }
}

is equivalent to

synchronized void myMethod() {
  //code
}
Jorn
  • 20,612
  • 18
  • 79
  • 126
  • 13
    It took me a second reading to catch that the first two examples have the keyword "static". Just pointing that out to others who may have seen this and missed it. Without the static keyword the first two examples would not be the same. – kurtzbot Jul 24 '14 at 16:23
  • 3
    Those examples are NOT equivalent! The synchronized methods are "synchronized" as a hole when a thread tries to call the methods. The blocks on the other hand, can have code above and below them, that can get executed from multiple threads. They only synchronize within the block! That is not the same! – JacksOnF1re Mar 15 '18 at 15:31
  • public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { instance = new Singleton(); } } return instance; } – JacksOnF1re Mar 15 '18 at 15:32
  • 3
    The whole point is that there *is* no code outside the `synchronized` blocks. That makes them equivalent. If you change one example, they are indeed no longer the same. – Jorn Mar 15 '18 at 21:22
  • Just adding that synchronized(MyClass.class) can also be used from other classes, not just from withing MyClass. I have a legacy code where several classes use a method from one class (let's say Foo.saveStuff). I need to make sure that only one thread uses saveStuff at a time. Due to bad DB transaction design I can't just make safeStuff synchronized so I have to use synchronized(Foo.class) in all the other methods. – tomorrow Aug 09 '21 at 11:04
  • @tomorrow In that case, it's probably better to synchronize on a separate lock object, not on some Class instance. – Jorn Aug 09 '21 at 13:49
24

No, the first will get a lock on the class definition of MyClass, not all instances of it. However, if used in an instance, this will effectively block all other instances, since they share a single class definition.

The second will get a lock on the current instance only.

As to whether this makes your objects thread safe, that is a far more complex question - we'd need to see your code!

David M
  • 71,481
  • 13
  • 158
  • 186
1

Yes it will (on any synchronized block/function).

I was wondering about this question for couple days for myself (actually in kotlin). I finally found good explanation and want to share it:

Class level lock prevents multiple threads to enter in synchronized block in any of all available instances of the class on runtime. This means if in runtime there are 100 instances of DemoClass, then only one thread will be able to execute demoMethod() in any one of instance at a time, and all other instances will be locked for other threads.

Class level locking should always be done to make static data thread safe. As we know that static keyword associate data of methods to class level, so use locking at static fields or methods to make it on class level.

Plus to notice why .class. It is just because .class is equivalent to any static variable of class similar to:

private final static Object lock = new Object();

where lock variable name is class and type is Class<T>

Read more: https://howtodoinjava.com/java/multi-threading/object-vs-class-level-locking/

vitalii
  • 443
  • 6
  • 10