Question: After reading "[Java concurrent in practice](http://jcip.net/)" and "[OSGI in practice](http://neilbartlett.name/blog/osgibook/)" I found a specific subject very interesting; Safe Publication. The following is from JCIP:

> 
> To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
> 
> 
> * Initializing an object reference from a *static* initializer.
> * Storing a reference to it into a *volatile* field.
> * Storing a reference to it into a *final* field.
> * Storing a reference to it into a field that is properly guarded by a (*synchronized*) lock.
> 
> 
> 

My first question: how many java developers are aware of this (problem)?
How many real world java applications are really following this, AND is this really a real problem? I have a feeling that 99% of the implemented JVMs out there are not that "evil", i.e. a thread is not guaranteed (in fact its practical (almost) "impossible") to see stale data just because the reference is not following the "safe publication idiom" above.

Answer: 
"is this really a real problem?" 

Yes absolutely. Even the most trivial web application has to confront issues surrounding concurrency. Servlets are accessed by multiple threads, for example. 

The other issue is that threading and concurrency is very hard to handle correctly. It is almost too hard. That is why we are seeing trends emerge like transactional memory, and languages like Clojure that hopefully make concurrency easier to deal with. But we have a ways to go before these become main stream. Thus we have to do the best with what we have. Reading JCiP is a very good start.
My experience (short-terming and consulting in lots of different kinds of environments
Most applications I've seen) agrees with this intuition - I've never seen an entire system clearly architected to manage this problem carefully (well, I've also almost never seen an entire system clearly architected) . I've worked with very, very few developers with a good knowledge of threading issues. 

Especially with web apps, you can often get away with this, or at least seem to get away with it. If you have spring-based instantiations managing your object creation and stateless servlets, you can often pretend that there's no such thing as synchronization, and this is sort where lots of applications end up. Eventually someone starts putting some shared state where it doesn't belong and 3 months later someone notices some wierd intermittent errors. This is often "good enough" for many people (as long as you're not writing banking transactions).

How many java developer are aware of this problem? Hard to say, as it depends heavily on where you work.