Peter Veentjer illustrates why you should care about the subject of sequential Java and what is actually implied by the term.
A lot of developers still think that Java is sequential consistent, but what does it mean? When code is executed by multiple threads, only results of all possible interleavings following the order of instructions in the sourcecode, are allowed and the most recently written variable will be visible when a read is done. Example: class Foo{ int a,b; void init(){ a=1; b=1; } void print(){ println(format("a=%s b=%s"),a,b); } } If init and print are called by different threads, according to sequential consistency you can expect the following output: a=0 b=0 a=1 b=0 a=1 b=1 The problem is that ‘a=0 and b=1′ also is possible because Java is not sequential consistent. This strange behaviour can be attributed to certain compiler optimizations: 1. reordering: a=1 and b=1 could be reordened (maybe the compiler thinks it improves the chance of a cache hit, or the cpu stalls the execution of a=1 and starts with the execution of b=1 or just executes them in parallel but b=1 instruction finishes before a=1) 2. visibility: it could happen that the write of a=1 is later visible in the thread that calls print than b=1 (a visibility problem could also be seen as a reordering problem).
Read the complete post by Peter on Sequential consistent Java: Veentjer