juc包下的所有类都是提供多线程并发编程用的,不仅满足线程安全而且效率也很高
ReentranLock是可重入锁,具体用法:
Lock lock = new ReentrantLock();
try{
lock.lock(); //锁对象加锁,只有一个线程获取到锁
//需要保证线程安全的代码
}finally{
lock.unlock(); //不管是否出现异常都需要释放锁
}
lock提供了更多获取锁的方式:
🍬synchronized与lock的区别:
🍂synchronized是一个关键字在JVM内部实现的,lock是标准库的一个类在JVM外部实现 🍂语法上看,sychronized是自动加锁与释放锁,lock是手动的加锁与释放锁,相对lock比较灵活,但需要保证不管是否发生异常都需要释放锁 🍂lock获取锁的方式相对更加丰富,提供了多种api 🍂从效率上看,当线程冲突严重时,lock性能要高很多
🍖线程冲突严重时lock性能高的原因:
synchronized在释放锁以后,之前因为申请锁失败而阻塞的线程,都会再次竞争 lock是基于aqs来实现,aqs是一个双端队列专门用来管理线程的状态,竞争失败的线程就入队列并设置状态,释放锁后把队列中的线程引用拿出来并设置状态(获取到锁)
🍬如何选择使用哪个锁呢?
🍃当锁竞争不激烈的时候,使用synchronized效率高,自动释放更方便 🍃当锁竞争激烈的时候,使用lock,搭配tryLock更灵活控制加锁的行为,而不是死等 🍃需要使用公平锁的时候使用lock,lock默认是非公平的锁,但可以通过构造方法传入true开启公平模式(后面在锁策略中介绍)
悲观锁: 大部分时间来看,都是存在线程冲突的(悲观的看待问题),每次拿数据的时候都认为会修改,所以每次拿数据的时候都先加锁,完成执行操作后再释放锁
乐观锁: 大部分时间来看,是不存在线程冲突的(乐观的看待问题),每次都直接执行修改数据的操作,在数据提交更新的结果时,才会检测是否产生并发冲突,返回是否修改成功的结果,让程序自行处理逻辑
🍖乐观锁最重要的就是检测出是否发生线程冲突,这里引入一个版本号(version)解决:
主存中有变量和一个版本号,两个线程同时将主存中的信息读到各自的寄存器中,然后进行修改,线程1先修改然后往主存中写,然后对比版本号,相同的话version++,当线程2执行相同操作时发现版本号不相同,就写入失败
具体过程如下图:
乐观锁从Java层面来看是无锁操作,直接修改共享变量 返回true,修改成功 返回false,修改失败
线程在竞争锁失败的时候会进入阻塞状态,放弃CPU,需要过很久才能被再次调度,但是实际上,虽然当前竞争锁失败但是没有过多久就竞争到锁,没必要放弃CPU,这个时候就可以使用自旋锁来解决这种情况
自旋锁实际也是Java层面的无锁操作
while(true){
boolean result = 乐观锁方式修改数据;
if(result) break;
}
说明: 如果获取锁失败,就立即在尝试获取锁,无限循环直到获取到锁,一旦其他线程释放锁,就能第一时间获取到锁
如果满足乐观锁的使用条件:冲突概率比较小,如果发生冲突也能够很快的得到执行 一般来说乐观锁都考虑结合自旋锁来操作
多个线程在数据读取时不会存在线程安全问题,但多个线程的写与读和写需要进行加锁,如果这两种场景下都用同一个锁就会产生很大的性能损耗,所以就要使用读写锁 读写锁就是对读和写操作区分对待,Java标准库中提供了ReentrantReadWriteLock类,实现了读写锁 ReentrantReadWriteLock.ReadLock表示一个读锁,提供了lock/unlock方法进行加锁释放锁 ReentrantReadWriteLock.WriteLock表示一个写锁,提供了lock/unlock方法进行加锁释放锁
关于读写锁:
🍁读与读之间不互斥 🍁写与写之间互斥 🍁读与写之间互斥
🍬读写锁适用频繁读,不频繁写的场景中
重量级锁: 加锁机制重度依赖OS提供的mutex 大量的内核态与用户态切换 容易引发线程的调度 操作成本高
轻量级锁: 加锁机制尽可能不用mutex,而是尽量在用户态代码完成 少量的内核态与用户态切换 不太容易引发线程调度 操作成本相对低
非公平锁:不以申请锁的时间先后顺序来获取到锁 缺陷:可能出现线程饥饿现象 优点:效率更高
公平锁:以申请锁的时间先后顺序来获取到锁
🍂synchronized是非公平锁,因为多个线程之间申请锁是竞争关系,不存在时间先后顺序 🍂lock默认下是非公平锁,但可以修改构造方法的参数来启用公平锁
可重入锁: 同一个线程可以重复申请到同一个对象的锁 不可重入锁: 同一个线程不可以重复申请到同一个对象的锁
Java中,只要以Reentrant开头命名的锁都是可重入锁,lock实现类,synchronized关键字锁都是可重入锁
CAS全称Compared And Swap(比较并交换),是jdk提供的一种乐观锁的实现,能够满足线程安全,以乐观锁的方式修改变量
比较并交换(比较,+1,交换)为一条CAS指令,是线程安全的
此处所谓的CAS指的是CPU提供了一个单独的CAS指令,通过这个指令可以完成比较并交换的过程
🍬CAS操作步骤:
🍀从主存拿值读取到自己的工作内存中,记为值A,执行修改操作后,值为B,主存的最新值记为C 🍀将B写入主存时比较A与主存的最新值C是否相等 🍀相等就写入成功,不相等就写入失败 🍀返回修改操作的结果
画图说明如下:
jdk提供了一个Unsafe的类,来执行cas的操作
jdk中unsafe提供的cas方法,是基于操作系统提供的cas方法,又是基于CPU提供的cas硬件支持,且CPU使用了lock加锁
简单说,Unsafe是基于操作系统和CPU提供的cas来实现的
Java的java.util.concurrent.atomic包下都是使用了cas来保证线程安全的,例如:++,--,!flag
原因: ++,--,!flag这种操作执行速度非常快,很快能得到执行,使用cas+自旋锁效率更高
既能够保证线程安全又能够比synchronized高效,因为不涉及竞争锁的竞争,线程要等待
典型的就是AtomicInteger类:
🍂addAndGet(int delta) i += delta 🍂decrementAndGet() --i 🍂getAndDecrement() i-- 🍂incrementAndGet() ++i 🍂getAndIncrement() i++
👁🗨️例如:执行1000次n++和n--操作看结果
import java.util.concurrent.atomic.AtomicInteger;
public class AutoInt {
//共享变量n初始值为0
private static AtomicInteger n = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0;i < 1000;i++){
n.getAndIncrement(); //1000次n++;
}
}
});
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0;i < 1000;i++) {
n.getAndDecrement(); //1000次n--
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(n);
}
}
结果:打印结果为0
在没有引入版本号的情况下,CAS是基于变量的值,在读和写的时候比较的,但这个时候会存在下面的一个问题:
从中发现,如果在当前线程写入值进行比较的时候,如果有其他线程对主存中的的值进行修改,修改为当前线程从主存读取的值的时候,当前线程仍然能写入成功,但是存在线程安全问题
🍖ABA问题的解决?
引入版本号,线程每次修改共享变量的时候版本号+1,比较的时候比较读和写时候版本号是否相同,相同的话写入成功,否则写入失败 jdk中,提供了一个AtomicStampedReferenceE>的类,这个类可以对某个类进行包装,在其内部就提供了版本号的管理
synchronized是基于对象头加锁,实现线程间的同步互斥 同步互斥:对同一个对象进行加锁的多个线程,同一个时间只有一个线程获取到锁,相当于多个线程获取锁执行同步代码是互斥的
🍬synchronized加锁操作,,只涉及对象头状态升级能升级不能降级,升级的过程:
无锁 偏向锁 轻量级锁 重量级锁
偏向锁:第一次进入的线程,或是这个线程再次申请同一个对象锁
偏向锁不是真的 "加锁", 只是给对象头中做一个 "偏向锁的标记", 记录这个锁属于哪个线程.如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)如果后续其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态
轻量级锁:随着其他线程的竞争进入轻量级锁状态,CAS+(自适应的)自旋锁
自适应:自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源,因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了,也就是所谓的 "自适应"
重量级锁:竞争锁进一步激烈,就会升级为重量级锁(使用操作系统mutex加锁)
锁消除,前提:变量只有一个线程可以操作
比如这段代码:
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");
此时每个 append 的调用都会涉及加锁和解锁,但如果只是在单线程中执行这个代码, 那么这些加 锁解锁操作是没有必要的, 白白浪费了一些资源开销
锁粗化,前提:变量是多个线程可以使用,,但是一个线程出现多次连续sychronized加锁