Java 5 made numerous changes to various aspects of "Java". In fact, it was probably the biggest update Java has ever made, bringing dozens of new language syntax features, compiler enhancements, and scores of new APIs. In the wake of all these large changes (enums, generics, annotations), we tend to forget about the smaller API additions and how they effect our development. A prime example of this are the concurrency libs.

Java 5 introduced a number of new mechanisms which make threading and locking quite a bit easier. Perhaps the most important of these is ReadWriteLock. Since the release of Java 5, I've started to see more and more code that looks like this:

public void foo() {
    lock.writeLock().lock();
    try {
        bar = "Bad news";
    } finally {
        lock.writeLock().unlock();
    }
}

This is an increasingly common pattern as more and more developers either recognize the power of ReadWriteLock over traditional synchronization, or are allowed by their company to switch to Java 5 specific APIs. It's really hard to argue with this code and it's capabilities. ReadWriteLock(s) provide the flexibility to not only lock in one method and unlock in another, but also have both exclusive and inclusive locking, allowing for greater concurrency and performance.

The interesting thing that I'm beginning to see is that ReadWriteLock is rising in usage completely at the expense of older mechanisms for locking such as synchronized and volatile. For example, the sample above used to be written like this:

public synchronized void foo() {
    bar = "Bad news";
}

Or even like this:

public void foo() {
    synchronized (bar) {
        bar = "Bad news";
    }
}

This style may be a lot less flexible, but it's no less valid. Also, it happens to be less verbose; and for a lot of use cases this is sufficient. Think of how many times you've written a singleton. Is it really necessary to make it thread-safe with a static ReadWriteLock or is synchronizing the method sufficient?

With companies on a "one release behind" policy switching to Java 5, these questions are of rising importance. Design patterns specific to the new features are becoming more dominant, and best practice needs to be defined. Should the use of synchronized be deprecated altogether, or is it still a valid part of the language with valid use-cases? Are there times where ReadWriteLock is just plain overkill? On the flip side of things, what are the performance implications? Is ReadWriteLock used in exclusively exclusive mode that much more performant than synchronized?

public void foo() {

    lock.writeLock().lock();

    try {

        bar = "Bad news";

    } finally {

        lock.writeLock().unlock();

    }

}

Object lock = new Object();

public void foo() {

   synchronized (lock) {

      doSomething();

   }

}