多线程--进阶-阿里云开发者社区

一. 常见的锁策略

1.1 乐观锁 vs 悲观锁

预测接下来锁冲突的概率是大,还是不大,根据这个冲突的概率,来决定接下来该咋做.

悲观锁:预测接下来冲突的概率比较大,总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以在每次拿数据的时候都会上锁,这样别人想拿这个数据的时候就会阻塞直到它拿到锁

乐观锁:预测接下来的冲突的概率不大,假设数据一般情况下不会产生并发冲突,所以在数据进行提交更新的时候,才会正式对数据是否产生并发冲突进行检测,如果发现并发冲突了,则返回用户错误的信息,让用户决定如何去做.

通常来说: 悲观锁一般要做的工作更多一些,效率会更低一些,乐观锁做的工作会少点,效率更高一点。

Synchronized 初始时使用乐观锁策略, 当发现锁竞争比较频繁的时候,就会自动切换成悲观锁策略.

1.2 轻量级锁 vs 重量级锁

重量级锁：加锁机制重度依赖了 OS提供的 mutex

• 大量的内核态用户态切换

• 很容易引发线程的调度

这两个操作，成本比较高，一旦涉及到用户态和内核态的切换，就意味着“沧海桑田”。

轻量级锁：加锁机制可能不使用 mutex ，而是尽量在用户态代码完成，实在搞不定了，再使用 mutex。

• 少量的内核态用户态切换

• 不太容易引发线程调度

理解用户态 vs 内核态

想象成去银行办业务

在窗口外，自己做，这时用户态，自己需要的时间成本是可控的；

在窗口内，工作人员做，这是内核态，内核态的时间成本是不太可控的。‘

如果办业务的时候反复和工作人员沟通，还需要重新排队，这时效率时很低的。

synchronized 开始是一个轻量级锁，如果锁冲突比较严重，就会变成重量级锁。

1.3 自旋锁 vs 挂起等待锁

按之前的方式，线程抢锁失败后进入阻塞状态，放弃CPU，需要过很久才能再次被调度，但实际上，大部分情况下，虽然当前抢锁失败，但过不了多久，锁就会被释放，没有必要就放弃cpu,这个时候就可以使用自旋锁来处理这样的问题。

自旋锁伪代码：

while(抢锁(lock)==失败){}

如果获取锁失败，立即再尝试获取锁，无限循环，直到获取到锁为止。第一次获取锁失败，第二次的尝试会在极短的时间内到来。

一旦锁被其他线程释放，就能第一时间获取到锁。

理解自旋锁 vs 挂起等待锁

想象一下，去追求喜欢的女神，当男生向女生表白后，女神说：你是个好人，但是我已经有男朋友了~~

挂起等待锁：我就不搭理女神了~~，我去潜心敲代码，等到未来某一天，女神分手了，她想起我来了，她主动找我，这个时候，我的机会就来了！！在挂起等待的期间，如果锁被释放，不能第一时间拿到锁，可能要过很久才能拿到锁，这个时间我是空闲出来的，就可以趁机学点别的技能。

自旋锁是一种典型的轻量级锁的实现方式(纯用户态的，不需要经过内核态，时间相对更短）

• 优点：没有放弃 CPU，不涉及线程阻塞和调度，一旦锁被释放，就能第一时间获取到锁。

• 缺点：如果锁被其他线程持有的时间比较久，那么就会持续消耗 CPU 资源（而挂起等待的时候是不消耗 CPU 的）。

挂起等待锁是通过内核态的机制来实现挂起等待，会使获取锁的时间更长。

synchronized 中的轻量级锁策略大概率就是通过自旋锁方式实现的。

针对上述三组锁策略：

synchronized 既是悲观锁，也是乐观锁，既是轻量级锁，也是重量级锁，轻量级锁部分基于自旋锁实现，重量级锁部分基于挂起等待锁实现。

1.4 互斥锁 vs 读写锁

synchronized 是互斥锁，像 synchronized 只有两个操作：

• 出了代码块，解锁

• 进入代码块，加锁

对与 synchronized 的加锁，只是单纯的加锁，没有更细化的区分了

除了 synchronized 锁之外，还有一种读写锁，能够把读和写两种加锁区分开

读写锁(ReentrantReadWriteLock)：

1.读锁和读锁之间，不会锁竞争。不会产生阻塞等待。

2.写锁和读锁之间，有锁竞争

3.写锁和读锁之间，也有锁竞争

1.5 可重入锁 vs 不可重入锁

如果一个锁，在一个线程中，连续对该锁加锁两次，不死锁，就叫做可重入锁，如果死锁了，就叫做不可重入锁

synchronized 是可重入锁

class BlockingQueue{
    synchronized void put(int elem){
        this.size();
    }
    
    synchronized int size(){......}
}

synchronized 是可重入锁，在这个场景下，不会死锁。在加锁的时候会判定一下，看当前尝试申请锁的线程是不是已经就是锁的拥有者了！如果是，就直接放行。

1.6 公平锁 vs 非公平锁

公平锁：遵守“先来后到”。B比C先到，当A释放锁之后，B就能先于C获取到锁

非公平锁: 不遵守“先来后到”.B和C竞争锁，都有可能获取到锁。

• 操作系统内部的线程调度就可以视为是随机的。如果不做任何额外的限制。锁就是非公平锁。如果要想实现公平锁，就需要依赖额外的数据结构，来记录线程们的先后顺序

• 公平锁和非公平锁没有好坏之分，关键还是看使用场景。

在。

• synchronized 是非公平锁

二. 死锁问题

死锁是什么?

多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放.由于线程被无限期的阻塞,因此程序不可能正常终止。

如何避免死锁

死锁产生的四个必要条件：

• 互斥使用，即当资源被一个线程使用时，别的线程不能使用

• 不可抢占，资源请求者不能强制从资源占有者手中读取资源，资源只能由资源占有者主动释放。

• 请求和保持，即当资源请求者在请求其他资源的同时保持对原有资源的占有。

• 循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P2的资源。这样就形成了一个等待循环路。

当上述四个条件都成立的时候，便形成死锁。当然，死锁的情况下如果打破上述任何一个条件，便可让死锁消失。

其中最容易破坏的就是“循环等待”。

破坏循环等待

最常用的一种死锁阻止技术就是锁排序。假设有N个线程尝试获取M把锁，就可以针对M把锁进行编号（1，2，3...M).

N 个线程尝试获取锁的时候，都按照固定的编号由小到大顺序来获取锁。这样就可以避免环路等待

两个线程对于加锁顺序没有约定，就容易产生环路等待

    public static void main(String[] args) {
        Object lock1=new Object();
        Object lock2=new Object();
 
        Thread t1=new Thread(()->{
            synchronized (lock1){
                synchronized (lock2){
                    //do something
                }
            }
        });
        t1.start();
        Thread t2=new Thread(()->{
            synchronized (lock2){
                synchronized (lock1){
                    //do something
                }
            }
        });
        t2.start();
    }

不会产生环路等待的代码：

约定号先获取lock1，再获取lock2，就不会产生环路等待。

    public static void main(String[] args) {
        Object lock1=new Object();
        Object lock2=new Object();
 
        Thread t1=new Thread(()->{
            synchronized (lock1){
                synchronized (lock2){
                    //do something
                }
            }
        });
        t1.start();
        Thread t2=new Thread(()->{
            synchronized (lock1){
                synchronized (lock2){
                    //do something
                }
            }
        });
        t2.start();
    }

三. CAS

CAS(compare and swap): 寄存器A的值和内存M的值进行对比，如果值相等，就把寄存器B的值赋给内存M。

我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。

1.比较A与V是否相等（比较）

2.如果比较相等，将B写入V。（交换）

3.返回操作成功过。

3.1 CAS 伪代码

下面写的代码不是原子的，真实的CAS是一个原子硬件指令完成的(这一条指令就能完成下述这一段代码)。这个伪代码只是辅助理解CAS的工作流程的。

boolean CAS(address, expectValue, swapValue){
    if(&address == expectValue){
        &address=swapValue;
        return true;
    }
    return false;
}

当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程，其他线程只会收到操作失败的信号。

CAS可以视为是一种乐观锁（或者可以理解为CAS是乐观锁的一种实现方式）

3.2 CAS 是怎么实现的

针对不同的操作系统，JVM用到了不同的CAS实现原理，简单来讲：

• java的CAS利用的是 unsafe 这个类提供的CAS操作；

• unsafe 的CAS依赖的是 jvm针对不同的操作系统实现的 Atomic::cmpxchg;

• Atomic::cmpxchg 的实现使用了汇编的CAS操作，并使用cpu 硬件提供的lock机制保证其原子性。

简而言之，是因为硬件予以了支持，软件层面才能做到。

3.3 CAS有哪些应用？

1. 实现原子类

标准库中提供了 java.util.concurrent.atomic 包，里面的类都是基于这种方式来实现的。

典型的就是 AtomicInteger 类，其中的 getAndIncrement 相当于i++操作。

伪代码实现：

class AtomicInteger {
    private int value;
    public int getAndIncrement() {
        int oldValue = value;
        while ( CAS(value, oldValue, oldValue+1) != true) {
            oldValue = value;
        }
        return oldValue;
    }
}

假设两个线程同时调用getAndIncrement

(1) 两个线程都读取 value 的值到 oldValue.(oldValue 是一个局部变量，在栈上，每个线程都有自己的栈）

（2）线程1 先执行CAS操作，由于 oldValue 和 value 的值相同，直接进行对value赋值。

注意：

• CAS 是直接读写内存的，而不是操作寄存器

• CAS 的读内存，写内存操作的是一条硬件指令，是原子的。

（3）线程2 再次执行CAS 操作，第一次CAS的时候发现oldValue 和value 不相等，不能直接赋值，因此需要进入循环。在循环里重新读取value的值赋给oldValue

(4) 线程2 接下来第二次执行CAS，此时oldValue 和 value 相同，于是直接赋值操作

（5）线程1 和线程2 返回各自的oldValue 的值即可。

再次声明：本来check and set 这样的操作在代码角度不是原子的，但是在硬件层面上可以让一条指令完成这个操作，也就变成原子的了

2.实现自旋锁

基于CAS实现更灵活的锁,获取到更多的控制权

自旋锁伪代码

public class SpinLock{
    private Thread owner =null;
    
    public void lock(){
        //如果当前owner 是null,比较就成功,就把当前线程的引用设置到owner 中,加锁完成!!循环结束
        //比较不成功,意味着 owner 非空,锁已经有线程持有了,此时CAS就啥都不干,直接返回false,循环继续
        //此时这个循环就会转的飞快,不停地尝试询问这里的锁是不是释放了,好处是一旦锁释放,就能立刻获取到.坏处,CPU忙等
        while(!CAS(this.owner, null, Thread.currentThread()){
        }
    }
    public void unlock{
        this.owner =null;
    }
}

3.4 CAS的 ABA 问题

1. 什么是 ABA问题

ABA问题: 假设存在两个线程t1和 t2 ,有一个共享变量,初始值为 A.

接下来,线程t1 想使用 CAS把num 值改成Z,那么就需要

• 先读取 num的值,记录到oldNum 变量中.

• 使用CAS 判定num的值是否为A,如果为A,就修改成了Z.

但是,在t1 执行这两个操作之间,t2 线程可能把num 的值从A变成了B,有从B改成了A.当t1 使用oldNum的值和内存中的值进行比较时,就会发现值没有变,从而执行CAS指令,对num进行赋值.

2. ABA 问题引来的 BUG

大部分的情况下, t2 线程这样的一个反复横跳改动,对于 t1 是否修改num 是没有影响的,但是不排除一些特殊情况.

假设滑稽老哥有100 存款,滑稽想从ATM 50 块钱,取款机创建了两个线程,并发的来执行 -50 操作

我们期望一个线程执行 -50 成功,另一个线程执行-50 失败.如果使用CAS 的方式来完成这个扣款过程就可能出现问题

正常过程

(1) 存款为100, 线程1 获取到当前存款值为 100, 期望更新为 50;线程2 获取到当前存款为100,期望更行为50.

(2) 线程 1 执行扣款成功,存款被改成50 ,线程2 阻塞等待中.

(3) 轮到线程2 执行了,发现当前存款未 50,和之前读到的 100 不相同.执行失败.

异常过程

(1) 存款100, 线程1 获取到当前存款值为100, 期望更新为50; 线程2 获取到当前存款为100,期望更新为50

(2) 线程1执行扣款成功,存款被改成 50, 线程2 阻塞等待中

(3) 咋线程2 执行之前,滑稽的朋友正好给滑稽转账50, 账户余额变成100

(4) 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的100 相同,再次执行扣款操作

这个时候,扣款操作被执行了两次,都是ABA问题搞得鬼.

3. 解决方案

要给修改的值,引入版本号, 在CAS 比较数据当前值和旧值的同时,也要比较版本号是否符合预期.

• CAS 操作在读取旧值的同时,也要读取版本号

• 真正修改的时候:如果当前版本号和读到的版本号相同,则修改数据,并把版本号 +1;如果当前版本号低于读到的版本号,就操作失败(认为数据已经被修改过了)

同样以上面的例子为例

假设滑稽老哥有 100 存款, 滑稽想从 ATM 取50 块钱. 取款机创建了两个线程,并发的来执行-50操作.

我们期望一个线程执行-50成功后,另一个线程-50失败

为了解决ABA 问题,给余额搭配一个版本号,初始设为1.

(1) 存款100, 线程1 获取到存款值为100,版本号为1, 期望更新为 50; 线程2获取到存款值为100,版本号为1,期望更新为50.

(2) 线程1 执行扣款成功,存款被改成50, 版本号改为2, 线程2 阻塞等待中

(3) 咋线程 2 执行之前,滑稽的朋友正好给滑稽转账50, 账户余额变成100, 版本号变为3

(4) 轮到线程2 执行了,返现当前存款为100,和之前读到的 100 相同,但是当前版本号为3,之前读到的版本号为1 ,版本小于当前版本,认为操作失败.

3.4 相关面试题

1. 讲解下你自己理解的CAS 机制

全称 Compare and swap ,即"比较并交换". 相当于通过一个原子操作,同时完成"读取内存,比较是否相等,修改内存"这三个步骤,本质上需要CPU指令的支撑.

2. ABA问题怎么解决?

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

四. Synchronized 原理

基本特点:结合上面的锁策略,我们可以总结出, Synchronized 具有以下特性(只考虑JDK 1.8)

1. 开始时是乐观锁，如果锁冲突频繁，就转换为重量级锁

2. 开始时是轻量级锁，如果锁被持有的时间较长，就转换为重量级锁

3. 实现轻量级锁的时候大概率用到的是自旋锁策略

4. 是一种不公平锁

5. 是一种可重入锁

6. 不是读写锁

加锁工作过程

JVM将 synchronized锁分为无锁，偏向锁，轻量级锁，重量级锁。会根据做情况，进行依次升级

4.1 偏向锁

第一个尝试加锁的线程，优先进入偏向锁状态。

偏向锁不是真的“加锁”，只是给锁对象中做一个“偏向锁”的标记，记录这个锁属于哪个线程。如果后续没有其他线程来竞争该锁，那么就不用进行其他同步操作了（避免了加锁解锁的开销）如果后续有其他线程来竞争锁（刚才已经在锁对象中记录了当前锁属于哪个线程了，很容易识别当前申请锁的线程是不是之前记录的线程），那就取消原来的偏向锁状态，进入一般的轻量级锁状态。

偏向锁本质上相当于“延迟加锁”，能不加锁就不加锁，尽量避免不必要的加锁和开锁，但是还是要做标记的，否则无法区分何时需要真正的加锁

4.2 轻量级锁

随着其他进程进入竞争，偏向锁状态被消除，进入轻量级锁状态（自适应的自旋锁）。此处的轻量级锁就是通过CAS来实现的。

• 通过CAS检查并更新一块内存（比如检锁对象做“偏向锁”标记的内存部分是否为null,如果为null，更新为该对象的引用）

• 如果更新成功，则认为加锁成功

• 如果更新失败，则认为该锁被占用，继续自旋式等待

自旋操作是一直让CPU 空转，比较浪费CPU资源。

因此此处的自旋不会一直进行，而是达到一定的时间/重试次数，就不再自旋了

也就是所谓的“自适应”

4.3 重量级锁

如果竞争进一步激烈，自旋不能快速获取到锁状态，就会膨胀为重量级锁

此处的重量级锁就是指内核提供的 mutex

• 执行加锁操作，先进入内核态

• 在内核态判定当前锁是否已经被占用

• 如果该锁没有被占用，则加锁成功，并切换回用户态

• 如果该锁被占用，则加锁失败。此时线程进入锁的等待队列，挂起，等待被操作系统唤醒

• 经历了一系列的沧海桑田，这个锁被其他线程释放了，操作系统也想起了这个挂起的线程，于是唤醒这个线程，尝试重新获取锁

4.4 其他优化操作

锁消除

编译器+JVM 判断锁是否可消除。如果可以，编译阶段做的优化手段,检查当前代码是否是多线程/是否有必要加锁,如果无必要,有把锁给写了,就会在编译过程中自动把锁去掉。

什么是“锁消除”？

有些程序中的代码中，用到了 synchronized，但其实在多线程环境下。（例如 StringBuffer)

StringBuffer sb=new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

此时每个append的调用都会涉及到加锁和解锁，但如果只是在单线程中执行这个代码，那么这些加锁解锁操作是没有必要的，白白浪费了一些资源开销。此时编译器就会做出优化，判断是否真的需要加锁。

锁粗化

一段逻辑中如果出现多次加锁和解锁，编译器 + JVM会自动进行锁粗化。

锁的粒度：synchronized 代码块，包含代码的多少，（代码越多，粒度越粗，越少，粒度越细。

实际开发过程中，使用细粒度锁，是期望释放锁的时候其他线程能使用，减少串行。

但是如果某个场景，要频繁加锁/解锁，此时编译器就可能把这个操作优化成一个粗粒度的锁。（加锁解锁要消耗大量的CPU资源）

五. Callable 接口

5.1 Callable 的用法

 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;
            }
        };
        // 把callable 实例使用FutureTask包装一下，不能直接传callable 
        FutureTask<Integer> futureTask=new FutureTask<>(callable);
        //创建线程，线程的构造方法传入FutureTask.此时新线程就会执行FutureTask内部的Callable 的call方法，完成计算，计算结果就放到了FutrueTask对象中
        Thread t=new Thread(futureTask);
        t.start();
        //主线程中调用futrue.get() 能够阻塞等待新线程计算完毕，并获取到FutrueTask中的结果
        int sum=futureTask.get();
        System.out.println(sum);
    }

5.2 理解 Callable

Callable 和 Runnable 相对，都是描述一个“任务”，Callable 描述的是带有返回值的任务，Runnable 描述的是不带返回值的任务。

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

六. JUC（java.util.concurrent)的常见类

6.1 ReentrantLock

可重入互斥锁，和synchronized 定位类似，都是用来实现互斥效果，保证线程安全。

ReentrantLock 的用法

• lock()：加锁，如果获取不到锁就死等

• trylock()：加锁，如果获取不到锁，等待一定的时间后就放弃锁

• unlock() : 解锁

ReentrantLock lock=new Reentrant();
lock.lock()
try{
   //working
}finally{
   lock.unlock();
}

ReentrantLock 和 synchronized 的区别:

1.synchronized 是一个关键字，是JVM 内部实现的,(大概率是基于C++实现的）。ReentrantLock 是标准库中的一个类，在JVM外实现的（基于java 实现的）。

2.sychronized 只是加锁和解锁，加锁的时候如果发现锁被占用，只能阻塞等待。ReentrantLock 还提供了一个tryLock 方法，如果加锁成功，那就没啥特殊的，如果加锁失败，不会阻塞，直接返回false（让程序员更灵活的决定接下来该怎么做）。

3. synchronized 是一个非公平锁（不遵循先来后到）；ReentrantLock 提供了公平和不公平两种工作模式。（在构造方法中，传入true 开启公平锁）

4. synchronized 搭配wait/notify 进行等待唤醒。如果多个线程wait 同一个对象，notify 的时候是随机唤醒一个。ReentrantLock 则是搭配Condition 这个类，这个类也能起到等待通知，但是可以精确的唤醒某个指定的线程。

6.2 原子类

原子类内部都是CAS实现的，所以性能要比加锁实现i++高很多，原子类有以下几个

• AtomicBlloean

• AtomicInteger

• AtomicIntegerArray

• AtomicLong

• AtomicReference

• AtomicStampdeReference

以AtomicInteger 举例，常见的方法有

addAndGet(int delta); i+=delta;

decrementAndGet(); --i;

getAndDecrement(); i--;

incrementAndGet(); ++i;

getAndIncrement(); i++;

6.3 信号量 Semaphore

信号量，用来表示“可用资源的个数”。本质上是一个计数器。

理解信号量

可以把信号量想象成是停车场的展示牌：当前有100个，表示有100个可用资源。

当有车开进来的时候，就相当于申请一个可用资源，可用车位就-1（称为信号量的P操作）

当有车开出去的时候，就相当于释放一个可用资源，可用车位就+1（称为信号量的V操作）

如果计数器的值已经为0了，还尝试申请资源，就会阻塞等待，直到有其他线程释放资源。

Semaphore 的PV操作中的加减计数器的操作都是原子的，可以在多线程的环境下直接使用。

    public static void main(String[] args) {
        Semaphore semaphore=new Semaphore(5);
        for (int i = 0; i < 20; i++) {
            int num=i;
            Thread t=new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println("申请资源");
                        semaphore.acquire();
                        System.out.println("我申请到了资源"+num);
                        Thread.sleep(1000);
                        System.out.println("我释放资源了"+num);
                        semaphore.release();
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            });
            t.start();
        }
    }

6.4 CountDownLatch

同时等待N个任务结束。

好像跑步比赛，10个选手依次就位，哨声响才同时出发；所有选手都通过终点，才能公布成绩。（线程都执行完，才执行后面的代码）。

 public static void main(String[] args) throws InterruptedException {
        CountDownLatch countDownLatch=new CountDownLatch(10);
        Runnable runnable=new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep((long)(Math.random()*1000));
                    //执行完毕，调用countDown()
                    countDownLatch.countDown();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        };
        for (int i = 0; i < 10; i++) {
            Thread t=new Thread(runnable);
            t.start();
        }
        //阻塞等待所有任务完成,此时会暗中计算，有几个countDown被调用了，
        // 当这10个人都调用过了之后，此时主线程的await就阻塞解除，就可以进行接下来的工作了。 
        countDownLatch.await();
        System.out.println("执行完毕");
    }

6.5 线程安全集合类

1.多线程环境使用 ArrayList

(1) Collection.synchronizedList(new ArrayList);

synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的List.

synchronizedList 的关键操作上都带有synchronized

(2) 使用 CopyOnWriteArrayList

CopyOnWrite 容器即写时复制容器.

• 当我们往一个容器添加元素的时候,不直接往当前容器添加,而是先将当前容器进行Copy,复制出一个新的容器,然后在新的容器里添加元素.

• 添加玩元素之后,再将原容器的引用指向新的容器

这样做的好处是我们可以对CopyOnWrite 容器进行并发的读,而不需要加锁,因为当前容器不会添加任何元素.所以CopyOnWrite 容器也是一种读写分离的思想,读和写不同的容器。

优点：在多读少写的场景下，性能很高，不需要加锁竞争

缺点：占用内存多；新写的数据不能第一时间读取到。

2. 多线程环境使用队列

（1）ArrayBlockingQueue

基于数组实现的阻塞队列

（2）LinkedBlockingQueue

基于链表实现的阻塞队列

（3）PriorityBlockingQueue

基于堆实现的带优先级的阻塞队列

（4）TransferQueue

最多只包含一个元素的阻塞队列

3. 多线程环境使用哈希表

HashMap 本身不是线程安全的

在多线程环境下使用哈希表可以使用：

• Hashtable

• ConcurrentHashMap

(1) Hashtable

只是简单的把关键方法加上了 synchronized 关键字。

这相当于直接针对Hashtable 对象本身加锁

• 如果多线程访问同一个 Hashtable 就会直接造成锁冲突

• size 属性也是通过 synchronized 来控制同步，也是比较慢的。

• 一旦扩容，就由该线程完成整个扩容过程，这个过程会涉及到大量的元素拷贝，效率会非常低。

（2）ConcurrentHashMap

相比于 Hashtable 做出了一系列的改进和优化，以java1.8为例

1. 读操作没有加锁（但是使用了 volatile 保证从内存读取结果），只对写操作进行加锁，加锁的方式仍然是用 synchronized，但是不是锁整个对象，而是锁每个链表的头节点作为锁对象，大大降低了所冲突的概率（针对同一个哈希表的不同位置添加元素，不涉及到锁竞争）。

2. 充分利用了CAS特性，比如 size 属性通过CAS 来更新。避免出现重量级锁的情况

3. 优化了扩容方式：化整为零

• 发现需要扩容的线程，只需要创建一个新的数组，同时只搬几个元素过去。

• 扩容期间，新老数组同时存在

• 后续每个操作 ConcurrentHashMap 的线程，都会参与搬家的过程，每个操作负责搬运一小部分元素

• 搬完最后一个元素再把老数组删掉

• 这个期间，插入只往新数组加

• 这个期间，查找与删除需要同时查新数组和老数组

七. 其他常见问题

1. 谈谈 volatile 关键字的用法

volatile 能够保证内存可见性，强制从内存中读取数据。此时如果有其他线程修改被 volatile 修饰的变量，可以第一时间读取到最新的值。

2. Java 多线程是如何实现数据共享的？

JVM 把内存分成了这几个区域：方法区，堆区，栈区，程序计数器。其中堆区这个内存区域是多个线程之间共享的。只要把某个数据放到堆内存中，就可以让多个线程都能访问到。

3. Java 创建线程池的接口是什么？参数 LinkedBlockingQueue 的作用是什么？

创建线程池主要两种方式：

• 通过 Executors 工厂类创建，创建方式比较简单，但是定制能力有限。

• 通过 ThreadPoolExecutor 创建。创建的方式比较复杂，但是定制能力强。

LindedBlockingQueue 标志线程池的任务队列。用户通过 submit/execute 向这个任务队列中添加任务。在由线程池中的工作线程来执行任务。

4. Java 线程共有几种状态？状态之间怎么切换的？

• NEW : 安排了工作，还未开始行动。新创建的线程。还没有调用 start 方法时处在这个状态。

• RUNNABLE : 可工作的，又可以分成正在工作中和即将开始工作。调用 start 方法之后，并正在 CPU 上运行/在即将准备运行的状态。

• BLOCKED : 使用 synchronized 的时候，如果锁被其他线程占用，就会阻塞等待，从而进入该状态。

• WAITING : 调用wait 方法会进入该状态。

• TIMED_WAITING: 调用 sleep 方法或者 wait（超时时间）会进入该状态

• TERMINATED : 工作完成了。当线程run 方法执行完毕后，会处于这个状态。

5. 在多线程下，如果对一个数进行叠加，该怎么做？

• 使用 synchronized / ReentrantLock 加锁

• 使用 AtomInteger 原子操作

6. Servlet 是否时线程安全的？

Servlet 本身时工作在多线程环境下。

如果在 Servlet 中创建了某个成员变量，此时如果由多个请求达到服务器，服务器就会多线程进行操作，是可能出现线程不安全的情况的。

7. Thread 和 Runnable 的区别和练习？

Thread 描述了一个线程

Runnable 描述了一个任务

在创建线程的时候需要指定线程完成的任务，可以直接从写Thread 的run 方法，也可以使用 Runnable 来描述这个任务。

8. 多次start 一个线程会怎么样？

第一次调用 start 可以调用成功

后续再次调用 start 会抛出 java.lang.illegalThreadStateException 异常。

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

多线程--进阶