Java多线程学习（三）——Sharing Objects

In the absence of synchronization, the compiler, processor, and runtime can do some downright weird things to the order in which operations appear to execute.  Attempts to reason about the order in which memory actions "must" happen in insufficiently synchronized multithreaded programs will almost certainly be incorrect.

要点：编译器优化会导致程序执行顺序有变化，从而导致多线程问题

解决方案：always use the proper synchronization whenever data is shared across threads

Nonatomic 64-bit operations

64-bit nemeric variables (double and long) that are not declared volatile. The Java Memory Model requires fetch and store operations to be atomic, but for nonvolatile long and double variables, the JVM is permitted to treat a 64-bit read or write as two separate 32-bit operations.

Locking and Visibility

Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock.

Volatile variables

When a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations. Volatile variables are not cached in registers or in caches where they are hidden from other processors, so a read of a volatile variable always returns the most recent write by any thread.

Locking can guarantee both visibility and atomicity; volatile variables can only guarantee visibility.

使用volatile variables的情况：

1. Writes to the variable do not depend on its current value, or you can ensure that only a single thread ever updates the value;

2. The variable does not participate in invariants with other state variables; and

3. Locking is not required for any other reason while the variable is being accessed

Safe publication idioms

To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:

1. Initializing an object reference from a static initializer;

2. Storing a reference to it into a volatile field or AtomicReference;

3. Storing a reference to it into a final field of a properly constructed object; or

4. Storing a reference to it into a field that is properly guarded by a lock.

对于Java的thread-safe collections来说：

1. Placing a key or value in a HashTable, synchronizedMap, or ConcurrentMap safely publishes it to any thread that retrieves it from the Map(whether directly or via an iterator)

2. Placing an element in a Vector, CopyOnWriteArrayList, CopyOnWriteArraySet, synchronizedList, or synchronizedSet safely publishes it to any thread that retrieves it from the collection;

3. Placing an element on a BlockingQueue or a ConcurrentLinkedQueue safely publishes it to any thread that retrieves it from the queue.