[concurrency-interest] New bug pattern, way to common

jason marshall jdmarshall at gmail.com
Sun Mar 23 14:57:24 EDT 2008

I can only recall using synchronize(getClass()) willfully in one
scenario (a couple occasions), and that was when I was building tables
of metadata about classes.

I don' tend to use class metadata in that manner anymore, so I haven't
used it in quite some time.  But I bet plenty of frameworks still do.
Especially class manipulation kits, but I suspect Hibernate does as

On Sun, Mar 23, 2008 at 11:19 AM, Gregg Wonderly <gregg at cytetech.com> wrote:
> Luke Blanshard wrote:
>  > This is still buggy.  Suppose you added class C extends A, and have
>  > thread 1 create an A and thread 2 create a C.  Now the inc method will
>  > be able to run simultaneously in both threads.
>  >
>  > It would only make sense to synchronize on getClass if there were "class
>  > instance" variables in Java, as in some variants of Smalltalk.
>  I don't know that I have a great example of when this behavior would actually be
>   correct.  It seems like findbugs could alert one to refererences to non-final
>  or non-private references within synchronized(getClass()) blocks.  I.e.
>  getClass() is okay as long as it's referencing things that only this "Class"
>  instance can see.  As in this example, that would include instance variables as
>  well as methods.  If increment() were final or private, then it's reference
>  would be okay.  It might also be okay to reference methods that were abstract.
>  So, I'm not sure that this could be called a problem coding practice as much as
>  an advanced coding construct that needs careful attention to use correctly.
>  Gregg Wonderly
> _______________________________________________
>  Concurrency-interest mailing list
>  Concurrency-interest at altair.cs.oswego.edu
>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

- Jason

More information about the Concurrency-interest mailing list