Threading - SCJD Exam with J2SE 5 - page 88

However, if it were required that elementExists be absolutely accurate (that is, if you
could not afford to receive an incorrect answer while another thread was in the middle of
inserting or removing elements into the ArrayList by another thread), then you would syn-
chronize access here as well.
This section integrates some of the ideas already presented. The concept of locking is fun-
damental to understanding threading, and you will gain a lot by paying careful attention here.
Locking Objects
You lock objects all the time in everyday life. When you go the movies, you might “lock” your
seat by leaving your coat on it. Even if you leave the seat to buy some popcorn, it is under-
stood that no one should sit down in that seat. The act of leaving your coat on the seat
effectively marks the seat for your exclusive use until you choose to release it.
Any Java object can be claimed for exclusive use. This is one of the explicit ways that Java
supports multithreading. Java further supports multithreading by allowing objects to broad-
cast when they are freed and by forcing threads that want a locked resource to become
inactive until those resources are freed.
If an object is not explicitly claimed, it is open for any thread's use. Similarly, a seat in a
movie theater that is not explicitly claimed can be taken at any time. This means that if you
leave your seat to buy some refreshments and don't lock the seat by leaving your coat on it,
then you shouldn't be surprised if someone else has claimed your seat when you get back.
Even if this strategy has worked in the past, it is not thread-safe for future use. The same is
true in Java. Unless your classes are made explicitly thread-safe, the fact that they have been
uncorrupted in the past is no guarantee that they will not be corrupted in the future.
There is a second level of depth to this metaphor. Someone might take your movie theater
seat anyway, even though your coat is on it. The same is true in Java. A locked object can be
violated if the thread that is modifying it does not respect synchronization.
For example, suppose you have a method that synchronizes on a member variable:
public void goodMethod() {
synchronized (myObject) {
//do stuff to myObject
}
}
A second method could modify myObject if it chooses not to synchronize on myObject .
Synchronizing on an object means “I'll respect other people's locks on this object, and I hope
they respect mine.” However, it is unenforced. Thus, the following example would refuse to
respect the synchronization established in goodMethod , and would execute without complaint.
This could cause problems if badMethod modifies myObject , as other threads that have synchro-
nized on myObject would be expecting to have exclusive access to myObject .
public void badMethod() {
//do stuff to myObject
}
Of course, these methods' names don't really imply that one way is “good” and another is
“bad.” For example, badMethod might just need to read myObject . If so, depending on context,
it may be perfectly okay not to synchronize on myObject . As is often the case, “good” and “bad”