多线程进阶

鲁大师啦啦啦

已于 2022-03-27 14:13:40 修改

阅读量563

点赞数 2

分类专栏： JavaWeb 文章标签：多线程 java

于 2022-03-21 15:27:52 首次发布

本文链接：https://blog.csdn.net/qq_39537400/article/details/123609598

版权

JavaWeb 专栏收录该内容

14 篇文章 1 订阅

订阅专栏

一：线程池

1.线程池的由来

本来多进程就是为了解决并发编程的方案，但是进程有点太重量了（创建和销毁，开销比较大）

因此引入了线程，线程比进程要轻量很多。

即便如此，如果某些场景中，需要频繁的创建销毁线程，此时，线程的创建和销毁的开销，也就无法被忽视了。线程池就是为了解决这样的问题而来。

2.线程池的使用
使用线程的时候，不是说用的时候才创建，而是提前创建好，放到一个“池子里”（和字符串常量池是类似的东西）

当我们需要使用线程的时候，直接从池子里取一个线程过来。
当我们不需要这个线程的时候，就把这个线程还回池子中。

如果是真的创建/销毁线程，涉及到用户态和内核态的切换。（切换到内核态，然后创建出对应的PCB来）
如果不是真的创建销毁线程，而只是放到池子里，就相当于全在用户态，就能搞定这个事情。

啥是用户态和内核态？
用户态是应用程序执行的代码。
内核态是操作系统内核执行的代码。
一般认为，用户态和内核态之间的切换，是一个开销较大的操作。

3.线程池 ThreadPoolExecutor

在Java标准库里面，也提供了现成的线程池组件。

ThreadPoolExecutor

ThreadPoolExecutor 里面包含的线程的数量并不是一成不变的。
能够根据任务量来自适应。
如果任务比较多，就会多创建一些线程。
如果任务比较少，就少创建一些线程。

经典面试题：ThreadPoolExecutor的构造参数都是啥意思
corePoolSize：核心线程池
maximumPoolSize：最大线程数

这两个值具体设成多少合适？
通过实验的方法来确定比较合适。

keepAliveTime：描述非核心线程存在的时间。

unit：时间单位，也是keepAliveTime的单位 ms,s,minute

本质是性能和资源之间做权衡。

workQueue：阻塞队列，来组织线程池要执行的任务。

threadFactory：线程的创建方式

RejectedExecutionHandler：拒绝策略。根据具体的业务场景，来选取具体的拒绝策略，用于处理极端情况。
丢弃最新的任务，丢弃最老的任务，阻塞等待，抛出异常。

4.线程池 Executors 类
由于 ThreadPoolExecutor 使用起来比较复杂，标准库又提供了一组其他的类，相当于对 ThreadPoolExecutor 又进行了一层封装。

这个类相当于一个“工厂类”
通过这个类提供的一组工厂方法，就可以创建出不同风格的线程池实例了。

newFixedThreadPool：创建出一个固定线程数量的线程池（完全没有非核心线程）
newCachedThreadPool：创建出一个数量可变的线程池（全是非核心线程）
newSingleThreadPool：创建出一个只包含一个线程的线程池（只是特定场景下使用）
newScheduleThreadPool：能够设定延时时间的线程池（插入的任务能够过一会再执行），相当于进阶版的定时器。

在以上几个工厂方法里面，调用了 ThreadPoolExecutor 的构造方法，同时把对应的参数进行了传递，并返回 ThreadPoolExecutor 实例。

public static void main(String[] args) {
        // 使用一下标准库中的线程池
        ExecutorService service = Executors.newFixedThreadPool(10);
        // 给这个实例里面加入一些任务
        for (int i = 0; i < 20; i++) {
            service.submit(new Runnable() {
                @Override
                public void run() {
                    System.out.println("hello");
                }
            });
        }
    }

当前线程池里有10个工作线程
往任务队列中加入20个任务
此时这10个工作线程就会从任务队列中，先取出10个任务，然后并发执行这些任务
这些线程谁执行完了，当前的任务，谁就去任务队列中重新取一个新的任务。
直到把线程池任务队列中的任务都取完了，此时线程池的工作线程就阻塞等待（等待新的任务的到来）

5.工厂模式
工厂模式存在的意义就是在给构造方法填坑（定性）；例如，平面坐标系和极坐标系的构造函数。
工厂模式主要是为了创建实例

构造方法的限制比较多

构造方法的名字，必须是固定的（类名）
如果需要多个版本的构造方法，就只能依赖构造方法的重载

为了解决构造方法留下来的坑：
不使用构造方法来构造实例了，而是使用其他的方法来进行构造实例，这样的用来构造实例的方法，就称为“工厂方法”。
工厂方法其实就是普通的方法，这个工厂方法里面会调用对应的构造方法，并进行一些初始化操作，并返回这个对象的实例。

6.实现一个简单版本的线程池

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class ThreadDemo25 {
    static class Worker extends Thread{
        private BlockingQueue<Runnable> queue = null;
        public Worker(BlockingQueue<Runnable> queue){
            this.queue = queue;
        }

        @Override
        public void run() {
            // 工作线程的具体的逻辑
            // 需要从阻塞队列中取任务
            while (true){
                try {
                    Runnable command = queue.take();
                    // 通过 run 来执行这个具体的任务
                    command.run();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    static class Threadpool{
        // 包含一个阻塞队列，用来组织任务
        private BlockingQueue<Runnable> queue = new LinkedBlockingQueue<>();

        // 这个 list 就用来存放当前的工作线程
        private List<Thread> workers = new ArrayList<>();

        private static final int MAX_WORKER_COUNT = 10;

        // 通过这个方法，把任务加入到线程池中
        // submit 不光可以把任务放到阻塞队列中，同时也可以负责创建线程
        public void submit(Runnable command) throws InterruptedException {
            if(workers.size() < MAX_WORKER_COUNT){
                // 如果当前工作线程的数量不足线程数目上限，就创建出新的线程
                // 工作线程就专门搞一个类来完成
                // worker 内部要能够取到队列的内容，就需要把这个队列实例通过 worker 的构造方法，传过去
                Worker worker = new Worker(queue);
                worker.start();
                workers.add(worker);
            }
            queue.put(command);
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Threadpool pool = new Threadpool();
        for (int i = 0; i < 10; i++) {
            pool.submit(new Runnable() {
                @Override
                public void run() {
                    System.out.println("hello");
                }
            });
        }
    }
}

二：常见的锁策略

加锁，是一个开销比较大的事情。
我们希望在一些特定场景下，针对场景做出一些取舍，好让锁更高效一些。

1.乐观锁和悲观锁

乐观锁：假设锁冲突的概率比较低，甚至与基本没有冲突。
就只是简单处理一下冲突。

悲观锁：假设锁冲突的概率比较高，甚至于每次尝试加锁都会有冲突。
此时就会愿意付出更多的成本来处理冲突。

synchronized其实就是悲观锁为主（也不全是，也有的时候是乐观锁）

乐观锁的典型实现：引入“版本号”对余额进行修改，更轻量。

2.读写锁

多个线程同时尝试修改同一个变量~线程不安全
如果多个线程同时读取同一个变量~线程安全

有些场景中，本来就是写比较少，读比较多的情况

两个读线程，其实不存在线程安全问题，就不必互斥。
两个写线程之间，其实存在线程安全问题，就需要互斥。
一个读线程一个写线程之间，其实也存在线程安全问题，也需要互斥。

因此，就可以根据读写的不同场景，给读和写分别加锁。

synchronized 没有对读写进行区分，只要使用就一定互斥了。

Java标准库里提供了一个类
ReentrantReadWriteLock.ReadLock 能够构造一个读锁实例。
ReentrantReadWriteLock.WriteLock 能够构造一个写锁实例

对于读操作比较多，写比较少的情况，使用读写锁，就能大大的提高效率。（降低锁冲突的概率）

3.重量级锁和轻量级锁

这些锁策略和策略之间，并不是完全互不相关，可能会有部分重叠。

重量级锁：加锁解锁开销很大，往往是通过内核来完成的。
轻量级锁：加锁解锁开销很大，往往是只是在用户态完成的。

看重的是加锁解锁的开销大不大，和应用场景没啥关系。

加锁这里的“互斥”能力，是哪里来的？
归根结底，是CPU的能力~CPU提供了一些特殊的指令，通过这些指令来完成互斥。
操作系统内核在对这些指令进行了封装，并实现了阻塞等待。

CPU提供了一些特殊指令（原子操作的指令）
操作系统对这些指令封装了一层，提供了一个 mutex（互斥量）

Java JVM 相当于对操作系统提供的 mutex 再封装一层，实现了 synchronized 这样的锁。

如果是当前的锁，就是通过内核的 mutex 来完成的，此时这样的锁往往就开销比较大。
如果当前的锁，是在用户态，通过一些其他的手段来完成，这样的锁往往就开销更小。

synchronized 既是一个轻量级锁，也是一个重量级锁，根据场景自动适应。

锁策略面试题常见问法：谈谈对×××锁的理解

4.自旋锁和挂起等待锁

自旋锁：如果线程获取不到锁，不是阻塞等待，而是循环的快速的再试一次，因此就节省了操作系统调度线程的开销，要比挂起等待锁更能及时的获取到锁。问题是更浪费CPU资源。

挂起等待锁：如果线程获取不到锁，就会阻塞等待。啥时候结束阻塞，就取决于操作系统具体的调度。当线程挂起的时候，不占用CPU。

啥时候使用挂起等待锁，啥时候使用自旋锁？
大的原则是：

如果锁冲突的概率比较低，使用自旋锁比挂起等待锁，更合适。
如果线程持有锁的时间比较短，使用自旋锁也比挂起等待锁更合适
如果对CPU比较敏感，不希望吃太多的CPU资源，那么就不太适合使用自旋锁。

这个自旋和挂起等待，这样的策略在 synchronized 中内置，自适应。

5.公平锁和非公平锁

对于公平锁来说，追求先来后到的原则，先等待的线程先获得锁。要想实现公平锁，就需要有额外的数据结构（比如有个队列，通过这个队列来记录这个先来后到的过程）

对于非公平锁来说，不遵守先来后到的规则，获取锁的概率是均等的，完全取决于操作系统的调度了。

选择哪一个锁看需求选择：
大部分情况下，使用非公平锁就够了。
有些场景下，我们期望对于线程的调度的时间成本是可控的，这个时候就更需要公平锁了。

synchronized 是非公平锁

6.可重入锁和不可重入锁

如果针对同一把锁，连续加锁两次，
如果是不可重入锁，就会出现“死锁”
如果是可重入锁，就不会死锁。

让当前的锁，记录一下这个锁是谁持有的，如果发现，当前有一个线程再次尝试获取锁，这个时候，就让代码能够运行，而不是阻塞等待。同时在这个锁里也维护一个计算器。

synchronized 就是可重入锁

三：CAS

1.什么是CAS

compare and swar，字面意思是“比较和交换”，原子操作。

2.CAS的应用—实现原子类，实现自旋锁

像 i++ 这样的操作是线程不安全的。如果需要多线程并发的 i++，就需要加锁。
加锁操作是比较低效的，因此使用 CAS 就可以既能够高效的完成自增，同时又能够保证线程安全。（高效+安全）

基于CAS这样的操作，就实现出了一些“原子类”，这些原子类都是不需要加锁就能保证线程安全。

3.CAS 中的 ABA 问题

使用 CAS 的时候无法区分这个数据是始终没变，还是这个数据从A 变成了B，又变回了A。
大部分情况下，ABA问题，其实影响不大。

描述 ABA导致的 bug，导致误判。

如何解决 ABA 问题？

给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.
如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当
前版本号比之前读到的版本号大, 就认为操作失败.

四：synchronized 的原理

结合之前讲到的锁策略，可以对synchronized做一个直观的认识

开始使用的时候是乐观锁，如果发现锁冲突概率比较高，就会自动转成悲观锁
synchronized不是读写锁
synchronized开始的时候是轻量级锁，如果锁被持有的时间较长/锁的冲突概率较高，就会升级成重量级锁
synchronized是一个非公平锁
synchronized是一个可重入锁
synchronized为轻量级锁的时候，大概率是一个自旋锁；为重量级锁的时候大概率是一个挂起等待锁

synchronized的锁升级

偏向锁，其实也就是一种乐观锁，本质上是一种“延时加锁”。

偏向锁只是在对象头重设置一个“偏向锁标记”，这个只做标记，就比真正的加锁，要高效很多。
如果赌赢了，那么这次就不真加锁了，直到锁的释放，这整个过程中根本没有涉及到加锁解锁，因此就很快
如果赌输了，比如线程1尝试获取这把锁，锁进入偏向锁状态，此时如果有一个线程2，也尝试竞争这个锁，那么此时线程1就会抢先把这个锁拿到，然后线程2去等待。

完全没竞争的时候，是偏向锁，如果出现了竞争，但是这时候竞争还比较小，此时我们就会进入到“轻量级锁”状态。

此处的轻量级锁，是基于CAS实现的自旋锁，是属于完全在用户态完成的操作。
因此这里面不涉及到内核态用户态的切换，也不涉及到线程的阻塞等待和调度，知识多费了一些CPU而已。
但是能保证更高效的获取到锁。

但是如果当前的场景，是锁冲突概率比较大，锁的竞争比较激烈。此时锁还会进一步的膨胀成重量级锁。

如果锁冲突的概率太大了，轻量级自旋锁，就会浪费大量的CPU（在等待的时候是CPU空转的）

使用更重量的挂起等待锁，就可以解决这个问题。
对于挂起等待锁来说，当锁等待的过程中，是释放CPU（不占用CPU）
代价就是引入了线程的阻塞和调度开销

这些过程的转变，完全是自适应。

synchronized 除了这个自适应的锁升级之外，还有一些重要的优化手段。

锁消除，其实就是编译器和JVM自行判定一下，看看当前这个代码是否真的需要加锁。（JVM和编译器，不相信程序猿的水平）

锁的粗化
JVM和编译器，会进行一些智能的判定，把多组synchronized合并为一组。
锁的粒度
synchronized 代码中包含多少代码，如果包含的代码多，认为锁的粒度比较粗。如果包含的代码少，认为锁的粒度比较细。

五：Callable

关于线程创建：

继承Thread,重写run
实现Runnable 重写run
继承Thread，重写run,使用匿名内部类
实现Runnable，重写run，使用匿名内部类
使用lambda表达式

Callable也是一种创建线程的方式

Runnable只是描述了一个过程，不关注结果（不关注返回值）
Callable也是描述了一个过程，同时要关注返回结果
Callable中包含一个call方法，和Runnable.run类似，都是描述一个具体的任务，但是call方法是带返回值的。

如果我们期望创建一个线程，并关注这个线程产生的返回结果，使用Callable就比较合适。

public class ThreadDemo26 {
    static class Result{
        public int sum;
        public Object locker = new Object();
    }

    public static void main(String[] args) throws InterruptedException {
        Result result = new Result();
        Thread t = new Thread(){
            @Override
            public void run() {
                int sum = 0;
                for (int i = 0; i <= 1000 ; i++) {
                    sum+=i;
                }
                result.sum = sum;

                synchronized (result.locker) {
                    result.locker.notify();
                }
            }
        };
        t.start();

        // 此处我们期望，这个线程的计算结果能够被主线程获取到
        // 为了解决这个问题，就需要引入一个辅助的类
        // 当代码写成这个样子的时候，发现在主线程中，是无法得到 sum 的值的
        // 主要是因为当前 t 线程和主线程之间是并发的关系
        // 执行的先后顺序不能确定
        // 解决方案是，让main这个线程先等待（wait）。t线程计算完毕之后，通知唤醒 main 线程即可
        synchronized (result.locker) {
            while (result.sum == 0){
                result.locker.wait();
            }
        }
        System.out.println(result.sum);
    }
}

此时我们需要使用wait notify 以及 sybchronized 这些机制相互配合，才能完成这个工作。

使用Callable接口，会更加方便。

package java100_0926;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;

public class ThreadDemo27 {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Callable<Integer> callable = new Callable<Integer>() {
            @Override
            public Integer call() throws Exception {
                int sum = 0;
                for (int i = 0; i <= 1000 ; i++) {
                    sum+=i;
                }
                return sum;
            }
        };
        // 由于 Thread 不能直接传一个 callable 实例，就需要一个辅助的类来包装一下
        // futureTask保存了Callable返回的结果
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        Thread t = new Thread(futureTask);
        t.start();

        // 尝试在主线程获取结果
        Integer result = futureTask.get();
        System.out.println(result);
    }
}

介绍下Callable是什么？

Callable 是一个 interface . 相当于把线程封装了一个 “返回值”. 方便程序猿借助多线程的方式计算
结果.
Callable 和 Runnable 相对, 都是描述一个 “任务”. Callable 描述的是带有返回值的任务,
Runnable 描述的是不带返回值的任务.

Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.
FutureTask 就可以负责这个等待结果出来的工作.

六：JUC(java.util.concurrent) 的常见类（面试出现的不多）

concurrent 并发

1.ReentrantLock

		public void increase(){
            lock.lock();
            count++;
            lock.unlock();
        }

ReentrantLock把加锁和解锁操作拆分开了
这种风格的代码，是常见的写法。

import java.util.concurrent.locks.ReentrantLock;

public class ThreadDemo28 {
    static class Counter{
        public int count = 0;
        public ReentrantLock lock = new ReentrantLock();
        public void increase(){
            lock.lock();
            count++;
            lock.unlock();
        }
    }
    public static void main(String[] args) {
        Counter counter = new Counter();
        Thread t1 = new Thread(){
            @Override
            public void run() {
                for (int i = 0; i < 50000; i++) {
                    counter.increase();
                }
            }
        };
        Thread t2 = new Thread(){
            @Override
            public void run() {
                for (int i = 0; i < 50000; i++) {
                    counter.increase();
                }
            }
        };
        t1.start();
        t2.start();


        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(counter.count);
    }
}

ReentrantLock相当于对 synchronized进行了补充

ReentrantLock把加锁和解锁拆分成两个方法，确实存在解锁的风险，但是可以让代码更灵活，比如把加锁解锁的diamante分别放到两个方法中
ReentrantLock除了lock和unlock方法之外，还提供了一个tryLock方法；
对于lock方法来说，如果尝试加锁失败，就会阻塞等待
对于tryLock方法来说，如果尝试加锁失败，就直接返回出错，不会阻塞等待
synchronized是一个非公平锁；
ReentrantLock支持两种模式：既可以支持公平锁，也能支持非公平锁

public ReentrantLock lock = new ReentrantLock(true);

ReentrantLock提供了比synchronized更强大的等待唤醒机制
synchronized是搭配wait notify
ReentrantLock是搭配了另外一个Condition类来完成等待唤醒（能够显示指定唤醒那个等待的线程）

2.原子类

AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

package java100_0926;

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.ReentrantLock;

public class ThreadDemo28 {
    static class Counter{

        //public ReentrantLock lock = new ReentrantLock(true);
        public AtomicInteger count = new AtomicInteger(0);
        public void increase(){
//            lock.lock();
//            count++;
//            lock.unlock();
            count.getAndIncrement();
        }
    }
    public static void main(String[] args) {
        Counter counter = new Counter();
        Thread t1 = new Thread(){
            @Override
            public void run() {
                for (int i = 0; i < 50000; i++) {
                    counter.increase();
                }
            }
        };
        Thread t2 = new Thread(){
            @Override
            public void run() {
                for (int i = 0; i < 50000; i++) {
                    counter.increase();
                }
            }
        };
        t1.start();
        t2.start();


        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(counter.count);
    }
}

3.信号量 Semaphore

信号量是一个计算器（int整数）
功能：描述可用资源的个数

也可以使用信号量来控制线程安全。
创建信号量的时候，设置一个初始值（可用资源的个数）
如果把初始值设为1了，此时这个信号量就只有0 1两种取值
称为“二元信号量”
二元信号量就和锁的功能是类似的

P操作：申请资源
V操作：释放资源

import java.util.concurrent.Semaphore;

public class ThreadDemo29 {
    public static void main(String[] args) {
        Semaphore semaphore = new Semaphore(4);
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                try {
                    // 先尝试申请资源
                    System.out.println("准备申请资源");
                    semaphore.acquire();
                    System.out.println("申请资源成功");
                    // 申请到了之后，sleep 1000ms
                    Thread.sleep(1000);
                    // 再释放资源
                    semaphore.release();
                    System.out.println("释放资源成功");
                } catch (InterruptedException e) {
                    e.printStackTrace();

                }

            }
        };
        // 创建 20 个线程
        // 让这20个线程来分别去尝试申请资源
        for (int i = 0; i < 20; i++) {
            Thread t = new Thread(runnable);
            t.start();
        }
    }
}

4.CountDownLatch

import java.util.concurrent.CountDownLatch;

public class ThreadDemo30 {
    public static void main(String[] args) throws InterruptedException {
    	// 有八个线程在跑
        CountDownLatch latch = new CountDownLatch(8);
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                System.out.println("起跑");
                // random 方法得到的是一个[0,1)之间的浮点数
                // sleep 的单位是 ms,此处 *10000 意思是 sleep[0,10)区间范围内的秒数
                try {
                    Thread.sleep((long) (Math.random()*10000));
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                latch.countDown();
                System.out.println("撞线完成！");
            }
        };
        for (int i = 0; i < 8; i++) {
            Thread t = new Thread(runnable);
            t.start();
        }
        latch.await();
        System.out.println("比赛结束");
    }
}

七：线程安全的集合类

线程不安全的集合类

ArrayList
LinkedList
TreeMap
HashMap
TreeSet
HashSet
Queue

如果想在多线程环境下来使用这些，就需要做一些特殊的处理~典型的办法就是加锁。

Stack String StringBuffer 是线程安全
Strng 内部并没有进行加锁，但是仍然是线程安全？
String是一个不可变对象，指的就是，没有提供public的方法，来修改 String的内容。

多线程环境下使用哈希表

ConcurrentHashMap 其实也是使用 synchronized 加锁，但是加锁方式和 HashTable 区别很大。
HashTable 是直接针对 this 对象来加锁
一个HashTable实例，就只有一把锁
此时如果有10个线程并发修改这个HashTable，此时10个线程也就都在竞争同一把锁了（锁冲突的概率比较高）

ComcurrentHashMap锁对象，是针对数组的每个元素来进行加锁（也就是针对每个哈希桶来加锁）

此时如果再有十个线程，并发修改哈希表，此时如果当前线程之间计算出的数组位置（hashcode%数组长度）是不相同的，此时就没有锁竞争。
即使有两个线程修改的元素正好在同一个数组位置上，此时才会发生锁竞争。

1.ConcurrentHashMap 针对修改操作的加锁，使用的是粒度更小的锁，针对每个哈希桶来分别设定锁。大大降低了锁冲突的概率（针对java1.8）
在java1.8之前，ConcurrentHashMap使用的是“分段锁”，相当于把这些哈希桶分成若干组，每组分配一个锁。
2.ConcurrentHashMap针对读操作，没加锁，而是直接使用volatile
设计者评估了说，读操作，其实影响不大，读到一个旧的值和新的值，对于实际开发来说没有明显的影响
3.更充分的利用了CAS的特性，比如获取/修改size属性（元素个数）
4.更优化的扩容方式

HashTable的扩容：
如果某次put操作，导致当前的元素个数太多了，就会触发扩容，这个扩容就会需要创建一个更大的内存，并且把数据复制过去一份。
这就会直接导致这次插入操作，非常非常低效。

ConcurrentHashMap 基本思路，就是“化整为零”
如果某个插入操作触发了扩容，不是一口气扩容完，而是只搬运一部分元素。
下次再对这个ConcurrentHashMap操作的时候，再搬运一部分，保证每次操作都不至于太慢
在这个搬运过程中，相当于内部维护了两套内存，一套是旧的数据，一套是新的数据
插入操作，就只往新数据中插
查找操作，就需要同时查旧的数据和新的数据
当完全搬运完成，再删除旧数据

八：死锁

死锁：锁导致了线程被阻塞，该锁被释放了之后，对应的线程才会结束阻塞，但是有的时候可能这个锁永远也释放不了。于是该线程也就无法结束阻塞状态了。

产生死锁的场景：
1.如果一个线程针对一把锁，连续尝试加锁两次，并且该锁不是可重入锁的时候。
2.两个线程，两把锁（双方互不释放资源，仍然需要对象的另一把锁）
3.多个线程和多个锁 =》哲学家问题

站在教科书的角度，总结出死锁的四个必要条件：
1.互斥使用。如果一个锁被一个线程占用的时候，别的线程就会阻塞等待（锁的基本设定）
2.不可抢占/不可剥夺。线程1如果获取到一把锁，此时线程2不能强行把锁给抢过来
3.请求和保持。当资源的请求者在请求其他资源的时候，同时要保持之前的资源（线程获取到锁1之后，再尝试获取锁2，此时仍然保持对锁1的持有）
4.循环等待。线程1，先尝试获取锁1 和锁2 线程2 尝试获取锁2和锁1 这样的情况就是循环等待。

重点记第四条，和写代码相关。

死锁的常见面试题：谈谈对于死锁的理解
不要背！！！

如何避免死锁？

银行家算法非常复杂，不太适合实际开发的时候使用。

站在开发的角度：
1.尽量避免复杂的设计，避免在某个锁的代码中再尝试获取其他锁。
如果实在需要进行锁的嵌套使用，一方面要保证持有锁的时间足够短，代码足够简单，另一方面要保证按照统一的顺序（先获取锁1 再获取锁2）来进行加锁。

这样的固定顺序，其实就是破坏了死锁的“循环等待”

鲁大师啦啦啦

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
多线程进阶

一：线程池1.线程池的由来本来多进程就是为了解决并发编程的方案，但是进程有点太重量了（创建和销毁，开销比较大）因此引入了线程，线程比进程要轻量很多。即便如此，如果某些场景中，需要频繁的创建销毁线程，此时，线程的创建和销毁的开销，也就无法被忽视了。线程池就是为了解决这样的问题而来。2.线程池的使用使用线程的时候，不是说用的时候才创建，而是提前创建好，放到一个“池子里”（和字符串常量池是类似的东西）当我们需要使用线程的时候，直接从池子里取一个线程过来。当我们不需要这个线程的时候，就把这个线程还回
复制链接

扫一扫

专栏目录