markspace wrote:
Ross wrote:
If I have a method which is both static and synchronized, then can I
guarantee that only one thread will be allowed in at once, even if I
have multiple instances of the object in memory, one per thread?
Yes. The "synchronized" keyword on a static method synchronizes on the
class object. Since all instances of that class share one class object,
then there'll be only one thread, period, in that method at a time.
There's a slight exception for class loaders which load load multiple
instances of the same class object. Since all the static method does is
synchronize on the class object, there may be be more than one thread,
one per loaded class object, in those circumstances.
There are some good reasons to have multiple class objects, but it's not
really normal and would usually be considered an error in the class
loader, just so you know.
Also, the likely reason for synchronizing a static method is to make
sure operations it performs on mutable private static variables are
atomic and don't suffer from data races. If there are two copies of the
class via different classloaders, they get their own independent copies
of those static variables as well as their own independent monitors, so
their having separate monitors doesn't create an opportunity for a data
race.
The main concern, instead, is invariant violation when the design
expects a singleton of some sort: a single global registry of some sort,
a single global interning cache, a single INSTANCE reference to a single
singleton instance such as what java.awt.Toolkit.getDefaultToolkit()
returns, etc.; if there are suddenly two of a thing like that when the
design calls for exactly one, then problems can ensue, but problems that
have nothing to do with concurrency and data races.
two different classloaders is actually two different classes. Like so
Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when