（请注意文章中加粗的字体）
1. 计算机体系结构，多处理器，高速缓存和内存
图1.1
从计算机的体系结构我们可以知道，在处理器和主内存直接都会有高速缓存，这层高速缓存的存在是因为内存存储设备与处理器的运算速度之间有着几个数量级的差距，所以现代计算机系统都会加入这样一层读写速度尽可能接近处理器运算速度的高速缓存（cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速运行，当运算结束后再从缓存同步回内存中，这样处理器就无须等待缓慢的内存读写了。
基于高速缓存的存储交互很好滴解决了处理器与内存的速度矛盾，但是也引入了新的问题：缓存一致性（Cache Coherence）（参考：）。在多处理器系统中，每个处理器都有自己的高速缓存（这个高速缓存主要是作为线程的工作内存来使用的，见后），而它们又共享同一主内存（Main Memory），如图1.1所示。当多个处理器的运算任务都涉及到同一块主内存区域时（其实就是多线程并发时对共享变量的读写操作），将可能导致各自的缓存数据不一致的情况，如果真的发生这种情况，那同步回到主内存是以谁的数据为准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时需要根据协议来进行操作。
除此之外，为了使处理器内部的运算单元能尽量充分利用，处理器可能会对输入代码进行乱序执行（out-of-order execution）优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果一致，因此如果存在一个计算任务依赖另一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，java虚拟机的及时编译器中也有类似的指令重排序（instruction reorder）优化。（这里涉及到的指令重排序跟多处理器架构的cache分片有关，参考：）
2. java内存模型（Java Memory Model，JMM）详解
java内存模型与java内存结构是不一样的（参考：java内存结构）
java虚拟机器试图定义一种java内存模型（java memory model，JMM），来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让java在各种平台下都能达到一致的并发效果。
以下转载自：http://kenwublog.com/explain-java-memory-model-in-detail
内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节.
不同平台间的处理器架构将直接影响内存模型的结构.
在C或C++中, 可以利用不同操作平台下的内存模型来编写并发程序. 但是, 这带给开发人员的是, 更高的学习成本.
相比之下, java利用了自身虚拟机的优势, 使内存模型不束缚于具体的处理器架构, 真正实现了跨平台.
(针对hotspot jvm, jrockit等不同的jvm, 内存模型也会不相同)
内存模型的特征:
a, Visibility 可视性 (多核,多线程间数据的共享)
b, Ordering 有序性 (对内存进行的操作应该是有序的)
根据Java Language Specification中的说明, jvm系统中存在一个主内存(Main Memory或Java Heap Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。其中, 工作内存里的变量, 在多核处理器下, 将大部分储存于处理器高速缓存中, 高速缓存在不经过内存时, 也是不可见的。（图2.1）
图2.1
jmm怎么体现 可视性(Visibility) ?
在jmm中, 通过并发线程修改共享变量值, 必须将线程变量同步回主存后, 其他线程才能访问到.
jmm怎么体现 有序性(Ordering) ?
通过java提供的同步机制或volatile关键字, 来保证内存的访问顺序.
缓存一致性（cache coherency）
什么是缓存一致性?
它是一种管理多处理器系统的高速缓存区结构，其可以保证数据在高速缓存区到内存的传输中不会丢失或重复。(来自wikipedia)
举例理解:
假如有一个处理器有一个更新了的变量值位于其工作内存（缓存）中，但还没有被写入主内存，这样别的处理器就可能会看不到这个更新的值。
解决缓存一致性的方法?
a, 顺序一致性模型:
要求某处理器对所改变的变量值立即进行传播, 并确保该值被所有处理器接受后, 才能继续执行其他指令.
b, 释放一致性模型: (类似jmm cache coherency)
允许处理器将改变的变量值延迟到释放锁时才进行传播.
jmm缓存一致性模型 – “happens-before ordering(先行发生排序)”
一般情况下的示例程序:
x = 0;
y = 0;
i = 0;
j = 0;
// thread A
y = 1;
x = 1;
// thread B
i = x;
j = y;在如上程序中, 如果线程A,B在无保障情况下运行, 那么i,j各会是什么值呢?
答案是, 不确定. (00,01,10,11都有可能出现)
这里没有使用java同步机制, 所以 jmm 有序性和可视性 都无法得到保障.
happens-before ordering( 先行发生排序) 如何避免这种情况?
排序原则已经做到:
a, 在程序顺序中, 线程中的每一个操作, 发生在当前操作后面将要出现的每一个操作之前.
b, 对象监视器的解锁发生在等待获取对象锁的线程之前.
c, 对volitile关键字修饰的变量写入操作, 发生在对该变量的读取之前.
d, 对一个线程的 Thread.start() 调用 发生在启动的线程中的所有操作之前.
e, 线程中的所有操作 发生在从这个线程的 Thread.join()成功返回的所有其他线程之前.
为了实现 happends-before ordering原则, java及jdk提供的工具:
a, synchronized关键字
b, volatile关键字
c, final变量
d, java.util.concurrent.locks包(since jdk 1.5)
e, java.util.concurrent.atmoic包(since jdk 1.5)
…
使用了happens-before ordering的例子:
(1) 获取对象监视器的锁(lock)
(2) 清空工作内存数据, 从主存复制变量到当前工作内存, 即同步数据 (read and load)
(3) 执行代码，改变共享变量值 (use and assign)
(4) 将工作内存数据刷回主存 (store and write)
(5) 释放对象监视器的锁 (unlock)
注意: 其中4,5两步是同时进行的.
这边最核心的就是第二步, 他同步了主内存,即前一个线程对变量改动的结果,可以被当前线程获知!(利用了happens-before ordering原则)
对比之前的例子
如果多个线程同时执行一段未经锁保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。
3. 经典j2ee设计模式Double-Checked Locking失效问题（参考：单例模式和双重检测Double-Checked-Locking）
双重检查锁定失效问题,一直是JMM无法避免的缺陷之一.了解DCL失效问题, 可以帮助我们深入JMM运行原理.
要展示DCL失效问题, 首先要理解一个重要概念- 延迟加载(lazy loading).
非单例的单线程延迟加载示例:
class Foo
{
private Resource res = null;
public Resource getResource()
{
// 普通的延迟加载
if (res == null)
res = new Resource();
return res;
}
}非单例的 多线程延迟加载示例:
Class Foo
{
Private Resource res = null;
Public synchronized Resource getResource()
{
// 获取实例操作使用同步方式, 性能不高
If (res == null) res = new Resource();
return res;
}
}非单例的 DCL多线程延迟加载示例:
Class Foo
{
Private Resource res = null;
Public Resource getResource()
{
If (res == null)
{
//只有在第一次初始化时,才使用同步方式.
synchronized(this)
{
if(res == null)
{
res = new Resource();
}
return res;
}
}Double-Checked Locking看起来是非常完美的。但是很遗憾，根据Java的语言规范，上面的代码是不可靠的。
出现上述问题, 最重要的2个原因如下:
1, 编译器优化了程序指令, 以加快cpu处理速度.
2, 多核cpu动态调整指令顺序, 以加快并行运算能力.
问题出现的顺序:
1, 线程A, 发现对象未实例化, 准备开始实例化
2, 由于编译器优化了程序指令, 允许对象在构造函数未调用完前, 将 共享变量的引用指向 部分构造的对象, 虽然对象未完全实例化, 但已经不为null了.
3, 线程B, 发现部分构造的对象已不是null, 则直接返回了该对象.
不过, 一些著名的开源框架, 包括jive,lenya等也都在使用DCL模式, 且未见一些极端异常.
说明, DCL失效问题的出现率还是比较低的.
接下来就是性能与稳定之间的选择了?
DCL的替代 Initialize-On-Demand :
public class Foo {
// 似有静态内部类, 只有当有引用时, 该类才会被装载
private static class LazyFoo {
public static Foo foo = new Foo();
}
public static Foo getInstance() {
return LazyFoo.foo;
}
}维基百科的DCL解释:
http://en.wikipedia.org/wiki/Double-checked_locking
DCL的完美解决方案:
http://www.theserverside.com/patterns/thread.tss?thread_id=39606
总结:
多线程编程, 针对有写操作的变量, 必须 保证其所有引用点与主存中数据一致(考虑采用同步或volatile) .
