【JavaEE -- 多线程进阶 - 面试重点】

打印 上一主题 下一主题

主题 1638|帖子 1638|积分 4924

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指令,不涉及加锁,不会阻塞,合理使用也包管线程安全,即无锁编程
  1. public class ThreadDemo34  {
  2.     // AtomicInteger: Java标准库中,对cas又进一步的封装,提供了一些工具类,即原子类
  3.     // 使用原生的int 会出现线程安全问题 ,不使用加锁,使用AtomicInteger替换int也能保证线程安全
  4.     // private static int count = 0;
  5.     private static AtomicInteger count = new AtomicInteger(0);
  6.     public static void main(String[] args) throws InterruptedException {
  7.         Thread t1 = new Thread(() -> {
  8.             for (int i = 0; i < 50000; i++) {
  9.                 //getAndIncrement 对变量的修改,是一个cas指令,即这个指令天然就是原子的
  10.                 //count++;
  11.                 count.getAndIncrement();
  12.                 // ++count;
  13.                 //count.incrementAndGet();
  14.                 // count += n;
  15.                 //count.getAndAdd(n);
  16.             }
  17.         });
  18.         Thread t2 = new Thread(() -> {
  19.             for (int i = 0; i < 50000; i++) {
  20.                 //count++;
  21.                 count.getAndIncrement();
  22.             }
  23.         });
  24.         t1.start();
  25.         t2.start();
  26.         t1.join();
  27.         t2.join();
  28.         System.out.println(count);
  29.     }
  30. }
复制代码
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
  1. public class ThreadDemo35 {
  2.     private static  int sum = 0;
  3.     public static void main(String[] args) throws InterruptedException {
  4.         // 创建一个新线程,用新的线程实现从1+到1000
  5.         // 不用callable
  6.         Thread t = new Thread(new Runnable() {
  7.             @Override
  8.             public void run() {
  9.                 int result = 0;
  10.                 for (int i = 0; i <= 1000; i++) {
  11.                     result += i;
  12.                 }
  13.                 sum = result;
  14.             }
  15.         });
  16.         t.start();
  17.         t.join();
  18.         // 主线程获取到计算结果
  19.         // 此处想要获取到结果,就需要弄一个成员变量保持上述结果
  20.         System.out.println("sum= " + sum);
  21.     }
  22. }
复制代码


  • Callable要关注执行结果,Callable提供的call方法,返回值就是线程执利用命得到的结果
  • callable 通常搭配FutureTask来使用,FutureTask用来生存Callable的返回结果,因为callable往往是在另一个线程中执行的,什么时间执行完不确定
  • FutureTask类,作为Thread和callable的粘合剂,使用futureTask.get()获取结果,带有阻塞功能,假如线程还没有执行完,get就会阻塞,等待线程执行完
    当编写多线程代码,希望关注线程中代码的返回值的时间:
    相比于runnable来说,不必要引入额外的成员变量,直接借助这个的返回值即可。
  1. import java.util.concurrent.*;
  2. // Callable 接口
  3. public class ThreadDemo36 {
  4.     public static void main(String[] args) throws ExecutionException, InterruptedException {
  5.         // 期望线程的入口方法里,返回值是啥类型,此处的泛型就是什么类型 这里希望返回值是Integer
  6.         Callable<Integer> callable = new Callable<Integer>() {
  7.             @Override
  8.             public Integer call() throws Exception {
  9.                 int result = 0;
  10.                 for (int i = 0; i <= 1000; i++) {
  11.                     result += i;
  12.                 }
  13.                 return result;
  14.             }
  15.         };
  16.         //Thread没有提供构造函数传入callable
  17.         // 引入一个FutureTask类,作为Thread和callable的粘合剂 未来的任务,相当于一个凭据
  18.         FutureTask<Integer> futureTask = new FutureTask<>(callable);
  19.                
  20.         Thread t = new Thread(futureTask);
  21.         t.start();
  22.         // 接下来这个代码不需要join,使用futureTask获取到结果
  23.         // futureTask.get() 这个操作也具有阻塞功能,如果线程还没有执行完毕,get就会阻塞,等到线程执行完了,
  24.             //return的结果就会被get返回回来
  25.         System.out.println(futureTask.get());
  26.     }
  27. }
复制代码
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

信号量,用来体现 可用资源的个数,本质上就是一个计数器。
  1. import java.util.concurrent.Semaphore;
  2. // 信号量 Semaphore
  3. public class ThreadDemo37 {
  4.     public static void main(String[] args) throws InterruptedException {
  5.         Semaphore semaphore = new Semaphore(1);
  6.         // 申请1个资源
  7.         semaphore.acquire();
  8.         System.out.println("P 操作");
  9.         semaphore.acquire();
  10.         System.out.println("P 操作");
  11.         // 释放一个资源
  12.         semaphore.release();
  13.         System.out.println("V 操作");
  14.     }
  15. }
复制代码


  • 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++操作,再举行开释操作,这样也可以确保线程安全
  1. import java.util.concurrent.Semaphore;
  2. // 信号量 Semaphore
  3. // 在操作前先申请一个可用资源 使数字-1 semaphore.acquire();  后semaphore.release(); 数字+1 释放一个可用资源
  4. // 加锁状态, 就是 0 ,释放状态,就是1 对于非0即1的信号量就称为 二元信号量
  5. public class ThreadDemo38 {
  6.     private static int count = 0;
  7.     public static void main(String[] args) throws InterruptedException {
  8.         Semaphore semaphore = new Semaphore(1);
  9.         Thread t1 = new Thread(() -> {
  10.             for (int i = 0; i < 50000; i++) {
  11.                 try {
  12.                     semaphore.acquire();
  13.                 } catch (InterruptedException e) {
  14.                     e.printStackTrace();
  15.                 }
  16.                 count++;
  17.                 semaphore.release();
  18.             }
  19.         });
  20.         Thread t2 = new Thread(() -> {
  21.             for (int i = 0; i < 50000; i++) {
  22.                 try {
  23.                     semaphore.acquire();
  24.                 } catch (InterruptedException e) {
  25.                     e.printStackTrace();
  26.                 }
  27.                 count++;
  28.                 semaphore.release();
  29.             }
  30.         });
  31.         t1.start();
  32.         t2.start();
  33.         t1.join();
  34.         t2.join();
  35.         System.out.println(count);
  36.     }
  37. }
复制代码
小结
确保线程安全的操作:

  • synchronized
  • ReentrantLock
  • CAS(原子类)
  • Semaphore
7. CountDownLatch

CountDownLatch,同时等待N个使命执行竣事,比如,多线程执行一个使命,把大的使命拆成几个部门,由每个线程分别执行


  • 构造CountDownLatch实例,初始化10体现10个使命线程必要完成
  • 每个使命执行完毕,都调用latch.countDown(),在CountDownLatch 内部的计数器同时自减
  • 主线程中使用latch.await(),阻塞等待所有使命竣事,相当于计数器为0
** join() ,就只能每个线程执行一个使命,而使用CountDownLatch就可以一个线程执行多个使命**。
  1. public class ThreadDemo39 {
  2.     public static void main(String[] args) throws InterruptedException {
  3.         // 1.此处构造方法中写10,意思是有10个线程任务
  4.         CountDownLatch latch = new CountDownLatch(10);
  5.         // 创建出 10个线程负责下载
  6.         for (int i = 0; i < 10; i++) {
  7.             int id = i;
  8.             Thread t = new Thread(() -> {
  9.                 Random random = new Random();
  10.                 int time = (random.nextInt(5) + 1) * 1000;
  11.                 System.out.println("线程 "+id+"开始下载");
  12.                 try {
  13.                     Thread.sleep(time);
  14.                 } catch (InterruptedException e) {
  15.                     e.printStackTrace();
  16.                 }
  17.                 System.out.println("线程结束 " + id + "结束下载");
  18.                 // 2.告知 CountDownLacth 执行结束了
  19.                 latch.countDown();
  20.             });
  21.             t.start();
  22.         }
  23.         // 3. 通过await操作等待所有任务结束,也就是 countDown被调用10次
  24.         latch.await();
  25.         System.out.println("所有任务都已经完成了");
  26.     }
  27. }
复制代码
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企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

来自云龙湖轮廓分明的月亮

论坛元老
这个人很懒什么都没写!
快速回复 返回顶部 返回列表