标签:
Java虚拟机规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致性的并发效果。在此之前,主流程序语言直接使用物理硬件(或者说是操作系统的内存模型),因此会由于不同平台上内存模型的差异,导致程序在一套平台上并发完全正常,而在另一套平台上并发访问却经常出错。
Java内存模型的主要目标是定义程序中各个变量的访问规则,即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量包括实例字段、静态字段和构成数组对象的元素,不包括局部变量和方法参数,因为后者是线程私有的,不会被共享,自然就不存在竞争问题。
Java内存模型规定所有的变量都存储在主内存(虚拟机内存的一部分)中,每条线程还有自己的工作内存,线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝,线程对所有变量的操作都必须在工作内存中进行,而不能直接读写主内存中的变量。不同线程之间也无法访问对方工作内存中的变量,线程间变量值的传递均通过主内存来完成。线程、主内存、工作内存三者的交互关系如下图:
Java内存模型中定义了以下八种操作,来完成一个变量从主内存拷贝到工作内存、以及工作内存同步回主内存之内。
如果要把一个变量从主内存复制到工作内存,那就要按顺序地执行read和load操作,如果要把变量从工作内存同步回主内存,就要按顺序的执行store和write操作。这两个操作必须按顺序执行,但是没有保证是连续执行,也就是说read与load之间、store与write之间是可插入其他指令的。除此之外,Java内存模型还规定了在执行上述八种基本操作时必须满足如下规则:
volatile可以保证两个线程对变量操作的可见性,即一个线程操作的操作可以被另一线程看到。但是如果操作不是原子的,依然没法保证volatile同步的正确性。只有在下述情况,才可以使用这个关键字:
/**
* 基于双重判断的单例模式
*/
public class Singleton {
private volatile static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
public static void main(String[] args) {
Singleton.getInstance();
}
}
volatile还有个特性就是,可以禁止指令进行重排序优化。普通变量仅仅会保证在该方法的执行过程中所有以来复制结果的地方都能获取到正确的结果,而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。如下例子:
Map configOptions;
char [] configText;
//此变量必须定义为volatile
volatile boolean initialized = false;
//假设一下代码在线程A中执行,模拟读取配置信息,当读取完成后,将initialized设置为true来通知其他线程配置可使用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;
//假设以下代码在线程B中执行,等待initialized 为true,代表线程A已经把配置信息初始化完成
while(!initialized ){
sleep();
}
//使用线程A中初始化好的配置信息
doSomethingWithConfig();
如果initialized 没有使用volatile修饰,就可能由于指令重排的优化,导致位于线程A中的最后一句代码“initialized = true”被提前执行,这样在线程B中使用配置信息的代码就可能出现错误。
所以,volatile本身强大的地方就是他还能预防这种情况发生,虽然牺牲了一点性能,但是大大增强了程序的可靠性。但是记住,不要依赖于volatile,在合适的时候才使用他(上文已经说明),如果情况不合适,就使用传统的synchronized关键字同步共享变量的访问,用来保证程序正确性(这个关键字的性能会随着jvm不断完善而不断提升,将来性能会慢慢逼近volatile)。
Java内存模型中对volatile变量定义的特殊规则:
对于64位的数据类型(long和double),在模型中特别定义;了一条宽松的规定:允许虚拟机将没有被volatile修饰的64位数据的读写划分为两次32位的操作来进行,即允许虚拟机不保证64位数据类型的load、store、read和write这四个操作的原子性。
原子性:由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write这六个,我们可以大致的认为基本数据类型的访问读写是具备原子性的(long和double除外)。Java代码中的同步块即synchronized关键字,因此在synchronized块之间的操作也具备原子性。内部是通过字节码指令monitorenter和monitorexit来实现。
可见性:就是当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值。关键字synchronized和final也能保证可见性。首先同步块是因为对变量执行unlock操作之前,必须先把次变量同步回主内存中。而final关键字的可见性是指:被final修饰的字段在构造器中一旦被初始化完成,并且构造器没有把this指针传递出去,那么在其他线程中就能看见final字段的值。
有序性:用synchronized和volatile关键字来保证线程操作之间的有序性。volatile本省就包含禁止指令重排序的语义,而synchronized则是因为:一个变量在同一时刻只允许一条线程对齐进行lock操作。这个规则决定了持有同一个锁的两个同步块只能串行的进入。
如果Java内存模型中所有的有序性都只靠volatile和synchronized来完成,那么有一些操作将会变得很啰嗦。java内存模型中的一个重点原则——先行发生原则(Happens-Before),使用这个原则作为依据,来指导你判断是否存在线程安全和竞争问题。
接下来从下面这个例子感受一下“时间上的先后顺序”“与”“先行发生”之间有什么不同。
private int value = 0;
public void setValue(int value){
this.value = value;
}
public int getValue(){
return value;
}
假设存在线程A和B,线程A先调用setValue(1),然后线程B调用了同一个对象的getValue(),那么线程B返回的值是什么?
分析:没有同步块—管程锁定规则不适用;value没有被volatile修饰,所以volatile变量规则不适用;后面的线程启动、终止、中断规则和对象终结规则也扯不上关系,所以我们无法确定这两个线程谁先执行,因此我们说这里的操作时线程不安全的。
如何修复呢?可以为set、get方法定义为synchronized方法,这样可以使用管程锁定规则;或者把value设定为volatile变量,由于set方法对value的修改不依赖value的原值,满足volatile关键字使用场景。
线程也叫作轻量级进程,是大多现代操作系统的基本调度单位。在同一个进程中,多个线程共享内存空间,因此需要足够的同步机制才能保证正常访问。每个线程本身都有各自的程序计数器、栈和局部变量等。在java中使用线程调度的方式是抢占式的,需要由操作系统分配执行时间,线程本身无法决定(例如java中,只有Thread.yield()可以让出自己的执行时间,但是并没有提供可以主动获取执行时间的操作)。虽然java中线程调度由系统执行,但是还是可以通过设置线程优先级来“建议”操作系统多给某些线程分配执行时间(然后,这并不一定就能保证高优先级的先执行)。
Java定义了如下几种线程状态,一个线程仅处于一个状态:
标签:
原文地址:http://blog.csdn.net/chun0801/article/details/51912714