Scope of synchronization on .class objects in the JVM

Question

Let's say I've got the following code:

synchronize (Test.class) {
   ...
}

Does this mean that the Test.class objects is locked for every other program running in the same virtual machine? Or does this lock only affect this one program in the JVM?
If it affects every program: When Test.class is in a dependency included by two programs via different but content wise identical JARs would the lock still affect both programs?

Uhm, a JVM is one process, so what do you mean with your first question? — fge, Feb 22 '15 at 15:07
@fge I suppose the question might apply to multiple web apps for example. — Boris the Spider, Feb 22 '15 at 15:09
you should also consider the `ClassLoader` that loads that class. If two webapps running in a single JVM synchronize on `Test.class`, they both have different instances of `Test.class` as the web apps are loaded by different class loaders. — Arkantos, Feb 22 '15 at 15:23
@Arkantos that really depends, I don't think generalisations are very helpful here. Often webapps will have the same instance of a `class` - it depends on where the `class` comes from... — Boris the Spider, Feb 22 '15 at 15:28
@BoristheSpider.. I don't get your point. Each web-app has a different class loader in a container (say tomcat), so even though `Test.class` is in the shared libs, when it's actually loaded, they both create an instance of `Test.class` unique to that class loader and that is used as lock. Am I missing something here ? — Arkantos, Feb 22 '15 at 15:33
@Arkantos If the `class` is part of the container's classes - that it loads in its parent classloader, the parent of all web app classloaders, then there will only be a single instance of the `class`. — Boris the Spider, Feb 22 '15 at 15:34
@BoristheSpider.. yup that's a possibility. Thanks for pointing that :) — Arkantos, Feb 22 '15 at 15:37
@BoristheSpider.. yes i understand that if a class is loaded by parent class loader, then the sub class loader won't load it again, but we don't know if that's the case of OP, that's why I said that — Arkantos, Feb 22 '15 at 15:41
@BoristheSpider saying parent class loader loads all classes is incorrect. Though each web app class loader has same parent class or resource loading is not delegated to parent class loader like normal java applications. — Aniket Thakur, Feb 22 '15 at 16:11
@AniketThakur it _is_, for example - [here's the Tomcat documentation](http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html). — Boris the Spider, Feb 22 '15 at 16:12

score 2 · Accepted Answer · answered Feb 25 '15 at 09:09

When you have multiple ClassLoaders, each one can have it's own instance of a class (or share an instance of a class) e.g. String.class will be shared, but MyType.class might be different in each "Application" assuming each application has it's own class loader.

In terms of locking, there not nothing special about the Class object except it is used implicitly in static synchronised methods.

e.g.

class MyType {
    static synchronized void method() { }
}

is much the same as

class MyType {
    static void method() { 
        synchronized(MyType.class) {
        }
    }
}

It performs the same function, though the byte code is not identical.

score -1 · Answer 2 · answered Feb 22 '15 at 16:31

Your "programs" are simply various ClassLoader.load(programClass).main(args) that you run multiple times. Certainly they share one classloader, one machine and are effectively different parts of the same program, one OS process. Just calling various classes programs changes nothing. They are still visible to each other. If one can execute methods of another, they can block each other.

Aniket Thakur · Answer 3 · 2015-02-25T12:15:41.227

Java is an OO language which means you have Objects and they interact with each other to form a complete program. Each Object is associated with a monitor. Synchronization is essentially done over the objects which actually get a lock on the objects monitor.

Now coming to your question. When you say

synchronize (Test.class) {
   ...
}

lock is obtained over the Test.class object. Also for a fully qualified class name JVM will make sure it is loaded only once per class loader (unless it is GCed). So you will always have only one instance of Test.class per JVM instance (Considering class loading is done by same class loaded). By JVM instance I mean a Java process which will have it's own PID. If one thread have lock over Test.class no other thread can get this lock unless it is released by the holding thread (Same thread can get the lock again - Locks in Java are Reentrant nature).

If you start new java process -> new JVM instance -> new instance of Test.class is loaded by class loader -> It's lock can be obtained and is not dependent on any other JVM instance running.

Note : If Class objects are separate ( same class loaded by different class loaders for instance - like what happens in case of web apps ) then you can certainly get separate lock on each. You will not be able to cast an instance of one class to the other.

This is not true - _So you will always have only one instance of `Test.class`_. Not if you have any custom `ClassLoader` behaviour, and certainly not in a web application. — Boris the Spider, Feb 22 '15 at 15:29
@BoristheSpider Yes I meant one per class loader. As far as web apps are considered classes in each web app (`/WEB-INF/classes` and `/WEB-INF/lib/*.jar`) are loader by different class loaders and will behave like different classes altogether including locking mechanism. — Aniket Thakur, Feb 22 '15 at 16:13
So correct your answer, or keep collecting downvotes. At present it is entirely incorrect. — user207421, Feb 25 '15 at 09:25

Scope of synchronization on .class objects in the JVM

3 Answers3