static synchronized method

[Ross]

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?

Cheers,

Ross

 

[markspace]

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.

 

[Henderson]

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.

 

[Roedy Green]

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?

Static methods sync on the class object, one per classloader, usually
one per JVM.

 

[lewbloch]

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.

Classloaders define a sort of namespace wherein the "same" class from
two different classloaders is actually two different classes. Like so
much in Java, this is a very powerful technique that can mess you up a
lot if you're careless or don't fully grasp the consequences.

Classloader magic is one of those "here there be dragons" regions of
Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
it comes to their use.

 

[Alice]

Classloaders define a sort of namespace wherein the "same" class from
two different classloaders is actually two different classes. Like so
much in Java, this is a very powerful technique that can mess you up a
lot if you're careless or don't fully grasp the consequences.

Classic pontification.

Classloader magic is one of those "here there be dragons" regions of
Java. I've dabbled in it, but I am Dukas' Sorcerers Apprentice when
it comes to their use.

Classic pontification.

 

[Ross]

Thanks. The program just uses the standard ClassLoader, and doesn't
even have that many classes.

In the static synchronized method, a password file is being rewritten.
If this program gets adopted long term, I'll be rewriting it to use a
proper database, and data synchronisation issues will disappear. But
"static synchronized" will do for the meantime.

 

[lewbloch]

Classic pontification.


Classic pontification.

Troll. Plonk.

 

[lewbloch]

Thanks. The program just uses the standard ClassLoader, and doesn't
even have that many classes.

In the static synchronized method, a password file is being rewritten.
If this program gets adopted long term, I'll be rewriting it to use a
proper database, and data synchronisation issues will disappear. But
"static synchronized" will do for the meantime.

Why do you want the method to be static?

It's not wrong, but an instance method would also work. I'm
interested in the reasoning.

 

[Alice]

Troll.

What does your trolling have to do with Java, lewbloch?

Plonk.

Famous last word.