Question

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);

---

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.

Answer 1

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.