产品经理新视线

内存模型 (memory model)

内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节.

不同平台间的处理器架构将直接影响内存模型的结构.

在C或C++中, 可以利用不同操作平台下的内存模型来编写并发程序. 但是, 这带给开发人员的是, 更高的学习成本.
相比之下, java利用了自身虚拟机的优势, 使内存模型不束缚于具体的处理器架构, 真正实现了跨平台.
(针对hotspot jvm, jrockit等不同的jvm, 内存模型也会不相同)

内存模型的特征:
a, Visibility 可视性 (多核,多线程间数据的共享)
b, Ordering 有序性 (对内存进行的操作应该是有序的)

• java 内存模型 ( java memory model )

All instance fields, static fields and array elements are stored in heap memory . Local variables ( §14.4) , formal method parameters ( §8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model.

Fields declared final are initialized once , but never changed under normal circumstances.

Volatile 变量只放到主存，不会被拷贝到线程缓存， volatile运算存在脏数据问题， volatile仅仅能保证变量可见性 （都在主存中）, 无法保证原子性（多线程操作会出现不一致性） java.util.concurrent.atomic 包提供了基于 volatile 变量的原子操作实现同步 。

Java的内存模型JMM（Java Memory Model ） JMM 主要是为了规定了线程和内存之间的一些关系。根据 JMM 的 设计，系统存在一个主内存 (Main Memory or Heapmemory) ， Java 中所有 实例变量、静态变量、数组元素 都储存在主存 中（All instance fields, static fields and array elements are stored in heap memory），对于所有线程都是共享的。每条线程都有自己的工作内存 (Working Memory) ，工作内存由缓存 和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量 的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的 变量。

根据Java Language Specification中的说明, jvm系统中存在一个主内存(Main Memory或Java Heap Memory)【囧  现在才搞清楚 原来堆就是主存 一直含糊不清，看样子要看下 java Language Specification了】，Java中所有变量都储存在主存中，对于所有线程都是共享的。

每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。

其中, 工作内存里的变量, 在多核处理器下, 将大部分储存于处理器高速缓存中, 高速缓存在不经过内存时, 也是不可见的.

Other specification about JMM:

JMM中，把内存和CPU缓存及寄存器，分成两个部分：

1. 主存储空间 Main Memory

2. 工作空间    Working Memory

Main Memory就是机器的Memory，是对象状态最终的存储地。Working Memory，主要是寄存器和CPU缓存，是运算过程中对象状态的临时存储地。

在多CPU的情况下，如上图，有两个CPU，这时，就有一个Main Memory，两个Working Memory。当两个线程同时操作一个对象时，比如Object1，在某个时刻Object1的状态就会存在三份。

JMM提供一些规则，使多份状态保持同步，或者如何选择一个作为最终的状态。

• 内存模型的特征:

a . Visibility 可视性 (多核,多线程间数据的共享）

jmm怎么体现 可视性(Visibility) ?

在jmm中, 通过并发线程修改变量值, 必须【是程序员手动的？还是JVM自己控制？】将线程变量同步回主存后, 其它线程才能访问到.

b . Ordering 有序性 (对内存进行的操作应该是有序的

【为什么要有序？：我的理解  就是类似操作系统中的  对临界区的访问要有原子性。不能多个同时 不然很容易出问题。】）

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关键字 （变量只放到主存，不会放到各线程缓存中）

（ http://soft6.com/tech/9/92017.html ）

volatile, 用更低的代价替代同步，同步的代价, 主要由其覆盖范围决定, 如果可以降低同步的覆盖范围, 则可 以大幅提升程序性能.而volatile的覆盖范围仅仅变量级别的. 因此它的同步代价很低。volatile的语义, 其实是告诉 处理器, 不要将我放入工作内存, 请直接在主存操作我.(工作内存详见java内存模型)因此, 当多核或多线程在访问该 变量时, 都将直接操作主存, 这从本质上, 做到了变量共享.但volatile运算存在脏数据问题， volatile仅仅能保证变 量可见性（都在主存中）, 无法保证原子性（多线程操作会出现不一致性） java.util.concurrent.atomic 包提供了 基于 volatile 变量的原子操作实现同步 。CPU原语-比较并交换(CompareAndSet， CAS ),实现非阻塞算法，

要实现 volatile 的原子性可以使用下列方法：同步（得不偿失）或使用硬件原语(CAS，通过条件存储指令等，各个 CPU 规范不同), 实现非阻塞算法，CAS 操作包含三个操作数 —— 内存位置(V)、预期原值(A)和新值(B)，

CAS 原理:我认为位置 V 应该包含值 A;如果包含该值，则将 B 放到这个位置;否则，不要更改该位置，只告诉我这个 位置现在的值即可。java.util.concurrent.atomic使用第二种方案。

c, final变量（只实例化一次永不改变，各线程只拷贝一次主存 final 变量， System. out,System.in,System.error 比较 特殊，看 java 语言规范）
d, java.util.concurrent.locks包(since jdk 1.5)
e, java.util.concurrent.atmoic包(since jdk 1.5)

f. SingleThreadModel (Servlet 不再建议使用，因为 Servlet 本身多线程，实现该接口意味着每次都会实例化一 个新的 Servlet 来处理请求，而不是多线程使用同一 Servlet 。 )

…

使用了happens-before ordering的例子:

(1) 获取对象监视器的锁(lock)

(2) 清空工作内存数据, 从主存复制变量到当前工作内存, 即同步数据 (read and load)

(3) 执行代码，改变共享变量值 (use and assign)

(4) 将工作内存数据刷回主存 (store and write)

(5) 释放对象监视器的锁 (unlock)

注意: 其中4,5两步是同时进行的.

这边最核心的就是第二步, 他同步了主内存,即前一个线程对变量改动的结果,可以被当前线程获知!(利用了happens-before ordering原则)

对比之前的例子
如果多个线程同时执行一段未经锁保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。

总结:

实现多线程方式：

1. synchronized

2.volatile （见上面说明）

3.final 变量

4. java.util.concurrent.locks 包

5.java .util.current.atmoic 包

6.SingleThreadModel.

多线程编程, 针对有写操作的变量, 必须保证其所有引用点与主存中数据一致(考虑采用同步)为了达到更大的吞吐量 及线程的安全性，尽量少使用或不使用主存变量（主要是实例变量），

在不得已要使用的情况下要考虑同步策略 .

经典j2ee设计模式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) .