What are class level, object level, explicit and intrinsic locking?

Question

I have been going through Java multi-threading concepts. The more I go through them, the more confused I become.

Right now I am not understanding the differences between class level, object level, explicit and intrinsic locking in Java. Can someone please let me know which is what? Also, if I can get some examples to understand, that will be very helpful for me.

Answer 1

Explicit vs Intrinsic

When you use synchronized on an object or indirectly as part of a method signature you are creating an intrinsic lock. You rely upon the in-built lock associated with all objects and classes.

An explicit lock is provided in Java 5+ in the package java.util.concurrent.locks. The most commonly used class is probably ReentrantLock. These provide alternatives to using the intrinsic locks and offer features that are not possible with intrinsic locks.

Class Level vs Object Level

This distinction applies to intrinsic locks only. If you have a synchronized static method, the intrinsic lock used will be associated with the class object itself. If you synchronize on an object instance (or have a synchronized instance method) it will be an object-level lock.

Further Reading

Brian Goetz's Java Concurrency in Practice is an excellent book for understanding the nightmarishly confusing world of multi-threaded programming in Java.

Answer 2

When you use "Synchronized" keyword, it uses intrinsic locks or monitors. Every object in Java has an intrinsic lock associated with it. Whenever a thread tries to access a synchronized block or method, it acquires the intrinsic lock or the monitor on that object or Object level Lock. In case of static methods, the thread acquires the lock over the class object.

public synchronized void doAtomicTransfer(){
  //enter synchronized block , acquire lock over this object.
  operation1()
  operation2();   
} // exiting synchronized block, release lock over this object.

An intrinsic locking mechanism can have some functional limitations, such as:

• It is not possible to interrupt a thread waiting to acquire a lock (lock Interruptibly).
• It is not possible to attempt to acquire a lock without being willing to wait for it forever (try lock). Only one thread can hold the lock at once: there's no facility, for example, to allow multiple threads holding a lock simultaneously for read-only access.
• Cannot implement non-block-structured locking disciplines, as intrinsic locks must be released in the same block in which they are acquired.

Explicit locks are useful in cases where you need to overcome some of the shortcomings of built-in synchronization. In particular, they have the following features:

• A thread can attempt to acquire a lock interruptibly;
• A thread can give a timeout value for attempting to acquire the lock;
• Read/write locks are supported– that is, locks that allow multiple concurrent readers if the lock is not locked for writing;
• The traditional wait/notify metaphor is extended to allow conditions (see below);
• Support for fairness (if more than one thread is waiting for a lock, they acquire in first-in-first-out order when it becomes available);
• The ability to lock beyond the scope of a block: for example, one method can pass a lock object to another thread;
• Locks can be queried to find out, for example, if they currently have any threads waiting to acquire them.

Answer 3

"class-level" locking, and "object-level" locking are artificial ideas, created by authors who probably do not have a deep understanding of how Java's intrinsic locking works.

class-level locking looks like this:

class Foobar {
    static synchronized void moo() { ... }
}

But that construct actually is just a shorthand way of writing:

class Foobar {
    static void moo() {
        synchronized (Foobar.class) { ... }
    }
}

And object-level locking, which looks like this:

class Foobar {
    synchronized void baa() { ... }
}

Is nothing but shorthand for:

class Foobar {
    static void baa() {
        synchronized (this) { ... }
    }
}

So really, underneath "class-level" and "object-level" locking, there is only one concept, the synchronized block:

synchronized(objectReference) {...}

All you need to know is that the JVM will not allow more than one thread to synchronize on the same object at the same time.

When data that you want to protect are global, then it makes sense to synchronize on a global, singleton object while accessing the data. Foobar.class is a global singleton.

When data that you want to protect are entirely contained within some object instance, then it makes sense to synchronize on something associated with that instance or, on the instance itself (i.e., this).