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?
No comments:
Post a Comment