java 内存模型、多线程

 

文档来源： <http://www.iteye.com/topic/108927 >


本文参照Java Language Specific对原文做了部分修改。

1. 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.

V olatile 变量只放到主存，不会被拷贝到线程缓存， 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) ，工作内存由缓存 和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量 的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的 变量。

 

 

2. 内存模型的特征:

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

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

         在jmm中, 通过并发线程修改变量值, 必须将线程变量同步回主存后, 其它线程才能访问到.

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

        jmm怎么体现 有序性(Ordering) ?

        通过java提供的同步机制或volatile关键字, 来保证内存的访问顺序.

3 . 缓存一致性（cache coherency）

    什么是缓存一致性?

    它是一种管理多处理器系统的高速缓存区结构，其可以保证数据在高速缓存区到内存的传输中不会丢失 或重复。(来自wikipedia )

    举例理解:

    假如有一个处理器有一个更新了的变量值位于其缓存中，但还没有被写入主内存，这样别的处理器就可 能会看不到这个更新的值.

    解决缓存一致性的方法?

    a . 顺序一致性模型:

        要求某处理器对所改变的变量值立即进行传播, 并确保该值被所有处理器接受后, 才能继续执行其他 指令.

 

    b . 释放一致性模型: (类似jmm cache coherency)

        允许处理器将改变的变量值延迟到释放锁时才进行传播 .

jmm缓存一致性模型 - "happens-before ordering(先行发生排序)"

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.Single ThreadModel.

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

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

 

 

 

 

 

经典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