JAVA内存模型和线程安全

一.java内存模型(jmm,java memory model):

    运行时涉及到两种内存,主内存和工作区内存,其中工作区内存通常为cpu的高速缓存区用来加快内存数据读取操作的(各线程独立).所有的变量内容都存在主内存中,当需要对内存数据进行操作时，数据将会从主存中load到工作区缓存并由cpu计算和赋值操作，然后再由工作区内存write到主存中，读取时如果工作区内存中已经有(loaded)则直接使用;工作区内存保存了线程使用的变量的副本,线程不可以直接操作主内存,只能操作工作区内存,对于需要变更的变量,需要通过一系列回写指令集同步到主内存中.且工作区内存是线程独占的,主内存是线程共享的.如下为操作集:

lock:对主内存中的变量"加锁",标记为一个线程持有.如果一个变量已经被lock,其他线程尝试lock将被阻塞,同一个线程可以多次lock,不过锁的引用次数将会+1,需要unlock同样次数,才能解锁.对一个变量lock将会导致清空工作区内存中此变量的副本,即当其他线程再次使用此变量时需要重新获取.

unlock:对主内存中的变量"释放锁",释放锁的线程和持有锁的线程必须是同一个线程,无法对没有加锁的变量执行unlock.

read:由工作区内存向主内存发出"read"操作,随后必须执行load操作.

load:工作区内存中加载"read"操作指定的变量,并放入副本中.此指令需要和read保持顺序

use:变量交付给执行引擎做计算,当jvm需要使用变量时,将会使用此操作.

assign:在工作区内存中,将变量更新为某个值.一个被assign操作的变量,必须被write到主内存,如果没有被assign的变量不能被write到主内存.

store:工作区内存向主内存发出"同步"操作.

write:工作区内存将store操作指定的变量同步到主内存中.此操作需要和store保持顺序.

其中read->load,store->write指令必须按照顺序执行,即不能load一个没有被read操作指定的变量,也不能write一个没有被store操作指定的变量,不过这read + load/store + write不一定必须是连续的,其中间仍然可以有其他指令.(volatile有特例)

    volatile是java提供的轻量级变量同步机制,它确保了变量可见性,即任何一个线程修改了volatile修饰的变量,其他线程将立即可见.对于普通变量因为存在主内存和工作区内存的复制和同步,所以无法具备此特性.volatile变量存储在主内中,任何线程需要使用此变量时,必须再次read,因为其他线程对此变量的更改,将会被其他线程在使用此变量时立即获得新值.

    volatile只是保证了可见性,但是它并非线程安全,因为如果线程一旦read到此值然后进行计算,在尚未write到主内存时其他线程也做了同样的操作,那么volatile变量的最终结果将无法达到预期..如果期望volatile变量线程安全,必须同步或者cas.volatile变量操作时,read->load->use三个操作是连续的,assign->store->write三个操作是连续的.

    通常volatile用在“值”类型上，引用类型也有用到，如filterinputstream里的volatile inputstream in。volatile修饰的变量如果是对象或数组之类的，其含义是对象或数组的地址具有可见性，但是对象或数组内部的成员改变不具有可见性。

二.线程安全

    线程是执行任务的最小调度单元,内核线程是os创建和管理的线程,它将有内核完成线程的切换以及调度(cpu调度).任何一个java线程都对应一个内核线程,即java线程的所有特性都基于内核并受制于内核.在linux和windows系统中,一个java线程就是底层的一个内核线程.java对线程的调度基于内核,在主流的系统中,广泛采用了"抢占式"调度机制,即线程都以"争抢cpu资源"的姿态来运行,最终被运行的线程将有内核的调度算法来决定,如果线程没有获得运行资源,那么线程将被"暂停".."协同式"调度已经不适合多线程(进程)的系统,它表现为线程之间互相"谦让",如果一个线程获得运行资源,那么它将一直运行下去直到结束,如果一个线程是"长时间"的,那么极有可能这个线程将独占一个cpu,而其他线程无法获得资源..

   线程状态:

new:新创建线程,尚未开启.

runnable:当前线程已经被启动或者正在被运行,处于此状态的线程标明即将或者已经得到了运行资源.

waiting:如果线程因为wait()/join()/locksupport.park(this)/sleep()导致当前线程无法继续执行或者获得资源.

blocked:如果当前线程因为对象锁获取时,被"阻塞",那么线程将处于blocked状态,此状态下,线程不会释放资源.

terminated:线程执行结束,资源即将被回收.

    在java中(甚至任何语言或者平台中)确保线程安全的方式,无外乎"同步锁"和"cas","同步锁"是一种粗暴而严格的同步手段,它强制对资源的访问必须队列化,一个资源在任何时候只能有一个线程可访问.在java中"synchronized"修饰词可以用来同步方法的调用,synchronized可以指定需要同步的对象,如果 没有指定,默认为当前对象,如果是static方法,则表示对class同步.synchronized关键词在编译之后,最终会生成2个指令:monitorenter和monitorexit,执行引擎如果遇到monitorenter指令,将会尝试获取对象锁,如果获取成功,则锁计数器+1,同时工作区中的对象值将视为无效，重新从主存中load；monitorexit将导致锁计数器-1，即释放锁，此时将会把对象值从工作区缓存中write到主存中;如果计数器为0,则表示此对象没有被任何线程加锁.如果获取锁失败,当前线程阻塞.此外synchronized本身具有"重入性"语义,如果此对象上的monitor是当前线程,那么锁获取操作将直接成功.

   我们不再争论synchronized锁和reentrantlock api锁谁更优秀,这一把双刃剑,性能方面两者在普通情况下(即无复杂递深的lock调用或者多层synchronized)性能几乎差不多,synchronized稍微优秀一些.但是reentrantlock提供了多样化的控制以及condition机制,可以帮助我们有效的控制并发环境中,让线程遵循条件的阻塞和唤醒;例如blockingqueue的实现机制.

    cas(compare and swap),设计方式上更像一种"乐观锁",通过"比较"-"更新"这种无阻塞的手段实现数据在多线程下的"安全性".在java中cas操作遍布atomic包下的api中,底层使用一个闭源的unsafe.compareandswapint(object,valueoffset,expect,update),其中需要告知对象的内存地址.cas会出现一个有趣的问题,就是aba,即a变量被更改为b之后,再次被更改为a,此时对于持有a数据的线程尝试更改值是可以成功了,就像b值从来就没有出现过一样..其实吧,这个问题不是问题,既然有线程把数据更改为a,那么后续的线程操作就应该遵守现在的结果,而无需关注过去的过程.

三、补充

java线程之间的通信由java内存模型（jmm）控制，jmm决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，jmm定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory，或叫工作区内存），本地内存中存储了该线程以读/写共享变量的副本。本地内存是jmm的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。

1.1 可见性

也就说假设一个对象中有一个变量i，那么i是保存在main memory中的，当某一个线程要操作i的时候，首先需要从main memory中将i 加载到这个线程的working memory中，这个时候working memory中就有了一个i的拷贝，这个时候此线程对i的修改都在其working memory中，直到其将i从working memory写回到main memory中，新的i的值才能被其他线程所读取。从某个意义上说，可见性保证了各个线程的working memory的数据的一致性。

可见性遵循下面一些规则：

当一个线程第一次读取某个变量的时候，会从main memory中读取最新的；

当一个线程运行结束的时候，所有写的变量都会被flush回main memory中；

当一个线程释放锁后，所有的变量的变化都会flush到main memory中，然后一个使用了这个相同的同步锁的进程，将会重新加载所有的使用到的变量，这样就保证了可见性;

volatile的变量会被立刻写到main memory中，读则重新加载。

1.2 原子性

还拿上面的例子来说，原子性就是当某一个线程修改i的值的时候，从取出i到将新的i的值写给i之间不能有其他线程对i进行任何操作。也就是说保证某个线程对i的操作是原子性的，这样就可以避免数据脏读。

通过锁机制或者cas（compare and set 需要硬件cpu的支持）操作可以保证操作的原子性。

1.3 有序性

假设在main memory中存在两个变量i和j，初始值都为0，在某个线程a的代码中依次对i和j进行自增操作（i，j的操作不相互依赖），

i++;

j++;

由于，所以i,j修改操作的顺序可能会被重新排序。那么修改后的ij写到main memory中的时候，顺序可能就不是按照i，j的顺序了，这就是所谓的reordering，在单线程的情况下，当线程a运行结束的后i，j的值都加1了，在线程自己看来就好像是线程按照代码的顺序进行了运行（这些操作都是基于as-if-serial语义的），即使在实际运行过程中，i，j的自增可能被重新排序了，当然计算机也不能帮你乱排序，存在上下逻辑关联的运行顺序肯定还是不会变的。但是在多线程环境下，问题就不一样了，比如另一个线程b的代码如下

if(j==1) {

    system.out.println(i);

}

按照我们的思维方式，当j为1的时候那么i肯定也是1，因为代码中i在j之前就自增了，但实际的情况有可能当j为1的时候i还是为0。这就是reordering产生的不好的后果，所以我们在某些时候为了避免这样的问题需要一些必要的策略，以保证多个线程一起工作的时候也存在一定的次序。jmm提供了happens-before 的排序策略。

通过对以上知识的理解，我们应该深刻认识到线程安全问题的敏感性了，无论是get还是set，都要严谨的考虑线程安全问题，并且在get的地方考虑能否用volatile代替同步锁。

原文链接：[http://wely.iteye.com/blog/2228828]