blog rss feed

Introduction to reducing thread contention in Java

Keywords:

Last editor: Dave Cherry, last modified: Oct 25, 2009

This article assumes that you are already familiar with concurrent programming and design. Java 1.5 introduced the concurrent library java.util.concurrent, which provides an extensive set of classes for dealing with concurrency issues, these sit alongside some existing classes that have been around since earlier times. I've noticed that some of the classes I mention here don't get used as often as they should, especially given that they are quick wins. This article only scratches the surface of the new classes available, but should provide a starting point for further reading.

How to avoid synchronization with thread local

There are many cases where synchronization can be avoided by using ThreadLocal. These cases are usually where an object that is heavy to create such as SimpleDateFormat needs to be cached for later use, but the code in question is multi-threaded and therefore would cause multithreaded access to the variable.

java.lang.ThreadLocal does exactly this, as it is a wrapper object, that ensures each thread gets its own copy of the variable being protected; works best when an application is composed of a few long lived threads. See the example below:


import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

public class Concurrent
{
    private ThreadLocal<DateFormat> sdf = new ThreadLocal<DateFormat>() {
        protected DateFormat initialValue()
        {
            return new SimpleDateFormat("yyyyMMdd'T'HH:mm:ss");
        }
    };

    public String someOperation()
    {
        return "important text created at " + sdf.get().format(new Date());
    }


    public static void main(String[] args)
    {
        Concurrent con = new Concurrent();
        System.out.println(con.someOperation());
    }
}

So how does it work?

In the example above we create an anonymous class that extends ThreadLocal, in the simplest case, you override the initialValue(..) method. Consider initialValue like a constructor that gets called the first time a thread access the variable. In order to access the stored variable call get(..), which returns the correct type, as it is a Java 1.5 generic class.

It really is that simple, and can avoid costly synchronization when a per thread variable is all that's required. Next step, concurrent maps.

1 2 3 4 >>

Comments [2]

On 13-Apr-2010 00:20,  Richard Wilson wrote:

I shouldn't be static. What if you want a different DateFormat for different instances of Concurrent?

On 28-Nov-2008 13:03,  Johan Rydahl wrote:

ThreadLocal should really be declared static.

Please leave a comment



Search

Blog calendar

blog: previous month September 2010 blog: next month
su mo tu we th fr sa
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30