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