How to detect synchronization violations with Java

Question

Hi,

I'm wondering what good ways there would be make assertions about synchronization or something so that I could detect synchronization violations (while testing).

That would be used for example for the case that I'd have a class that is not thread-safe and that isn't going to be thread-safe. With some way I would have some assertion that would inform me (log or something) if some method(s) of it was called from multiple threads.

I'm longing for something similar that could be made for AWT dispatch thread with the following:

public static void checkDispatchThread() {
 if(!SwingUtilities.isEventDispatchThread()) {
  throw new RuntimeException("GUI change made outside AWT dispatch thread");
 }
}

I'd only want something more general. The problem description isn't so clear but I hope somebody has some good approaches =)

Answer 1

For the specific example you give, SwingLabs has some helper code to detect event thread violations and hangs. https://swinghelper.dev.java.net/

A while back, I worked with the JProbe java profiling tools. One of their tools (threadalyzer?) looked for thread sync violations. Looking at their web page, I don't see a tool by that name or quite what I remember. But you might want to take a look. http://www.quest.com/jprobe/performance-home.aspx

Answer 2

You are looking for the holy grail, I think. AFAIK it doesn't exist, and Java is not a language that allows such an approach to be easily created.

"Java Concurrency in Practice" has a section on testing for threading problem. It draws special attention to how hard it is to do.

Answer 3

When an issue arises over threads in Java it is usually related to deadlock detection, more than just monitoring what Threads are accessing a synchronized section at the same time. JMX extension, added to JRE since 1.5, can help you detect those deadlocks. In fact we use JMX inside our own software to automatically detect deadlocks an trace where it was found.

Here is an example about how to use it.

Answer 4

As well as @Fernando's mention of thread deadlocking, another problem with multiple threads is concurrent modifications and the problems it can cause.

One thing that Java does internally is that a collection class keeps a count of how many times it's been updated. And then an iterator checks that value on every .next() against what it was when the interator was created to see if the collection has been updated while you were iterating. I think that principle could be used more generally.

Answer 5

Try ConTest or Covertity

Both tools analyze the code to figure out which parts of the data might be shared between threads and then they instrument the code (add extra bytecode to the compiled classes) to check if it breaks when two threads try to change some data at the same time. The two threads are then run over and over again, each time starting them with a slightly different time offset to get many possible combinations of access patterns.

Also, check this question: http://stackoverflow.com/questions/111676/unit-testing-a-multithreaded-application

Answer 6

You can use Netbeans profiler or JConsole to check the threads status in depth

Answer 7

You might be interested in an approach Peter Veentjer blogged about, which he calls The Concurrency Detector. I don't believe he has open-sourced this yet, but as he describes it the basic idea is to use AOP to instrument code that you're interested in profiling, and record which thread has touched which field. After that it's a matter of manually or automatically parsing the generated logs.

Answer 8

If you can identify thread unsafe classes, static analysis might be able to tell you whether they ever "escape" to become visible to multiple threads. Normally, programmers do this in their heads, but obviously they are prone to mistakes in this regard. A tool should be able to use a similar approach.

That said, from the use case you describe, it sounds like something as simple as remembering a thread and doing assertions on it might suffice for your needs.

class Foo {

  private final Thread owner = Thread.currentThread();

  void x() {
    assert Thread.currentThread() == owner;
    /* Implement method. */
  }

}

The owner reference is still populated even when assertions are disabled, so it's not entirely "free". I also wouldn't want to clutter many of my classes with this boilerplate.

The Thread.holdsLock(Object) method may also be useful to you.

Answer 9

IntelliJ IDEA has a lot of useful concurrency inspections. For example, it warns you when you are accessing the same object from both synchronised and unsynchronised contexts, when you are synchronising on non-final objects and more.

Likewise, FindBugs has many similar checks.