无法理解Java规范中volatile的示例

Question

I got general understanding what volatile means in Java. But reading Java SE Specification 8.3.1.4 I have a problem understanding the text beneath that certain volatile example.

class Test {
    static volatile int i = 0, j = 0;
    static void one() { i++; j++; }
    static void two() {
        System.out.println("i=" + i + " j=" + j);
    }
}

This allows method one and method two to be executed concurrently, but guarantees that accesses to the shared values for i and j occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread. Therefore, the shared value for j is never greater than that for i, because each update to i must be reflected in the shared value for i before the update to j occurs. It is possible, however, that any given invocation of method two might observe a value for j that is much greater than the value observed for i, because method one might be executed many times between the moment when method two fetches the value of i and the moment when method two fetches the value of j.

How is

j never greater than i

, but at the same time

any given invocation of method two might observe a value for j that is much greater than the value observed for i

??

Looks like contradiction.

I got j greater than i after running sample program. Why use volatile then? It gives almost the same result without volatile (also i can be greater than j , one of previous examples in specs). Why is this example here as an alternative to synchronized ?

Answer 1

At any one time, then j is not greater than i .

This is different from what method two observes because it is accessing the variables i and j at different times. i is accessed first, and then j is accessed slightly later.

This isn't a direct alternative to the synchronized version because the behavior is different. One difference from not using volatile is that without volatile, values of 0 could always be printed. The increment doesn't ever need to be visible.

The example demonstrates the ordering of volatile accesses. An example that requires this could be something like:

volatile boolean flag = false;
volatile int value;

// Thread 1
if(!flag) {
    value = ...;
    flag = true;
}

// Thread 2
if(flag) {
    System.out.println(value);
    flag = false;
}

and thread 2 reads the value that thread 1 set rather than an old value.

Answer 2

I think the point of the example is to emphasize that you need to take care and ensure the order when using volatile; the behavior may be counter-intuitive and the example demonstrates it.

I agree that the wording there is a bit obscure and it is possible to provide more explicit and clear example for multiple cases, but there is no contradiction.

The shared value is the value at the same moment. If two threads read values of i and of j at exactly the same moment, the value of j will never be observed greater than i. volatile guarantees keeping order of reads and updates as in the code.

However, in the sample, print + i and + j are two different operations separated by an arbitrary amount of time; hence, j can be observed larger than i, because it can be updated arbitrary number of times after the read of i and before the read of j.

The point of using volatile is that when you concurrently update and access volatile variables with the right order, you can make assumptions that are not possible in principle without volatile.

In the sample above, the order of access in two() does not allow to conclude with a confidence which variable is greater or equal.

Consider, however, if the sample was changed to System.out.println("j=" + j + " i=" + i);

Here you can assert with a confidence that the printed value of j is never larger than the printed value of i. This assumption will not hold without volatile for two reasons.

First, updates i++ and j++ can be executed by compiler and hardware in an arbitrary order and in reality may execute as j++;i++. If from other thread you then access j and i after j++ but before i++ , you can observe, say, j=1 and i=0 , regardless of the access order. volatile guarantees that this will not happen and it will execute operations in the order that is written in your source.

Second, volatile guarantees that another thread will see most recent values changed by another thread, as long as it accesses it in the later point of time after the last update. Without volatile, there can be no assumptions about the observed value. In theory, the value can stay for another thread zero forever. The program may print two zeros, zero and an arbitrary number, etc. from past updates; the observed value in other threads may be less than the current value that the updater thread sees after an update. volatile guarantees that you will see the value in a second thread after the update in the first.

While the second guarantee may seem as a consequence of the first (the order guarantee), they are in fact orthogonal.

Regarding synchronized , it allows to execute a sequence of non-atomic operations, like i++;j++ as an atomic operation, eg if one thread does synchronized i++;j++ and another does synchronized System.out.println("i=" + i + " j=" + j); , the first thread may not perform increment sequence while the second prints and the result will be correct.

But this comes at a cost. First, synhronized has a performance penalty by itself. Second, more important, not always such behavior is required and the blocked thread wastes time, reducing the system throughput (eg you can do so many i++;j++; during System.out).

Answer 3

I'd like to propose that it's a mistake and the examples were supposed to print j before i :

static void two() {
    System.out.println("j=" + j + " i=" + i);
}

The novelty in the first example is that, due to update reordering, j can be greater than i even when observed first .

The final example now makes perfect sense with some minor edits to the explanation (edits and commentary in brackets):

This allows method one and method two to be executed concurrently, but guarantees that accesses to the shared values for i and j occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread. Therefore, the shared value for j is never [observed to be] greater than that for i , because each update to i must be reflected in the shared value for i before the update to j occurs. It is possible, however, that any given invocation of method two might observe a value for [ i ] that is much greater than the value observed for [ j ], because method one might be executed many times between the moment when method two fetches the value of [ j ] and the moment when method two fetches the value of [ i ].

The key point here is that the second update will never be observed before the first update, when using volatile . The last sentence about the gap between the two reads is entirely parenthetical, and i and j were swapped to conform to the erroneous example.

Answer 4

How is j never greater than i?

Let's say you execute one() only once. During the execution of this method, i is always incremented before j as the increment operations happen one after the other. If you are executing one() concurrently, each individual method call will wait for other methods in the execution queue to finish writing their values to i or j, depending on which variable the currently executing method is trying to increment. So, all writes to i happen one after the other, and all writes to j happen one after the other. And since within the method body itself i is incremented before j, at a given instant, j will never be greater than i.

any given invocation of method two might observe a value for j that is much greater than the value observed for i, how?

If method one() is being executed in the background while you call two() , between the time when i is read and then j is read, the method one can be executed multiple times. So, when the value of i is read it could be the result some invocation of one() that happened at time t=0, and when then value of j is read, it could be the result of an invocation of one() that happened later in time, for example at t=10. Hence, j can be greater than i in this case in the println statement.

Why use volatile in lieu of synchronized?

I will not list all the reasons why anyone should use volatile instead of a synchronized block. But bear in mind that volatile guarantees atomic access to that particular field alone, and does not ensure the atomic execution of a block of code that is not marked as synchronized . In this example, access to i and j are synchronized, but the overall operation {i++;j++} isn't synchronized hence it apparently (I use apparently since it is not exactly the same but looks similar) gives the same results as without using the volatile keyword.

Answer 5

How is

j never greater than i

, but at the same time

any given invocation of method two might observe a value for j that is much >>greater than the value observed for i

??

The first statement is always true at any given moment in the program's execution, and the second statement may be true for any given interval in the program's execution.

When a volatile variable is written to, writes to both it and everything before it must become visible to other threads (In Java 5+, at least. The explanation doesn't really change much for versions of Java before that, though). Thus, the increment of i must be visible by the time j is incremented, meaning that j can never appear greater than i to other threads.

The reads of i and j , though, are not guaranteed to occur at a single moment in the program execution. The read of i and j may appear to occur very close to each other to the thread executing two() , but in reality some arbitrary amount of time may have passed between the reads. For example, two() may read i when i = 5 and j = 5 , but then get "frozen" while other threads execute, changing the values of i and j to, say, 20 and 19 , respectively. When two() resumes, it picks up where it left off and reads j , which now has a value of 19 . two() doesn't re-read i because as far as it is concerned there was no break in execution, so there is no need to undergo the extra work.

Why use volatile then?

While both volatile and synchronized provide visibility guarantees, the precise semantics are slightly different. volatile guarantees that changes made to the variable will be instantly visible to all threads, while synchronized guarantees that changes made in its block will be visible to all threads as long as they synchronize on the same lock . synchronized also provides additional atomicity guarantees that volatile does not.

Why is this example here as an alternative to synchronized?

volatile is a viable alternative to synchronized only if one() is executed by a single thread, which is the case here. In this case, only a single thread is ever writing to i and j , so there is no need for the atomicity guarantees synchronized provides. If one() were executed by multiple threads, volatile wouldn't work because the read-add-store operations that make up an increment must occur atomically, and volatile does not guarantee that.

Answer 6

This program does guarantee that method two() observes j >= i-1 (not considering overflow).

Without volatile , the observed values of i,j could be all over the place.

The statement

the shared value for j is never greater than that for i

is very informal, because it means "at the same time", which is not a defined concept in JMM.

---

The core principle of JMM is about "sequential consistency". The driving motivation of JMM is

JLS#17 - If a program is correctly synchronized, then all executions of the program will appear to be sequentially consistent

In the following program

void f()
{
    int x=0, y=0;
    x++;
    print( x>y );
    y++
}

x>y will always be observed as true . It has to be, if we follow the sequence of actions. Otherwise, there is really no way for us to reason about any (imperative) code. That is "sequential consistency".

"Sequential consistency" is an observed property, it doesn't have to coincide with "real" actions (whatever that means). It is entirely possible that x>y is evaluated to be true by JVM before x is actually incremented (or at all). As long as JVM can guarantee observed sequential consistency, it can optimize actual execution anyway it can, eg execute code out of order.

But this is for a singlet thread. If multiple threads are reading/writing shared variables, such optimizations of course will completely wreck sequential consistency. We cannot reason about program behavior by thinking of interleaving actions from multiple threads (with actions in the same thread following intra-thread sequence).

If we want to guarantee inter-thread sequential consistency of any multi-thread code, we must abandon the optimization techniques developed for single thread. That is going to have severe performance penalty for most programs. And it is also uncalled for -- data exchange among threads is rather rare.

Therefore, special instructions are created just for establishing inter-thread sequential consistency when it is needed. Volatile reads and writes are such actions. All volatile reads and writes obey inter-thread sequential consistency. In this case, it guarantees that j >= i-1 in two() .

Answer 7

All dependes on how you are using it. The volatile keyword in Java is used as an indicator to Java compiler and Thread that do not cache value of this variable and always read it from main memory. So if you want to share any variable in which read and write operation is atomic by implementation eg read and write in an int or a boolean variable then you can declare them as volatile variable.

From Java 5 along with major changes like Autoboxing, Enum, Generics and Variable arguments , Java introduces some change in Java Memory Model (JMM), Which guarantees visibility of changes made from one thread to another also as "happens-before" which solves the problem of memory writes that happen in one thread can "leak through" and be seen by another thread.

The Java volatile keyword cannot be used with method or class and it can only be used with a variable. Java volatile keyword also guarantees visibility and ordering, after Java 5 write to any volatile variable happens before any read into the volatile variable. By the way use of volatile keyword also prevents compiler or JVM from the reordering of code or moving away them from synchronization barrier.

Important points on Volatile keyword in Java

1. The volatile keyword in Java is only application to a variable and using volatile keyword with class and method is illegal.

2. volatile keyword in Java guarantees that value of the volatile variable will always be read from main memory and not from Thread's local cache.

3. In Java reads and writes are atomic for all variables declared using Java volatile keyword (including long and double variables).

4. Using the volatile keyword in Java on variables reduces the risk of memory consistency errors because any write to a volatile variable in Java establishes a happens-before relationship with subsequent reads of that same variable.