I worked at a place that used a commercial static code analysis system called Coverity Prevent, and it was freaking amazing! It's really sophisticated and intelligent.
We threw about 18 GB of both open-source and proprietary C and C++ code at it, and it would trace through the code paths and quickly find subtle bugs that would take a human forever to track down. It was also great at pinpointing things that would usually be Heisenbugs.
It ran every few days against our code base, and a nice feature was that we could tell it, "This isn't really a bug," and it would remember that in the future.
The gotcha is, Coverity is really expensive. They don't publish the costs, but I get the sense that for commercial projects, it starts in the hundreds of thousands of dollars per year. But it probably saved us having to hire a whole bunch of developers and QA staff, so on the whole our management seemed to think it was a good buy.
Having had that experience, I look quite favorably on static code analysis.
Anything that is a measurable, well-defined pattern can be parsed.
A deeper question is why would this be important (and important enough to measure and evaluate it with a tool)? How would you meaningfully 'score' or quantify the results, and how would you use those scores? The answer to those questions will tell you why there aren't many tools with that kind of capability, and the ones that are out there with a feature-set advertising this kind of capability are limited, either: pricey, fragile, or some blended combination of the two.
In the past, at least six or eight years ago, I saw these features in the upper end editions of UML tools, like Rational and Sparx Systems (architect/enterprise oriented editions of each respective version). From what I can remember, these products could sometimes 'see' EAA patterns in models of imported/analyzed source. They would suggest complementing patterns and naming for other facets that were participating somehow. Or they would let you 'stub-in' skelatons of these patterns (somewhat useful, but counter to a degree in how patterns are supposed to more often than not, organically emerge).
Identifying patterns of any kind was a very new concept at the time, and in one of the first sets of tools that would incorporate this kind of built-in feature, finding patterns of any kind, but also including EAA patterns. I haven't really looked at them since, so perhaps they are now more refined, stable, and economically feasible.
Perhaps they are also available from someone where the tools operate directly on source (instead of a model), but I am not aware of it.
Best Answer
Answering your first question:
http://www.contemplateltd.com/threadsafe/faq#non-checkers
"What kinds of concurrency defects does ThreadSafe not look for?
We do not yet include support for all of java.util.concurrent. Specifically, ThreadSafe does not check for misuse of the advanced synchronization facilities provided by java.util.concurrent, for example the java.util.concurrent.atomic package. Nor does it currently include any checkers for mistakes that may occur when writing parallel programs using the Fork-Join framework.
Finding bugs in intricate lock-free algorithms requires analysis technology that does not scale well. Such algorithms should be left to specialized concurrency experts. ThreadSafe can be configured to find defects in applications that use libraries containing such algorithms.
Which analyses we include in new releases of ThreadSafe is dictated both by what is possible using analysis technology that is mature enough for integration into a usable product, and by the features and concurrency defects that we see often in ‘average’ Java programs.
If you have a Java concurrency problem that is not currently covered by ThreadSafe, Contemplate’s Java concurrency specialists may be able to help by adding custom configuration to ThreadSafe and/or by use of advanced analysis technology that is not yet mature enough for integration into ThreadSafe."