线程安全、volatile关键字、原子 性
线程安全
线程安全
如果有多个线程在同时运行,而这些线程可能会同时运行这段代码。程序每次运行结果和单线程运行的 结果是一样的,而且其他的变量的值也和预期的是一样的,就是线程安全的。
我们通过一个案例,演示线程的安全问题:
电影院要卖票,我们模拟电影院的卖票过程。假设要播放的电影是 “葫芦娃大战奥特曼”,本次电影的座 位共100个(本场电影只能卖100张票)。
我们来模拟电影院的售票窗口,实现多个窗口同时卖 “葫芦娃大战奥特曼”这场电影票(多个窗口一起卖这 100张票) 需要窗口,采用线程对象来模拟;需要票,Runnable接口子类来模拟
发现程序出现了两个问题:
- 相同的票数,比如5这张票被卖了两回。
- 不存在的票,比如0票与-1票,是不存在的。
若每个线程中对全局变量、静态变量只有读操作,而无写操作,
一般来说,这个全局变量是线程安全的;
若有多个线程同时执行写操作,一般 都需要考虑线程同步,否则的话就可能影响线程安全。
线程同步
线程同步是为了解决线程安全问题。
当我们使用多个线程访问同一资源的时候,且多个线程中对资源有写的操作,就容易出现线程安全问 题。
要解决上述多线程并发访问一个资源的安全性问题:也就是解决重复票与不存在票问题,Java中提供了同 步机制(synchronized)来解决。
窗口1线程进入操作的时候,窗口2和窗口3线程只能在外等着,
窗口1操作结束,窗口1和窗口2和窗口3才有机 会进入代码去执行。
也就是说在某个线程修改共享资源的时候,其他线程不能修改该资源,
等待修改完毕同步 之后,才能去抢夺CPU资源,完成对应的操作
保证了数据的同步性,解决了线程不安全的现象
为了保证每个线程都能正常执行原子操作,Java引入了线程同步机制。
那么怎么去使用呢?有三种方式完成同步操作:
1. 同步代码块。
2. 同步方法。
3. 锁机制。
同步代码块
同步代码块: synchronized 关键字可以用于方法中的某个区块中,表示只对这个区块的资源实行 互斥访问。
synchronized(同步锁){
需要同步操作的代码
}
同步锁:
对象的同步锁只是一个概念,可以想象为在对象上标记了一个锁. 1. 锁对象 可以是任意类型。 2. 多个线程对象 要使用同一把锁。
注意:在任何时候,多允许一个线程拥有同步锁,谁拿到锁就进入代码块,其他的线程只能在外等着 (BLOCKED)。
使用同步代码块解决代码:
当使用了同步代码块后,上述的线程的安全问题,解决了
同步方法 synchronized
同步方法:使用synchronized修饰的方法,就叫做同步方法,保证A线程执行该方法的时候,其他线程只 能在方法外等着。
public synchronized void method(){
可能会产生线程安全问题的代码
}
同步锁是谁? 对于非static方法,同步锁就是this。 对于static方法,我们使用当前方法所在类的字节码对象(类名.class)。
使用同步方法代码如下:
public class Ticket implements Runnable{
private int ticket = 100;
/*
* 执行卖票操作
* */
@Override public void run() {
//每个窗口卖票的操作
//窗口 永远开启
while(true){
sellTicket();
}
}
/*
* 锁对象 是 谁调用这个方法 就是谁
* 隐含 锁对象 就是 this
*/
public synchronized void sellTicket(){
if(ticket>0){//有票 可以卖
//出票操作
//使用sleep模拟一下出票时间
try {
Thread.sleep(100);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//获取当前线程对象的名字
String name = Thread.currentThread().getName();
System.out.println(name+"正在卖:"+ticket--);
}
}
}
Lock锁
java.util.concurrent.locks.Lock 机制提供了比synchronized代码块和synchronized方法更广 泛的锁定操作,同步代码块/同步方法具有的功能Lock都有,除此之外更强大
Lock锁也称同步锁,加锁与释放锁方法化了,如下:
- public void lock() :加同步锁。
- public void unlock() :释放同步锁。
使用如下
public class Ticket implements Runnable{
private int ticket = 100;
Lock lock = new ReentrantLock();
/* * 执行卖票操作 */
@Override
public void run() {
//每个窗口卖票的操作
//窗口 永远开启
while(true){
lock.lock();
if(ticket>0){//有票 可以卖
//出票操作
//使用sleep模拟一下出票时间
try {
Thread.sleep(50);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//获取当前线程对象的名字
String name = Thread.currentThread().getName();
System.out.println(name+"正在卖:"+ticket--);
}
lock.unlock();
}
}
}
volatile关键字
public class VolatileThread extends Thread {
// 定义成员变量
private boolean flag = false ;
public boolean isFlag() {
return flag;
}
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 将flag的值更改为true
this.flag = true ;
System.out.println("flag=" + flag);
}
}
public class VolatileThreadDemo {// 测试类
public static void main(String[] args) {
// 创建VolatileThread线程对象
VolatileThread volatileThread = new VolatileThread() ;
volatileThread.start();
// main方法
while(true) {
if(volatileThread.isFlag()) {
System.out.println("执行了======");
}
}
}
}
我们看到,VolatileThread线程中已经将flag设置为true,但main()方法中始终没有读到,从而没有打印。
JMM
概述:JMM(Java Memory Model)Java内存模型,是java虚拟机规范中所定义的一种内存模型。
Java内存模型(Java Memory Model)描述了Java程序中各种变量(线程共享变量)的访问规则,以及在JVM 中将变量存储到内存和从内存中读取变量这样的底层细节。
所有的共享变量都存储于主内存。这里所说的变量指的是实例变量和类变量。不包含局部变量,因为局 部变量是线程私有的,因此不存在竞争问题。每一个线程还存在自己的工作内存,线程的工作内存,保留了被线程使用的变量的工作副本。线程对变量的所有的操作(读,取)都必须在工作内 存中完成,而不能直接读写主内存中的变量,不同线程之间也不能直接访问对方工作内存中的变量,线程间变量的值的传递需要通过主内存完成。
问题处理
加锁
某一个线程进入synchronized代码块前后,执行过程入如下:
a.线程获得锁
b.清空工作内存
c.从主内存拷贝共享变量新的值到工作内存成为副本
d.执行代码
e.将修改后的副本的值刷新回主内存中 f.线程释放锁
volatile关键字
private volatile boolean flag ;
工作原理
volatile与synchronized
volatile只能修饰实例变量和类变量,而synchronized可以修饰方法,以及代码块。
volatile保证数据的可见性,但是不保证原子性(多线程进行写操作,不保证线程安全);
而 synchronized是一种排他(互斥)的机制,
原子性
概述:所谓的原子性是指在一次操作或者多次操作中,要么所有的操作全部都得到了执行并且不会受到 任何因素的干扰而中断,要么所有的操作都不执行,
多个操作是一个不可以分割的整体。
比如:从张三的账户给李四的账户转1000元,这个动作将包含两个基本的操作:从张三的账户扣除 1000元,给李四的账户增加1000元。这两个操作必须符合原子性的要求,
要么都成功要么都失败。
问题及原理说明
以上问题主要是发生在count++操作上:
count++操作包含3个步骤:
从主内存中读取数据到工作内存 对工作内存中的数据进行++操作 将工作内存中的数据写回到主内存
count++操作不是一个原子性操作,也就是说在某一个时刻对某一个操作的执行,有可能被其他的线程 打断。
- 假设此时x的值是100,线程A需要对改变量进行自增1的操作,首先它需要从主内存中读取变量x的 值。由于CPU的切换关系,此时CPU的执行权被切换到了 B线程。A线程就处于就绪状态,B线程处于运行状态
- 线程B也需要从主内存中读取x变量的值,由于线程A没有对x值做任何修改因此此时B读取到的数据还 是100
- 线程B工作内存中x执行了+1操作,但是未刷新之主内存中
- 此时CPU的执行权切换到了A线程上,由于此时线程B没有将工作内存中的数据刷新到主内存,因此 A线程工作内存中的变量值还是100,没有失效。A线程对工作内存中的数据进行了+1操作
- 线程B将101写入到主内存
- 线程A将101写入到主内存 虽然计算了2次,但是只对A进行了1次修改。
虽然计算了2次,但是只对A进行了1次修改。
volatile原子性测试
代码测试
小结:在多线程环境下,volatile关键字可以保证共享数据的可见性,但是并不能保证对数据操作的原 子性(在多线程环境下volatile修饰的变量也是线程不安全的)。
// 定义一个int类型的变量
private volatile int count = 0 ;
在多线程环境下,要保证数据的安全性,我们还需要使用锁机制。
volatile的使用场景
- 开关控制
利用可见性特点,控制某一段代码执行或者关闭(比如今天课程的第一个案例)。 - 多个线程操作共享变量,但是是有一个线程对其进行写操作,其他的线程都是读
问题解决
使用锁机制
我们可以给count++操作添加锁,那么count++操作就是临界区的代码,临界区只能有一个线程去执 行,所以count++就变成了原子操作。
原子类
概述:java从JDK1.5开始提供了java.util.concurrent.atomic包(简称Atomic包),这个包中的原子操作类 提供了一种用法简单,性能高效,线程安全地更新一个变量的方式。
AtomicInteger
原子型Integer,可以实现原子更新操作
public AtomicInteger(): | 初始化一个默认值为0的原子型Integer |
public AtomicInteger(int initialValue): | 初始化一个指定值的原子型Integer |
int get(): | 获取值 |
int getAndIncrement(): | 以原子方式将当前值加1,注意,这里返回的是自增前 的值。 |
int incrementAndGet(): | 以原子方式将当前值加1,注意,这里返回的是自增后 的值。 |
int addAndGet(int data): | 以原子方式将输入的数值与实例中的值 (AtomicInteger里的value)相加,并返回结果。 |
int getAndSet(int value): | 以原子方式设置为newValue的值,并返回旧值。 |
案例改造
使用AtomicInteger对案例进行改造.
原子类CAS机制
CAS的全成是: Compare And Swap(比较再交换); 是现代CPU广泛支持的一种对内存中的共享数据进行 操作的一种特殊指令。CAS可以将read-modify-write
转换为原子操作,这个原子操作直接由处理器保证。
CAS机制当中使用了3个基本操作数:内存地址V,旧的预期值A,要修改的新值B。
举例:
- 在内存地址V当中,存储着值为10的变量。
- 此时线程1想要把变量的值增加1。对线程1来说,旧的预期值A=10,要修改的新值B=11。
3. 在线程1要提交更新之前,另一个线程2抢先一步,把内存地址V中的变量值率先更新成了11。
4. 线程1开始提交更新,首先进行A和地址V的实际值比较(Compare),发现A不等于V的实际值, 提交失败。
5. 线程1重新获取内存地址V的当前值,并重新计算想要修改的新值。此时对线程1来说,A=11, B=12。这个重新尝试的过程被称为自旋。
6. 这一次比较幸运,没有其他线程改变地址V的值。线程1进行Compare,发现A和地址V的实际值是 相等的。
7. 线程1进行SWAP,把地址V的值替换为B,也就是12。
CAS与Synchronized
CAS和Synchronized都可以保证多线程环境下共享数据的安全性。那么他们两者有什么区别? Synchronized是从悲观的角度出发:
总是假设坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这 样别人想拿这个数据就会阻塞直到它拿到锁
(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程)。因此 Synchronized我们也将其称之为悲观锁。jdk中的ReentrantLock也是一种悲观锁。 CAS是从乐观的角度出发:
总是假设好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会 判断一下在此期间别人有没有去更新这个数据。
CAS这种机制我们也可以将其称之为乐观锁。