Volatile关键字详解,以及需要注意的地方
2016-03-15 17:04
435 查看
简介
volatile关键字保证了在多线程环境下,被修饰的变量在别的线程修改后马上同步到主存,这样线程对变量的修改对其它线程就是可见的,其它线程能够马上读到这个修改后的值。Thread的本地内存
每个Thread都拥有自己的线程存储空间Threadh是同步本地存户空间的数据到主存是不确定的。
上图表示两个线程并发执行,而且代码顺序上为Thread1 -> Thread2
1.不用 volatile
假如ready字段不使用volatile,那么Thread 1对ready做出的修改对于Thread2来说未必是可见的,是否可见是不确定的.假如此时thread1 ready泄露了(leak through)了,那么Thread 2可以看见ready为true,但是有可能answer的改变并没有泄露,则thread2有可能会输出 0 (answer=42对thread2并不可见)
2.使用 volatile
使用volatile以后,做了如下事情
每次修改volatile变量都会同步到主存中 每次读取volatile变量的值都强制从主存读取最新的值(强制JVM不可优化volatile变量,如JVM优化后变量读取会使用cpu缓存而不从主存中读取) 线程 A 中写入 volatile 变量之前可见的变量, 在线程 B 中读取该 volatile 变量以后, 线程 B 对其他在 A 中的可见变量也可见. 换句话说, 写 volatile 类似于退出同步块, 而读取 volatile 类似于进入同步块
所以如果使用了volatile,那么Thread2读取到的值为read=>true,answer=>42,当然使用volatile的同时也会增加性能开销
注意
volatile并不能保证非源自性操作的多线程安全问题得到解决,volatile解决的是多线程间共享变量的可见性问题,而例如多线程的i++,++i,依然还是会存在多线程问题,它是无法解决了.如下:使用一个线程i++,另一个i–,最终得到的结果不为0volatile解决了线程间共享变量的可见性问题 使用volatile会增加性能开销 volatile并不能解决线程同步问题 解决i++或者++i这样的线程同步问题需要使用synchronized或者AtomicXX系列的包装类,同时也会增加性能开销
相关文章推荐
- Object详解
- 修改mongodb oplog size
- 20160314作业
- 修改mongodb oplog size
- Redux API之bindActionCreators
- RHCS(维护篇)
- nginx的location配置详解
- 如何通过远程连接服务器上的MySQL
- Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift
- 减法 (苏州大学计算机学院三月月赛暨蓝桥杯热身赛)
- 清空svn的队列
- C++之多态性与虚函数
- Selenium_获取相对坐标
- keepalived配置文件详解
- SpringIoc BeanDefinition载入交互过程
- 利用memcache来保存tomcat的session会话
- MongoDB:Replica Set 之操作日志 Oplog
- MongoDB:Replica Set 之操作日志 Oplog
- JNI(Java Native Interface)
- HTML