Difference between class level lock and object lock

[Dixit Saurabh]

I have one doubt regarding class level lock and object level lock. It is clear for me if we want to synchronize our static methods then we make these method synchronized and take a class level lock for this.

But my doubt is: If we have a static method that accesses a non-static field (using an instance) and same non static field accessed by other non static synchronized method. Then How we can manage synchronization for this instance variable because two different thread can access synchronized static method and synchronized method.

[Gladwin Burboz]

Two different threads cannot access synchronized static method of a same class as one thread will first get the monitor of class object instance.

Also if there are two threads as below
T1. Thread that has acquired lock on an object instance say O1
T2. Thread from synchronized static method which will attempt to access non-static field using object instance O1

T2 has acquired lock on class-object instance and not on object instance O1.
When T2 attempts to access O1, it will see that O1 is already locked by T1 and will get blocked.

And T2 should acquire lock on O1 as follows:

synchronized(O1) {
   // access O1 variables here
}

[Jim Hoglund]

In other words, a thread cannot enter a synchronized block of code until it holds
the appropriate object lock. For instance methods, this is the lock of an instance.
For static methods this is the Class object lock.

Jim ... ...

[Henry Wong]

Dixit Saurabh wrote:
But my doubt is: If we have a static method that accesses a non-static field (using an instance) and same non static field accessed by other non static synchronized method. Then How we can manage synchronization for this instance variable because two different thread can access synchronized static method and synchronized method.

Another way to think of it is this... The JVM will enforce the locking mechanism. To make sure that only one thread can own the lock at one time. It is *not* a real lock in this regard. There is no locking of accesses, etc. Once you own the lock, you do the access. And if you code the program, such that there is a way to get to a variable by not owning the lock, or by owning different locks (in this example), then is it a flaw in your design.

Henry

[Jim Hoglund]

Good points about owning locks. Sensitive data should be handled in properly synchronized code.
I say "handled" because this does not apply only to data changes. For example, one thread reports
bank account balances while another thread does account transfers. Say the transfer thread properly
takes locks on the 'from' and 'to' account objects. But if the reporting thread does not, it can show a
decreased balance in the 'from' account and the 'to' account balance before it has been increased.

As for class level state, it may be safest to make changes only through synchronized class methods.

Jim ... ...

[Dixit Saurabh]

Thanks to everyone for resolving my doubt. Now it is clear for me.