This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Synchronizing class variables

Posted by Bill Venners on 25 Jul 1998, 10:37 AM

> > Synchronization works the same in a constructor as it does
> > in a method, so it would certainly be possible to write
> > RGBColor's constructor as you suggest.

> > The one thing to note is that you don't need the synchronization
> > in the constructor, because only one thread can ever be
> > executing the code of the constructor at any one time. No
> > other thread can get a reference to the object until after
> > the construction of the object completes. Hence, you don't
> > need to synchronize anything in the constructor. This means
> > that any synchronization you add to the code executed by
> > the constructor unecessarily gives you a performance hit. My
> > philosophy is to avoid unecessary locking of objects, so
> > I didn't call setColor() from the constructor.

> > Note that you can write a constructor such that synchronization
> > becomes important, though this way of writing a constructor
> > goes against my "Constructors and initializers should just
> > be about initialization, the whole initialization, and nothing
> > but initialization" guideline. For example, from a constructor
> > you could call a method in some other class or object and pass
> > a reference to this (the object being constructed). That other
> > method could give the reference to another thread which could
> > try to invoke a method on the object. I can't imagine any good
> > reason why someone would want to do this, but I'll bet it has
> > probably happened somewhere.

> > bv

>
> I've recently been working with an example that has synchronization
> the constructor - and for good reason. The class has a static
> thread object that it only wants instantiated once. So the code
> looks like this

> public MyClass
> {
> static Thread myThread;

>
> public MyClass
> {
> synchronized (getClass())
> {
> if (myThread == null)
> {
> myThread = new Thread(...);
> }
> }
> }

> :
> }

>
> The ctr actually puts a lock on the class so that we won't
> try and create more than one thread if multiple instances of
> the object are instantiated at once (i.e. from separate threads).

> I hadn't seen any references to the use of getClass() this way,
> but it will server me well in my static class methods that
> need protection as well.

This is a good example of using synchronized inside a
constructor. The times one would need to use synchronized is
to synchronize access to something besides the instance
variables of the object being constructed. In this case, it
is the class variables, but it could also be instance variables
of some other object, though in that case you would think
that that object itself would take care of synchronizing
access to itself.

If you synchronize a class method, the object that gets locked
is the Class object which you lock explicitly in your
synchronized block. So you use the standard way to
synchronize access to class variables from instance methods
(or constructors). One place I know this is documented is
in the Threads book by Doug Lea.

bv