Thread Safe Code and Stress Testing

It just amazes me how much code makes it past code reviews that is not thread safe but should be.
Developers often know that certain code has troubles if it is not thread safe and what thread safe means. However they are not able to effective discern what needs to be thread safe and what does not. I had an individual that was very aware of these issues help mentor me as to how to detect these types of problems. I had seen problems and fix them prior to his mentoring but he really helped me to be proactive and see threading issues when authoring code.

The biggest issue is lack of understanding that beans defined in Spring are singletons. Also even if you inject a prototype into a singleton it effectively makes it a singleton. Then there are the problems where they improperly implement the singleton pattern, randomly synchronize things that don't need to, or create static variables that are not thread safe. I've seen so many times where developers create a static SimpleDateFormat instance. Recently I saw a DAO with local variables that were not thread safe. I also recently saw a persistence layer where they tried to manually implement the singleton pattern but didn't do it correctly so the local variables that were thread safe were not initialized correctly leading to NullPointerExceptions.

I tend to see threading issues revealed when load testing is performed. However to my amazement load testing is not always performed. I've also seen some some threading issues that have snuck past load testing and have never presented themselves as a problem.

We use a continuous integration build server but it only lists thread safety problems as warnings and then only catches half of them because it doesn't know what should or shouldn't be a singleton and thread safe any more than the developers do.

I've recently initialized an internal developer training effort.
There are relatively few developers that can detect these errors and even fewer that can fix them. So it is really an issue as these developers can not code review every line of code.

Are there any ways to catch these kind of problems earlier or some good resources to aid in developer training? Do people have similar experiences?

It seems most developers don't care that code has any more quality than it appears to work correctly. Am I being a little anal retentive and should just go with the flow, realize that code will not be perfect, and just let these problems exist and get resolved later?

First Groovy Script

A couple days ago I wrote my first Groovy script. Of course it had to be loaded into the Spring IoC container to wire it up to the beans using it.
Having a Java background and looking at Groovy's website it was very hard to define a pretty simple class with a method that implements a java interface.
First it made me use the def keyword with the method definition whereas the documentation didn't even have an example of how to write a method.
Then it made me define the return type of the method because it was saying it didn't match the interface return wheras the documentation seemed to indicate these did not have to be statically defined/typed.
The method took in no parameters and returned a List and was returning [instanceofMyObject1, instanceofMyObject2]
The documention showed defining typeless variables without using the def keyword.
It kept looking for member variables in the class so I had to define each one with the keyword def to get it to work.

Is the Groovy documentation really lacking good basic examples like writing a class with a method and using local variables?

The documentation outlined some of the power features but did very little to help people learn the basics other than go over some command line Groovy examples.

Can people recommend some good resources for a Java developer to learn and effectively take full advantage of the capabilities of Groovy?