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.
Firstly "safe publication" is not really an idiom (IMO). It comes straight from the language.

There have been cases of problems with unsafe publication, with use of NIO for instance.

Most Java code is very badly written. Threaded code is obviously more difficult than average line-of-business code.