1. 常见锁战略
加锁过程中,处理冲突的过程中,涉及到一些差别的处理方式。
1.1 乐观锁和悲观锁
- 乐观锁:在加锁之前,预估当前出现锁冲突的概率不大,因此在举行加锁的时间就不会做太多的工作,加锁的过程中做的事情比较少,加锁的速度比较快,但是更容易引入一些其他的题目,可能会消耗更多的cpu资源。
- 悲观锁:在加锁之前,预估当前锁冲突出现的概率比较大,因此在加锁的时间做更多的工作,做的事情更多,加锁的速度可能更慢,但是整个过程中不容易出现其他题目。
- 乐观锁的实现:引入一个版本号,借助版本号识别出当前的数据访问是否冲突。
- 悲观锁的实现:先加锁(比如借助操作系统提供的mutex),获取到锁再操作数据,获取不到就等待。
1.2 轻量级锁和重量级锁
按加锁开销的大小分:
- 轻量级锁:加锁的开销小,加锁的速度更快,轻量级锁一般就乐观锁。
- 重量级锁:加锁的开销大,加锁的速度更慢,重量级锁一般是悲观锁。
轻量和重量是加锁之后对结果的评价,乐观和悲观是加锁之前,对未发生的事情举行的预估,整体来说,这两种角度描述的是同一个事情。
1.3 自旋锁和挂起等待锁
- 自旋锁:是轻量级锁的一种典型实现,举行加锁的时间,搭配一个while循环,假如加锁乐成,自然循环竣事。假如加锁不乐成,不是阻塞放弃cpu,而是举行下一次循环,再次尝试获取到锁。这个反复快速执行的过程就称为自旋。一旦其他线程开释了锁,就能第一时间拿到锁。同时这样的自旋锁也就是乐观锁。自旋的条件:就是预期冲突的概率不大,其他线程开释了锁,就能第一时间拿到锁。当加锁的线程很多,自旋的意义就不大了,会浪费CPU资源。
- 挂起等待锁:重量级锁的一种典型实现,举行等待挂起等待的时间,就必要内核调度器介入,这一块要完成的操作很多,真正获取到锁花的时间就更多。同时也是一种悲观锁,这个锁可以适用于锁冲突激烈的情况。
synchronized具有自顺应能力
- 假如当前锁冲突的激烈程度不大,就处于乐观锁/轻量级锁/自旋锁。
- 假如当前锁冲突的激烈程度很大,就处于悲观锁/重量级锁/挂起等待锁。
1.4 普通互斥锁和读写锁
一个线程对于数据的访问,主要存在两种操作:读数据和写数据。
- 两个线程都只是读一个数据,此时并没有线程安全题目,之间并发的读取即可。
- 两个线程都要写一个数据,有线程安全题目。
- 一个线程读别的一个线程写,有线程安全题目。
- 普通互斥锁:多线程之间,数据的读取时之间不会产生线程安全题目,但是数据的写入方互相之间以及和读者之间都必要举行互斥。假如两种场景下都用同一个锁,就会产生极大的性能消耗,所以引出读写锁。
- 读写锁:在执行加锁操作时必要额外表明读写意图,复数读者之间并不互斥,而写者则要求与任何人互斥。读写锁分为两种情况,加 读锁和加 写锁。
- 读锁和读锁之间,不会出现锁冲突(不会阻塞,即不互斥)。
- 写锁和写锁之间,会出现锁冲突(会阻塞,即互斥)。
- 读锁和写锁之间,会出现锁冲突(会阻塞,即互斥)。
一个线程加 读锁的时间,另一个线程只能读,不能写。一个线程加 写锁的时间,另一个线程,不能读也不能写。
1.5 公平锁和非公平锁
假如三个线程A,B,C,A先尝试获取锁,获取乐成,然后B再尝试获取锁,获取失败,阻塞等待;然后C也尝试获取锁,C也获取失败,阻塞等待。
- 公平锁:遵守 “先来后到”,当A开释锁,B先于C拿到锁。
- 非公平锁:B和C都有可能获取到锁。
Java中synchronized黑白公平锁。
1.6 可重入锁和不可重入锁
- 可重入锁:一个线程针对一把锁,一连两次加锁,不会死锁。synchronized是可重入锁,实现方式:在加锁中记载锁持有的线程身份,以及一个计数器(记载加锁次数),假如发现加锁的线程就是持有锁的线程,则直接计数自增。
- 不可重入锁:一个线程针对一把锁,一连两次加锁,会死锁。系统自带的锁是不可重入的锁。
2. Synchronized原理(特点、加锁过程、自顺应)
2.1 Synchronized基本特点
- 开始是乐观锁,假如锁冲突频仍,转换为悲观锁(自顺应)
- 开始是轻量级锁实现,假如锁被持有的时间较长,就转换为重量级锁(自顺应)
- 实现轻量级锁的时间大概率用到自旋锁战略(自顺应)
- 是一种不公平锁
- 是一种可重入锁
- 不是读写锁
2.2 Synchronized加锁过程
当线程执行到Synchronized的时间,假如这个对象当前处于为加锁的状态,就会履历以下过程:
- 偏向锁阶段:假设没有线程竞争。 核心头脑就是懒汉模式,能不加锁就不加锁,能晚加锁就晚加锁。所谓的偏向锁,并非真的加锁了,而只是做了一个非常轻量的标记。非须要不加锁,在遇到竞争的情况下,偏向锁没有进步效率,但假如实在没有竞争的情况下,偏向锁就大幅度进步了效率。
- 轻量级锁阶段:假设有竞争,但是不多。此处就是通过自旋锁的方式来实现的;优势:别的的线程把锁开释了,就会第一时间拿到锁。劣势:比较消耗cpu,即对于自旋锁来说,假如同一个锁竞争者很多,大量线程都在自旋,整体cpu的消耗就很大。此同时,synchronized内部会统计当前这个锁对象上,有多少个线程在参与竞争,当参与竞争的线程多了就会进一步升级到重量级锁。
- 重量级锁阶段:锁竞争进一步激烈,此处的重量级锁就是指用到内核提供的mutex,此时拿不到锁的线程就不会继续自旋了,而是进入阻塞等待,让出cpu,当当前线程开释锁的时间,就由系统随机唤醒一个来获取锁。
2.3 锁消除
锁消除也是synchronized中内置的优化战略。编译器优化的一种方式,编译器编译代码的时间,假如发现这个代码,不必要加锁,就会自动把锁给干掉。针对一眼看上去就不涉及安全题目的代码,可以或许把锁消除掉,对于其他的很多含糊其词的,都不会消除。
2.4 锁粗化
锁粗化,会把多个细粒度的锁,合并成一个粗粒度的锁。粒度指的是synchronized {}里大括号里面包含代码越少,就认为锁的粒度越细,包含的代码越多,就认为锁的粒度越粗。
通常情况下,是更偏于让锁的粒度细一些,更有利于多个线程并发执行的,但偶然间也希望粒度粗点好.
如A给B交接使命,打电话,交接使命1,挂电话。打电话,交接使命2,挂电话。打电话,交接使命3,挂电话。粗化成,打电话,交接使命1,2,3.挂电话。把这三个合并一个粗粒度的锁,粗化进步了效率。
小结:synchronized的优化操作
- 锁升级:偏向锁 -> 轻量级锁 -> 重量级锁
- 锁消除:自动干掉不须要的锁
- 锁粗化:把多个细粒度的锁合并成一个粗粒度的锁,减少锁竞争。
3. CAS(compare and swap)
CAS是一个特殊的cpu的指令,完成的工作就是 比较 和 互换。是单个cpu指令,本身是原子的,同时完成 读取内存,比较是否相称,修改内存。
CAS的伪代码:
比较address内存地址中的值,是否和expected寄存器中的值雷同,假如雷同,就把swap寄存器的值和address内存的值,举行互换,返回true。假如不雷同,直接返回false。
- CAS本身是cpu指令,操作系统对指令举行了封装,jvm又对操作系统提供的api又封装了一层,有的cpu可能会不支持cas,而Java的标准库,对于CAS又举行了进一步的封装,提供了一些工具类,里面最主要的一个工具,原子类。
- 之前的线程安全都是靠加锁,加锁-》阻塞-》性能低落。基于CAS指令,不涉及加锁,不会阻塞,合理使用也包管线程安全,即无锁编程。
- public class ThreadDemo34 {
- // AtomicInteger: Java标准库中,对cas又进一步的封装,提供了一些工具类,即原子类
- // 使用原生的int 会出现线程安全问题 ,不使用加锁,使用AtomicInteger替换int也能保证线程安全
- // private static int count = 0;
- private static AtomicInteger count = new AtomicInteger(0);
- public static void main(String[] args) throws InterruptedException {
- Thread t1 = new Thread(() -> {
- for (int i = 0; i < 50000; i++) {
- //getAndIncrement 对变量的修改,是一个cas指令,即这个指令天然就是原子的
- //count++;
- count.getAndIncrement();
- // ++count;
- //count.incrementAndGet();
- // count += n;
- //count.getAndAdd(n);
- }
- });
- Thread t2 = new Thread(() -> {
- for (int i = 0; i < 50000; i++) {
- //count++;
- count.getAndIncrement();
- }
- });
- t1.start();
- t2.start();
- t1.join();
- t2.join();
- System.out.println(count);
- }
- }
复制代码 3.1 CAS 的ABA题目怎么办理
假如去ATM取钱,里面有1000,要取500,取钱的时间ATM卡了,按了一下没反应(t1线程),又按了一下(t2线程),此时此时产生了两个线程,去尝试扣款操作,此处 假如按CAS的方式扣款,这样是没题目的。当又来个t3线程给账户存了500,此时t1线程就不知道当前的1000是始终没变还是变了又变返来了。
办理方案:
- 约定数据变革是单向的(只能增加或者只能减少),不能是双向的(即又增加又能减少)。
- 对于本身就必须双向变革的数据,可以给它引入一个版本号,版本号这个数字是只能增加,不能减少。
4. Callable接口
- 继续Thread(包含了匿名内部类的方式)
- 实现Runnable(包含了匿名内部类的方式)
- 基于lambda
- 基于Callable
- 基于线程池
- Runnable关注的是这个过程,不关注执行结果,Runnable提供的是run方法,返回值类型是void
- public class ThreadDemo35 {
- private static int sum = 0;
- public static void main(String[] args) throws InterruptedException {
- // 创建一个新线程,用新的线程实现从1+到1000
- // 不用callable
- Thread t = new Thread(new Runnable() {
- @Override
- public void run() {
- int result = 0;
- for (int i = 0; i <= 1000; i++) {
- result += i;
- }
- sum = result;
- }
- });
- t.start();
- t.join();
- // 主线程获取到计算结果
- // 此处想要获取到结果,就需要弄一个成员变量保持上述结果
- System.out.println("sum= " + sum);
- }
- }
复制代码
- Callable要关注执行结果,Callable提供的call方法,返回值就是线程执利用命得到的结果
- callable 通常搭配FutureTask来使用,FutureTask用来生存Callable的返回结果,因为callable往往是在另一个线程中执行的,什么时间执行完不确定。
- FutureTask类,作为Thread和callable的粘合剂,使用futureTask.get()获取结果,带有阻塞功能,假如线程还没有执行完,get就会阻塞,等待线程执行完。
当编写多线程代码,希望关注线程中代码的返回值的时间:
相比于runnable来说,不必要引入额外的成员变量,直接借助这个的返回值即可。
- import java.util.concurrent.*;
- // Callable 接口
- public class ThreadDemo36 {
- public static void main(String[] args) throws ExecutionException, InterruptedException {
- // 期望线程的入口方法里,返回值是啥类型,此处的泛型就是什么类型 这里希望返回值是Integer
- Callable<Integer> callable = new Callable<Integer>() {
- @Override
- public Integer call() throws Exception {
- int result = 0;
- for (int i = 0; i <= 1000; i++) {
- result += i;
- }
- return result;
- }
- };
- //Thread没有提供构造函数传入callable
- // 引入一个FutureTask类,作为Thread和callable的粘合剂 未来的任务,相当于一个凭据
- FutureTask<Integer> futureTask = new FutureTask<>(callable);
-
- Thread t = new Thread(futureTask);
- t.start();
- // 接下来这个代码不需要join,使用futureTask获取到结果
- // futureTask.get() 这个操作也具有阻塞功能,如果线程还没有执行完毕,get就会阻塞,等到线程执行完了,
- //return的结果就会被get返回回来
- System.out.println(futureTask.get());
- }
- }
复制代码 5. JUC(java.util.concurrent)的常见类
5.1 ReentrantLock
用法:
- lock() :加锁,假如获取不到锁就死等
- unlock(),解锁
- trylock(超出时间):加锁,假如获取不到锁,等待肯定的时间之后就放弃加锁。
ReentrantLock,可重入锁,和synchronized一样是可重入锁,有了synchronized为什么还必要ReentrantLock:
- ReentrantLock提供了tryLock操作,lock直接举行加锁,假如加锁不成,就要阻塞;tryLock,尝试举行加锁,假如加锁不乐成,不阻塞,直接返回false,即tryLock提供了更多的可操作空间。
- Reentrant Lock提供了公平锁的实现(通过队列记载加锁线程的先后顺序),ReentrantLock构造方法中填写参数,就可以设置公平锁,而synchronized黑白公平锁。
- 搭配的等待通知机制差别的,synchronized,搭配wait / notify,对于Reentrant Lock,搭配Condition类,功能比wait / notify 略强一点。
6. 信号量Semaphore
信号量,用来体现 可用资源的个数,本质上就是一个计数器。
- import java.util.concurrent.Semaphore;
- // 信号量 Semaphore
- public class ThreadDemo37 {
- public static void main(String[] args) throws InterruptedException {
- Semaphore semaphore = new Semaphore(1);
- // 申请1个资源
- semaphore.acquire();
- System.out.println("P 操作");
- semaphore.acquire();
- System.out.println("P 操作");
- // 释放一个资源
- semaphore.release();
- System.out.println("V 操作");
- }
- }
复制代码
- new一个semaphore对象,有1个可用资源
- semaphore.acquire :申请一个资源,资源个数 -1(P操作)
- semaphore.release :开释一个资源,资源个数 +1 (V操作)
- 假如计数器为0,即没有可用资源了,还申请资源,就会阻塞等待,直到有其他线程开释资源。
- Semaphore的PV操作的加减操作都是原子的,可以在多线程下直接使用。
所谓的锁,本质上也是一种特殊的信号量,锁,可以认为计数值为1的信号量,开释状态,就是1,加锁状态,就是0,对于非0即1的信号量,称为二元信号量,信号量是更广义的锁。
6.1 使用Semaphore可以包管线程安全,就相当于synchronized加锁
使用Semaphore,先申请一个资源然后举行下述count++操作,再举行开释操作,这样也可以确保线程安全。
- import java.util.concurrent.Semaphore;
- // 信号量 Semaphore
- // 在操作前先申请一个可用资源 使数字-1 semaphore.acquire(); 后semaphore.release(); 数字+1 释放一个可用资源
- // 加锁状态, 就是 0 ,释放状态,就是1 对于非0即1的信号量就称为 二元信号量
- public class ThreadDemo38 {
- private static int count = 0;
- public static void main(String[] args) throws InterruptedException {
- Semaphore semaphore = new Semaphore(1);
- Thread t1 = new Thread(() -> {
- for (int i = 0; i < 50000; i++) {
- try {
- semaphore.acquire();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- count++;
- semaphore.release();
- }
- });
- Thread t2 = new Thread(() -> {
- for (int i = 0; i < 50000; i++) {
- try {
- semaphore.acquire();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- count++;
- semaphore.release();
- }
- });
- t1.start();
- t2.start();
- t1.join();
- t2.join();
- System.out.println(count);
- }
- }
复制代码 小结
确保线程安全的操作:
- synchronized
- ReentrantLock
- CAS(原子类)
- Semaphore
7. CountDownLatch
CountDownLatch,同时等待N个使命执行竣事,比如,多线程执行一个使命,把大的使命拆成几个部门,由每个线程分别执行。
- 构造CountDownLatch实例,初始化10体现10个使命线程必要完成
- 每个使命执行完毕,都调用latch.countDown(),在CountDownLatch 内部的计数器同时自减
- 主线程中使用latch.await(),阻塞等待所有使命竣事,相当于计数器为0
** join() ,就只能每个线程执行一个使命,而使用CountDownLatch就可以一个线程执行多个使命**。
- public class ThreadDemo39 {
- public static void main(String[] args) throws InterruptedException {
- // 1.此处构造方法中写10,意思是有10个线程任务
- CountDownLatch latch = new CountDownLatch(10);
- // 创建出 10个线程负责下载
- for (int i = 0; i < 10; i++) {
- int id = i;
- Thread t = new Thread(() -> {
- Random random = new Random();
- int time = (random.nextInt(5) + 1) * 1000;
- System.out.println("线程 "+id+"开始下载");
- try {
- Thread.sleep(time);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- System.out.println("线程结束 " + id + "结束下载");
- // 2.告知 CountDownLacth 执行结束了
- latch.countDown();
- });
- t.start();
- }
- // 3. 通过await操作等待所有任务结束,也就是 countDown被调用10次
- latch.await();
- System.out.println("所有任务都已经完成了");
- }
- }
复制代码 8. ConcurrentHashMap
多线程环境下HashMap线程不安全,使用哈希表(Hashtable)就在关键方法上添加synchronized。
- ConcurrentHashMap的读是否要加锁?
读操作没有加锁,目的是为了进一步低落锁冲突的概率,为了包管读到刚修改的数据,搭配了volatile关键字。
- 先容ConcurrentHashMap的锁分段技能?
把若干个哈希桶分成一个段,针对每个段分别加锁,这个是Java1.7中接纳的技能,Java1.8不再使用,
8.1 ConcurrentHashMap(Java1.8)的改进
- 缩小了锁的粒度
在Hashtable,直接在方法上使用synchronized,就相当于是对this加锁,此时尝试修改两个差别链表上的元素,都会触发锁冲突。假如修改两个差别链表上的元素,就不涉及到线程安全,修改差别变量。假如修改是同一个链表上的元素,就可能出现线程安全题目。
ConcurrentHashMap 就是把锁变小了,给每个链表都发了一把锁,此时,不是操作同一个链表的锁,就不会产生锁冲突。 不会产生更多的空间代价,因为Java中任何一个对象都可以直接作为锁对象,本身哈希表中,就得有数组,数组的元素都是已经存在的(每个链表的头节点作为加锁对象即可)。
锁桶(hash表也称为hash桶),构成了一个雷同于桶,每个链表就是构成桶的一个木板,所谓锁桶就是针对每个木板(每个链表)举行分别加锁的。
- 充分的使用了CAS原子操作,减少一些加锁
- 针对扩容操作的优化:扩容是一个重量操作。负载因子,描述了每个桶上均匀有多少个元素,0.75是负载因子默认的扩容阈值,不是负载因子本体。负载因子是计算出来的:拿着实际的元素个数 / 数组的长度(桶的个数),这个值和扩容阈值举行比较,看是否必要扩容。
- 假如太长,1.酿成树(长度不均匀的情况),2.扩容。
- 创建一个更大的数组,把旧的hash表的元素都给搬运到(删除/插入)新的数组上,假如hash表本身元素非常多,这里扩容操作就会消耗很长的时间。
- ** HashMap的扩容操作是梭哈,在某次插入元素的操作中,整体就举行了扩容。而ConcurrentHashMap,每次操作都只搬运一部门元素。**
- 即在扩容的过程中,同时存在两份哈希表,一份新的一份旧的:插入操作:直接往新的上插入;删除操作:新的旧的都是直接删除;查找操作:新的和旧的都得查询一下。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |