Looking for a surprising concurrent Java program

Since I am writing a profiler focusing on concurrency aspects, I am looking for a good artificial example using synchronization mechanisms in Java. My profiler makes visible some actions related to threading; for instance:

• calling notify/wait
• thread changes its state
• a thread is contended with another thread for a monitor lock
• a monitor lock has been acquired by a thread after contending for it with another
• measure the execution time of each method
• which thread has accessed a certain method and how often
• etc.

So what I am looking for, is a Java program which seems to be understood at first glance, but when executing it, you start to wonder about the results. I hope that my profiler might be able to detect what is going on in the background.

To clarify myself I give you an example, the book Java Concurrency in Practice by Brian Goetz gives "toxic" code examples which are used for learning reasons.

@NotThreadSafe
public class ListHelper<E> {
    public List<E> list =
        Collections.synchronizedList(new ArrayList<E>());
    ...
    public synchronized boolean putIfAbsent(E x) {
        boolean absent = !list.contains(x);
        if (absent)
            list.add(x);
        return absent;
    }
}

This is intended to be an extension of a thread-safe class, by the method putIfAbsent. Since list is synchronized, but putIfAbsent uses another lock for protecting the state as the methods defined on the list.

The profiler could display the used monitor locks and to the suprise of the user (or not...) the user would see there are two possible monitor locks instead of one.

I don't like this example very much, but I wouldn't ask, if I had already a bunch of good examples.

I found out my question is similar to this: What is the most frequent concurrency issue you've encoun开发者_如何学Ctered in Java? and Java concurrency bug patterns.

But they refer only to broken concurrent programs. I am also looking for thread-safe implementations, but where it still not obvious that they are thread-safe.

Have a look at the list of FindBugs bug descriptions, specifically those belonging to category of Multithreaded correctness (right table column).

Each of these bugs contain references on why a particular idiom is bad and how can it be solved.

I'd go back in time, like maybe seven years or more, and find some open source code from the era before java.util.concurrent. Just about anything that rolled its own concurrency is going to have some subtle bugs in it, 'cause concurrency is hard to get right.

How about this?

class ObjectReference {

  private volatile Object obj = null;      

  public void set(Object obj) {
    if (obj == null) {
      throw new IllegalArgumentException();
    }
    this.obj = obj;
    synchronized (this) {
      notifyAll();
    }
  }

  /**
   * This method never returns null
   */
  public Object waitAndGet() {
    if (obj != null) {
      return obj;
    }
    synchronized (this) {
      wait();
      return obj;
    }
  }
}

You could get null from waitAndGet() actually. See — Do spurious wakeups actually happen?

Dining philosophers problem is a classical concurrency example. This link has one possible solution and more can be found around the web.

As described in the first link this example illustrates quite many of the common concurrency problems. Please let your profiler show how many it can track!

See the The Java Specialists' Newsletter for a consistent stream of small Java puzzles, many of which should fit your testing needs.

I would recommend looking around (or asking the authors) for the IBM ConTest benchmark suite as it contains a number of Java concurrency bugs (unfortunately not large open-source programs). The good thing about this benchmark is that the bugs are already documented (type, and location).

If you want to find more programs I would recommend taking a look at some of the research papers in the area of software testing/quality of concurrent programs. They should indicate the sample programs they've used in their studies.

If all else fails you could try search on GitHub (or similar service) for repositories that contain the necessary concurrency mechanisms (i.e., synchronization). You might find a large amount of Java code that way, the only problem is that the bugs are not documented (unless you look for commit fixes).

I think these three suggestions will supply you with enough programs to test your concurrency profiler.

Maybe Eclipse or a Tomcat deployment? Neither one is very artificial, but I could imagine wanting good tools while debugging one or the other.