Java Reference
In-Depth Information
Locking Class Instances
Java provides a mechanism for locking classes as well as objects. This can be a little confusing,
but the concept is actually very straightforward. A class is just an object, used to create other
objects, just as an axe is an object for creating firewood.
The JVM generates a Class object when your program initially loads for every class the
program uses. Per JVM, there is a single Class object for all of the instance objects of a given
class. You have limited access to the Class object. Because the Class object is itself an object,
you can lock it just as you can lock any other object. What makes the Class object interesting
is its capability to contain static variables and static methods.
Static variables are universal for every object of a class, which means that a single instance
is shared by every object of that class. For example, for objects of the class McBurgerPlace ,
chiefExecutiveOfficer is a static member variable, because it is common to all. No matter
which McBurgerPlace you are eating in, it shares the same chiefExecutiveOfficer with every
other McBurgerPlace . If any McBurgerPlace restaurants were to change the chiefExecutive
Officer , every other McBurgerPlace would instantly be able to sense that change.
A static method is universal for every object of a class, which means that the single method
is shared by every object of the class, per JVM. For example, objects of the class McBurgerPlace
might have createFranchise as a static member method, assuming that creating a franchise
happens at the corporate level. Any McBurgerPlace object can create a new franchise by calling
corporate headquarters and asking to do so. No matter which McBurgerPlace store you are
talking about, the exact same createFranchise method is called.
Using static methods is different from using instance methods in one very important way:
The method exists on the class, not the objects. The proof of this lies in the fact that you can
create a franchise, even if there is no McBurgerPlace store present, by getting in touch with cor-
porate headquarters directly.
So what does all of this have to do with locking? Assume that you want to lock a given
McBurgerPlace for exclusive use while executing a method. For example, if your McBurgerPlace
(say the one on High Street) has a waxFloor method, then you don't want to be doing anything
else while waxing the floor—after all, lawsuits abound.
How do you enforce this exclusivity? In the real world, you make sure that nothing else is
happening in that particular store while waxing is in progress: no making burgers, no selling
French fries, no preparing Joyful Meals. Almost every activity waits until you are done waxing
the floor. To achieve the same exclusivity in Java, you synchronize the method in question by
putting the keyword synchronized in the method declaration:
public synchronized void waxFloor()
This means that any other synchronized methods called on the McBurgerPlace on High
Street will wait until the floor has been waxed.
Note Unsynchronized methods do not respect synchronized methods. Thus, an unsynchronized method
can be executed at any time. It is important to make sure that such methods can do no damage in your
object's state. For example, countMoney is probably safe to leave unsynchronized because it cannot inter-
fere with the waxing of the floor. The method wipeDownTables should probably be synchronized, however,
because it does interfere with the floor waxing.
Search WWH ::




Custom Search