I have a question on java method syncronization. In class test ,i have one syncronized method a() and another non syncronized method b(). Now if one thread accessing method a ,so it locked the object, Case is that, first thread has not yet finished executing syncronized method a ,then another thread calls non syncronized method b(). will second thread will be able to excute method b ,simutaneously with first thread executing method a.
Ernest Friedman-Hill
,
author and iconoclast
staff
Only synchronized methods care about that "lock." Unsynchronized methods don't even check it. The lock isn't a magical thing that has the power to stop method calls; it's only because a synchronized method contains code to check the lock before starting that synchronization works. There's a special bytecode "monitorenter" that handles this checking.
Anywau, don't think of a lock like a lock on the door; think of it as a signal. Imagine that two roommates have an arrangement: if roommate A comes home and finds a necktie hanging on the doorknob, he knows roommate B is inside entertaining a lady friend, and so he should not come in. This works fine for A and B, because they both know about the arrangement. A and B are like synchronized methods, the apartment is like the locked object, and the necktie is the lock (most Java people call it a "monitor.")
Now, imagine they have a friend C. C knows nothing about this arrangement. C comes along, sees the necktie on the doorknob, says "Huh, I wonder why there's a necktie on the doorknob", opens the door, and says, "Hey, how come there's a necktie hanging on... ooops, sorry..." and leaves, embarrassed.
C is like an unsynchronized method. He totally ignores the necktie.
I'm going to move this thread to our "Threads and Synchronization" forum for followup.
Thanks Ernest for your detailed explanation. what i understand now is object lock or monitor is only for syncronized method call. But here is my question, in this scenario i get the object using singleton pattern and if getInstance() method is syncronized, then what will happened to second thread for calling method B.
Ernest Friedman-Hill
,
author and iconoclast
staff
getInstance() is static, right? You don't say what kind of method B is here.
Every loaded class has an instance of java.lang.Class that represents it in the JVM. Static synchronized methods use the monitor belonging to the java.lang.Class object for their class; therefor static synchronized methods are separate from instance synchronized methods; the two don't interfere.
yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer .Thanks in advance
Ernest Friedman-Hill
,
author and iconoclast
staff
yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer .Thanks in advance
yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer .Thanks in advance
Well, it depends on what your getInstance() method really does!
For example, inside your getInstance() method you have a sleep(5000) call - basically you are forcing the thread to sleep for 5000 seconds. And within this 5000 seconds, you have a second thread that is attempting to call method b. Then -
In order for thread 2 to call method b, it should first get the object using a call to getInstance(), right?
Given this situation, thread 2 will have to wait till it gets the lock (after thread 1 has completed its sleep and released the lock by exiting the synchronized block of code). So, yes in this case thread 2 can not call the unsynchronized method b.
Is this scenario anything close to what you have in mind ?