why the following program can work under JLS spec on JVM memory model

on JLS 3, 17.5 Final Field Semantics's second discussion part: http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5

It is said that myS can equals "/tmp", I personally can not understand this. Any one can give more explain? Another point is what this example tells, does it mean if we want to share Global.s between multi thread, we need to make it final(if it is final, then can not change after construction) or need to sync when read and write? or declare a String array with length 1 and final so that can be changed and shared??

the original contents in JLS:

Consider the following example. One thread (which we shall refer to as thread 1) executes

Global.s = "/tmp/usr".substring(4);

while another thread (thread 2) executes

String myS = Global.s;
if (myS.equals("/tmp"))System.out.println(myS);开发者_JAVA技巧

the explain in JLS:

String objects are intended to be immutable and string operations do not perform synchronization. While the String implementation does not have any data races, other code could have data races involving the use of Strings, and the memory model makes weak guarantees for programs that have data races. In particular, if the fields of the String class were not final, then it would be possible (although unlikely) that Thread 2 could initially see the default value of 0 for the offset of the string object, allowing it to compare as equal to "/tmp". A later operation on the String object might see the correct offset of 4, so that the String object is perceived as being "/usr". Many security features of the Java programming language depend upon Strings being perceived as truly immutable, even if malicious code is using data races to pass String references between threads.

Strings are implemented using a char[], offset, and count. The substring method constructs a new String object with the same char[] and a new offset and count. Based on the execution semantics, it would be possible for the new String to be partially initialized when thread 2 attempts to access it. According to the source, substring returns a new String object constructed with a simple constructor:

644       // Package private constructor which shares value array for speed.
645       String(int offset, int count, char value[]) {
646           this.value = value;
647           this.offset = offset;
648           this.count = count;
649       }

So without marking char[], offset, and count as final in the String class definition, then thread 2 might see inconsistent values when it accesses them. If that happens, then the char[] could be set, but the offset and count might be wrong. If offset was still showing as the default of 0, you'd see the whole string. Of course, it would require amazing timing, specific reordering of instructions by the JIT, and a whole host of "luck" to make this happen.

It depends when "/tmp/usr".substring(4) executes.

Global.s = "/tmp/usr".substring(4);

actually executes as:

Global.s = "/tmp/usr";
s = s.substring(4);

If thread 2 looks up Global.s before that code executes, or (very unlikely) between these two lines, it will see s not as "/usr/", but as null or "/tmp/usr" depending on the timing.

Strings are immutable, but references to Strings are not:

String str = "A"; // "A" is immutable
str = "B";        // variable "str" may be changed to refer to a different String

You need to read that example and explanation in context. The context is that it is explaining why Java defines final fields to have special semantics with respect to the memory model.

The point it is making is that without the special final semantics, one thread could see an immutable object created by another thread in an inconsistent state. The special final semantics prevent this; see JLS 17.5.1. In this case, the fact that the 3 internal fields of the String class are final means that there is a comes-before relationship between the end of a String constructor and any operation on the resulting String.

But the JLS said it can be "/tmp", which i can not understand.

The substring operation is aiming to create a String object whose state is {offset: 4, count: 4, chars: "/tmp/usr".chars}.

But the memory model doesn't guarantee that an unsynchronized thread will see the field updates in the order in which they are made. In particular, it might see the string in the state {offset: 0, count: 4, chars: "/tmp/usr".chars} ... i.e. "/tmp".

(In fact, this doesn't happen because of the special semantics of final fields, as described immediately below the example.)