When is AtomicInteger preferrable over synchronized?

Question

Since AtomicInteger can be at at least an order of magnitude slower than an int protected by synchronized, why would I ever want to use AtomicInteger?

For example, if all I want is to increment an int value in a thread-safe manner, why not always use:

synchronized(threadsafeint) {
  threadsafeint++;
}

instead of using the much slower AtomicInteger.incrementAndGet()?

Peter Lawrey · Accepted Answer · 2012-07-26T14:00:48.723

Since AtomicInteger can be at at least an order of magnitude slower than an int protected by synchronized, why would I ever want to use AtomicInteger?

AtomicInteger is much faster.

static final Object LOCK1 = new Object();
static final Object LOCK2 = new Object();
static int i1 = 0;
static int i2 = 0;
static final AtomicInteger ai1 = new AtomicInteger();
static final AtomicInteger ai2 = new AtomicInteger();

public static void main(String... args) throws IOException {
    for(int i=0;i<5;i++) {
        testSyncInt();
        testAtomicInt();
    }
}

private static void testSyncInt() {
    long start = System.nanoTime();
    int runs = 10000000;
    for(int i=0;i< runs;i+=2) {
        synchronized (LOCK1) {
            i1++;
        }
        synchronized (LOCK2) {
            i2++;
        }
    }
    long time = System.nanoTime() - start;
    System.out.printf("sync + incr: Each increment took an average of %.1f ns%n", (double) time/runs);
}

private static void testAtomicInt() {
    long start = System.nanoTime();
    int runs = 10000000;
    for(int i=0;i< runs;i+=2) {
        ai1.incrementAndGet();
        ai2.incrementAndGet();
    }
    long time = System.nanoTime() - start;
    System.out.printf("incrementAndGet: Each increment took an average of %.1f ns%n", (double) time/runs);
}

prints

sync + incr: Each increment took an average of 32.4 ns
incrementAndGet: Each increment took an average of 20.6 ns
sync + incr: Each increment took an average of 31.4 ns
incrementAndGet: Each increment took an average of 12.9 ns
sync + incr: Each increment took an average of 29.6 ns
incrementAndGet: Each increment took an average of 12.9 ns
sync + incr: Each increment took an average of 35.1 ns
incrementAndGet: Each increment took an average of 16.6 ns
sync + incr: Each increment took an average of 29.9 ns
incrementAndGet: Each increment took an average of 13.0 ns

Adding some contention as @assylias suggests. It shows that when you are only really using one thread the CPU can optimise the access.

static final Object LOCK1 = new Object();
static final Object LOCK2 = new Object();
static int i1 = 0;
static int i2 = 0;
static final AtomicInteger ai1 = new AtomicInteger();
static final AtomicInteger ai2 = new AtomicInteger();

public static void main(String... args) throws  ExecutionException, InterruptedException {
    for(int i=0;i<5;i++) {
        testSyncInt();
        testAtomicInt();
    }
}

private static void testSyncInt() throws ExecutionException, InterruptedException {
    long start = System.nanoTime();
    final int runs = 1000000;
    ExecutorService es = Executors.newFixedThreadPool(2);
    List<Future<Void>> futures = new ArrayList<>();
    for(int t=0;t<8;t++) {
        futures.add(es.submit(new Callable<Void>() {
            public Void call() throws Exception {
                for (int i = 0; i < runs; i += 2) {
                    synchronized (LOCK1) {
                        i1++;
                    }
                    synchronized (LOCK2) {
                        i2++;
                    }
                }
                return null;
            }
        }));
    }
    for (Future<Void> future : futures) {
        future.get();
    }
    es.shutdown();
    long time = System.nanoTime() - start;
    System.out.printf("sync + incr: Each increment took an average of %.1f ns%n", (double) time/runs/2);
}

private static void testAtomicInt() throws ExecutionException, InterruptedException {
    long start = System.nanoTime();
    final int runs = 1000000;
    ExecutorService es = Executors.newFixedThreadPool(2);
    List<Future<Void>> futures = new ArrayList<>();
    for(int t=0;t<8;t++) {
        futures.add(es.submit(new Callable<Void>() {
            public Void call() throws Exception {
                for (int i = 0; i < runs; i += 2) {
                    ai1.incrementAndGet();
                    ai2.incrementAndGet();
                }
                return null;
            }
        }));
    }
    for (Future<Void> future : futures) {
        future.get();
    }
    es.shutdown();
    long time = System.nanoTime() - start;
    System.out.printf("incrementAndGet: Each increment took an average of %.1f ns%n", (double) time/runs/2);
}

prints

sync + incr: Each increment took an average of 478.6 ns
incrementAndGet: Each increment took an average of 191.5 ns
sync + incr: Each increment took an average of 437.5 ns
incrementAndGet: Each increment took an average of 169.8 ns
sync + incr: Each increment took an average of 408.1 ns
incrementAndGet: Each increment took an average of 180.8 ns
sync + incr: Each increment took an average of 511.5 ns
incrementAndGet: Each increment took an average of 313.4 ns
sync + incr: Each increment took an average of 441.6 ns
incrementAndGet: Each increment took an average of 219.7 ns

I'm now really confused. That's not what I understood from @Gray's answer here: http://stackoverflow.com/a/11125474/722603 What am I missing? — ef2011, Jul 26 '12 at 13:48
I think he means that `AtomicInteger` is slower than an *unsynchronized* `int`; he's talking about why you shouldn't replace all your `int` members with `AtomicInteger` without justification. But it's not an order of magnitude slower, any more than it's an order of magnitude faster. For the most part these are all small differences we're talking about. — Ernest Friedman-Hill, Jul 26 '12 at 13:50
I remember reading somewhere that locking mechanism also different for Atomic stuff, but couldn't get that reference right now. I may be wrong too. — kosa, Jul 26 '12 at 13:50
@thinksteep - Atomic types typically don't use locking. They use atomic "compare and swap" instructions, and the like. Reference: http://www.ibm.com/developerworks/java/library/j-jtp11234/ — Stephen C, Jul 26 '12 at 13:55
@StephenC: Thanks for the link it will refresh my understanding. — kosa, Jul 26 '12 at 13:57
@PeterLawrey You have been gentle - you could have added a little bit of contention to make the case of the CAS vs. monitor ;-) — assylias, Jul 26 '12 at 13:57
Wow. If so, the answer is simple: When you need that extra performance *and* `AtomicInteger` can still satisfy thread safety requirements (although this could be tricky sometimes in regard to race conditions). Did I get this right this time? — ef2011, Jul 26 '12 at 13:59
@assylias It slowed down the updates significantly, but the relative result was the same. — Peter Lawrey, Jul 26 '12 at 14:01
@ef2011 I would agree that AtomicInteger is the best choice if it does exactly what you need. If you have other operations you need, it might not be. — Peter Lawrey, Jul 26 '12 at 14:02
@PeterLawrey Interesting - I would have thought differently. Thanks for the update. — assylias, Jul 26 '12 at 14:03
Checking JCiP 15.3.2 - the effect seems more noticeable with moderate contention but it can reverse at high contention levels. — assylias, Jul 26 '12 at 14:07
At 8 threads on 8 cores, the performance is the same. If this is all your program does, you need a redesign IMHO. ;) — Peter Lawrey, Jul 26 '12 at 14:19

score 2 · Answer 2 · edited Oct 15 '14 at 16:08

2

if you really want to get more details on why java.util.concurrent stuff is better and what the difference is compared to the classical synchronized approach, read this link (and the whole blog generally)

edited Oct 15 '14 at 16:08

Michael Mior

28,107
9
89
113

answered Jul 26 '12 at 13:50

Andrey Borisov

3,160
18
18

When is AtomicInteger preferrable over synchronized?

2 Answers2

Linked