Java Synchronized Block for .class

Question

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 ??
}

Amyloid

Related: #438120 – Adalie

Answer 1

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.

Loquat

"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". – Ledaledah

Corrected. I intended to say that. – Loquat

what is the class instance vs the instance? – Bangkok

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? – Binder

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 – Dentiform

Your use of the term "class instance" is confusing and does not conform to its generally accepted meaning. Perhaps you should use the term class Type instance or just class type. – Jenisejenkel

Answer 2

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
}

Armour

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. – Koweit

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! – Manta

public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { instance = new Singleton(); } } return instance; } – Manta

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. – Armour

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. – Jeconiah

@Jeconiah In that case, it's probably better to synchronize on a separate lock object, not on some Class instance. – Armour

Answer 3

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!

Lungan

yes, MyClass.class could be any static variable and have the same effect. – Farrel

Answer 4

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/

Ciliary

this is not true, yes it will block all instances that are from same classloader! – Dentiform