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.