Java Threads, Second Edition

The Volatile Keyword

As we mentioned in Chapter 3, the act of setting the value of a variable (except for a long or a double) is atomic. That means there is generally no need to synchronize access simply to set or read the value of a variable.

However, Java’s memory model is more complex than that statement indicates. Threads are allowed to hold the values of variables in local memory (e.g. in a machine register). In that case, when one thread changes the value of a variable, another thread may not see the changed value. This is particularly true in loops that are controlled by a variable (like the shouldRun variable that we use to terminate threads): the looping thread may have already loaded the value of the variable into a register and will not necessarily notice when another thread sets that variable to false.

There are many ways to deal with this situation. You can synchronize on the object that contains the control variable—or better yet, you can provide accessor methods for the control variable (such as we do with the busyflag variable in our BusyFlag class). Or you can mark the variable as volatile, which means that every time the variable is used, it must be read from main memory.

In versions of the VM through 1.2, the actual implementation of Java’s memory model made this a moot point: variables were always read from main memory. But as VMs become more sophisticated, they will introduce new memory models and optimizations, and observing this rule will be increasingly important. ...