Does synchronization in java protect modified class fields?

Question

I saw this on Java's synchronization tutorial:

public class SynchronizedCounter {
    private int c = 0;

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

    public synchronized void decrement() {
        c--;
    }

    public synchronized int value() {
        return c;
    }
}

The tutorial says that subsequent calls by different threads block, like so:
A: increment();
B: increment(); <-- has to wait for A to finish

...but say two threads interleave like so:
A: increment(): load c -> 0;
B: decrement(): load c -> 0;
A: increment(): increment c -> 1;
B: decrement(): decrement c -> -1;
A: increment(): save c -> 1;
B: decrement(): save c -> -1;
Finally: c == -1;

Neither has to wait, in my understanding of the tutorial; so is c protected from memory inconsistency?

Due to popular demand: the tutorial

Answer 1

The synchronized keyword on a (non-static) method causes the method to lock on the enclosed object - in this case the instance of SynchronizedCounter. Thus each synchronized method prevents each other synchronized method from running in another thread. So in your example, thread A's call to increment() would complete before thread B's call to decrement() would start. Therefore your class is thread safe.

Answer 2

Your current understanding of Java threading is not complete. In Java, every object has an "implicit lock", which is the object itself. And the "synchronized" keywords uses this implicit lock to make your code thread safe. The following code has the same effect:

public class SynchronizedCounter {
    private int c = 0;

    public  void increment() {
        synchronized(this){
            c++;
        }
    }

    public  void decrement() {
        synchronized(this){
            c--;
        }
    }

    public  int value() {
        synchronized(this){
           return c;
        }
    }
}

Also, if you want to, you can declare multiple objects to server as simple lock objects. This, again, has the same effect:

public class SynchronizedCounter {
    private int c = 0;
    private Object lockObject;
    public  void increment() {
        synchronized(lockObject){
            c++;
        }
    }

    public  void decrement() {
        synchronized(lockObject){
            c--;
        }
    }

    public  int value() {
        synchronized(lockObject){
           return c;
        }
    }
}

Before synchronized method or synchronized block (also sometimes called guarded block) is executed, the executing thread must first obtain the lock. When it doesn't, the code in synchronized methods/block won't be executed. That's why your example will always work, because all the methods share one lock (the implicit one), none of the methods can be executed simultaneously with other methods.

For advanced locking mechanisms, please see the Lock interface.

Answer 3

Yes, c is protected from memory inconsistency.

However if the value of c is copied out of the object via the getter method, then that copy will live separately and become out of date.

None of the methods on SynchronizedCounter can be invoked simultaneously because they are all declared synchronised.

This does two things, firstly it creates a mutually exclusive region by requiring any thread to enter a monitor (http://en.wikipedia.org/wiki/Monitor_%28synchronization%29) and secondly it places memory barriers (http://en.wikipedia.org/wiki/Barrier_%28computer_science%29) at the entry to the method and the exit.

Thus only one thread can modify c at a time, and no matter which thread on which CPU core is executing that method then it will read the latest value of c and will make its change to c visible to the next thread that enters the monitor. For more on the memory barrier side, Doug Lea wrote a very useful guide at http://gee.cs.oswego.edu/dl/jmm/cookbook.html.