• Post Reply Bookmark Topic Watch Topic
  • New Topic

synchronized keywords in static methods  RSS feed

 
Srini Krishnan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

If we specify a synchronized keyword for a method,then the lock for that object is grabbed and the operation is done.But how does synchronization works for static method?

Thanks in advance.

Thanks
Srini
 
Henry Wong
author
Sheriff
Posts: 23280
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Srini Krishnan:
Hi,

If we specify a synchronized keyword for a method,then the lock for that object is grabbed and the operation is done.But how does synchronization works for static method?

Thanks in advance.

Thanks
Srini


For static methods, the Class object is used. You can access the class object via the getClass() method, if you have an instance, or YourClass.class, if you don't.

Henry
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this mean a synchronized static method can be run at the same time a regular synchronized method is being run? What happens if they both modify a static variable? I thought no other synchronized method, static or regular, could run while a synchronized static method was running in that same class. Is that true? If not, does that mean that any static variables modified both in instance and static methods must either be thread-safe themselves or the methods must get a lock on that variable?
 
Henry Wong
author
Sheriff
Posts: 23280
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ken Blair:
Does this mean a synchronized static method can be run at the same time a regular synchronized method is being run? What happens if they both modify a static variable? I thought no other synchronized method, static or regular, could run while a synchronized static method was running in that same class. Is that true? If not, does that mean that any static variables modified both in instance and static methods must either be thread-safe themselves or the methods must get a lock on that variable?


Yes. A static method uses a different lock from a regular method. Much the same way as calling regular methods on different instances uses a different lock.

Henry
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Every synchronized method or block works on a given monitor. Synchronized non-static methods all synchronize on the object instance. Synchronized static methods all lock on the class (which is an object itself). A synchronized block of code can synchronize on anything it wants ... maybe the object instance, maybe the class, maybe some other object. So yes, I guess a sync static method and a sync non-static method could both access some shared resource in a bad way. Threads are not for the faint of heart!
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you! I've been confused on this issue as in a few of the things I've read it seemed to indicate that a synchronized static method would prevent any synchronied methods from running concurrently, not just static ones. This means my 'fix' to UIDFactory was completely unnecessary and what Mr. C Lamont Gilbert said makes more sense. So that means any class that has a static variable modified by both static and regular methods the synchronized keyword in the methods isn't enough.



Look about right?
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True. Consider these equivalent things



And for instances of the class


You can see in class Three why I recommend never using 'this' or 'ClassName.class' as the lock object. You have exposed the 'key' to everyone holding the instance, and in case of the static method its even worse. The static monitor is accessible to any class that can see the classloader which for a typical application is every class in existence.
 
Srini Krishnan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I understand the following three things from the discussion.
1.A static method and regular method can run concurrently and can access the same static variable on the class.So the static variable is not thread-safe.
2.For regular synchronized method,the lock will be obtained for the object on which the method is invoked.
3.For static synchronized method,the lock will be obtained for the java.lang.Class's object.It means that another static synchronized method cannot execute during.

If we use the synchonized keyword as below
void regularMethod() {
synchronized(One.class) {
}
}
What kind of lock will be obtained for the above synchronized block.What is the significance of the giving One.class.Does it mean a class level lock as the static synchronized method acquire even though this method is invoked using the object instance.


Also i couldnt understand Mr. C Lamont Gilbert's reply which is pasted below.

"You can see in class Three why I recommend never using 'this' or 'ClassName.class' as the lock object. You have exposed the 'key' to everyone holding the instance, and in case of the static method its even worse. The static monitor is accessible to any class that can see the classloader which for a typical application is every class in existence."

Could you please elaborate on this?

Thanks in advance..

Thanks
Srini
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it mean a class level lock as the static synchronized method acquire even though this method is invoked using the object instance.


Yes.

Also i couldnt understand Mr. C Lamont Gilbert's reply which is pasted below.


Neither could I. I suspect it requires an understanding of classloaders and monitors that neither of us poseess.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, it doesn't require any advanced knowledge: it's a design thing, and it's one that sometimes makes lots of sense, and other times doesn't.

Sometimes, synchronization and uses of wait() and notify() are a private implementation feature that other classes shouldn't know about. In this case, using public synchronized methods (or synchronizing on the publically available Class instance) lets this implementation detail "leak out", and makes it possible for clients to inadvertently break the implementation.

One particularly bad example: the join() method in java.lang.Thread is implemented using wait(), notify(), and synchroinization on the Thread object itself. By locking a Thread object and calling wait() or notify() on it, you can interfere with the functioning of join(). If instead of synchronizing on the Thread itself, a Thread contained a special member object which join() used as a lock instead (via synchronized blocks) then this would be impossible.

But sometimes, a class is synchronized just to prevent concurrent access, and in that case, it's fine to synchronize on the instance itself. This lets you lock an object, then call lots of synchronized methods on it, to produce an uninterrupted sequence of calls. In this case, the synchrionization is part of the public interface -- clients should know about it.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand now. You're saying that if the Class needs to lock on something internally for correct functioning it should lock on something not publicly accessible. If the Class needs to lock on something because of funcionality that is exposed then it's fine because it's known.

Taking the UIDFactory I posted in a different thread as an example, if both the instance and static methods used the same variable they wouldn't want to lock on the Class internally to prevent concurrent modification. A different thread could potentially lock on the Class breaking the code. Instead they would use a third monitor that isn't accessible by the public so it ensures synchronization between it's methods won't be blocked by something irrelevent coded elsewhere.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep!
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Srini, my point was that the 2 methods of class One, aMethod and bMethod do exactly the same thing. They are perfectly equivalent, lock, monitor and all.


Also, in class Two, the 3 methods, aMethod, bMethod, cMethod do exactly the same thing as each other. They are perfectly equivalent.

The methods of class One are different from those of class Two and do not share the same "monitor."
 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now i am confused over lot of discussion.

I have understood so far:
1) Synchronized block is used to lock all object
while Synchronized block is used to lock specific Object
2) better use Synch block when you don't have access over a class.

3) my question is from point 1 , i am not clear about this with example.

and this is also true ?


In the case of synchronized method,the thread aquires object's lock only if we invoke Synchronized method, but in case of synchronized block, first the lock for the reference object is aquired before the method invocation."
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!