Question

When Synchronization is used there is a performance impact. Can volatile be used in combination with synchronized to reduce the performance overhead ? For example, instance of Counter will be shared among many threads and each thread can access Counter’s public methods. In the below code volatile is used for getter and synchronized is used for setter

public class Counter
{
    private volatile int count;

    public Counter()
    {
        count = 0;
    }

    public int getCount()
    {
        return count;
    }

    public synchronized void increment()
    {
        ++count;
    }   
}

Please let me know in which scenario this might break ?

Answer 1

Yes, you definitely can. In fact, if you look at the source code of AtomicInteger, it’s essentially what they do. AtomicInteger.get simply returns value, which is a volatile int (link). The only real difference from what you’ve done and what they do is that they use a CAS for the increment instead of synchronization. On modern hardware, a CAS can eliminate any mutual exclusion; on older hardware, the JVM will put some sort of mutex around the increment.

Volatile reads are about as fast as non-volatile ones, so the reads will be quite fast.

Not only that, but volatile fields are guaranteed not to tear: see JLS 17.7, which specifies that volatile longs and doubles are not subject to word tearing. So your code would work with a long just as well as an int.

As Diego Frehner points out, you might not see the result of an increment if you get the value “right as” the increment happens — you’ll either see the before or the after. Of course, if get were synchronized you’d have exactly the same behavior from the read thread — you’d either see the before-increment or post-increment value. So it’s really the same either way. In other words, it doesn’t make sense to say that you won’t see the value as it’s happening — unless you meant word tearing, which (a) you won’t get and (b) you would never want.