This is a pretty crappy article in my opinion, and certainly won't do anything to help the problem that the author describes - that developers' knowledge of con

This is a pretty crappy article in my opinion, and certainly won't do anything to help the problem that the author describes - that developers' knowledge of concurrency comes piecemeal without any structure. I challenge anyone to gain an understanding of volatile variables from his description. His example of volatile vs. synchronised contains an example of incorrect code but not an example of how it should be fixed, and doesn't even contain a particularly clear explanation of why it's bad. The explanation of the bytecode generated for a synchronised method compared to a synchronised block is curious if you're into bytecode but totally useless for a working programmer, and offers no guidance on choosing between them. Worse, it actually makes it sound like the option you almost certainly don't want (the synchronised method) is somehow more efficient than the almost universally better method (synchronising on a lock object, which provides much better lock granularity, prevents deadlock in the case of some external object claiming your object lock and generally makes lock ownership much clearer and easier to track). Finally, his example of the AtomicReferenceFieldUpdater ignores the javadoc (This class is designed for use in atomic data structures in which several reference fields of the same node are independently subject to atomic updates) and proceeds to show a contrived example of a compareAndSet that is really only a more confusing set, and doesn't actually achieve anything at all. There are much better sources to learn this stuff if you really need to know it, starting with Java Concurrency In Practice - no Java programmer should be writing concurrent code without having read the first 7 chapters of this.