【JavaEE】Synchronized原理、JUC以及线程安全的集合类手术刀剖析

最新推荐文章于 2023-12-09 23:44:29 发布

十叶知秋

最新推荐文章于 2023-12-09 23:44:29 发布

阅读量1.2k

点赞数 24

分类专栏： JavaEE 多线程文章标签： java java-ee 后端算法

本文链接：https://blog.csdn.net/weixin_46913665/article/details/123989221

版权

JavaEE 同时被 2 个专栏收录

18 篇文章 4 订阅

订阅专栏

多线程

9 篇文章 0 订阅

订阅专栏

文章目录

一、Synchronized 原理
二、JUC(java.util.concurrent)
三、线程安全的集合类
四、最后

一、Synchronized 原理

1.synchronized的基本特点

以JDK1.8为例：

开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁；
开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁；
实现轻量级锁的时候大概率用到的自旋锁策略；
是一种不公平锁；
是一种可重入锁；
不是读写锁。

2.synchronized典型的优化手段

这些典型的优化手段都是编译器、操作系统、jvm、CPU相互配合完成的。

2.1.锁膨胀/锁升级

体现了synchronized能够“自适应”的能力。

加锁的工作过程如下：
JVM 将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级。

在这里插入图片描述下面详细讲解一下具体的过程：

（1）偏向锁
第一个尝试加锁的线程, 优先进入偏向锁状态。
偏向锁不是真的 “加锁”, 只是给对象头中做一个 “偏向锁的标记”, 记录这个锁属于哪个线程。
如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)。
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态。
偏向锁本质上相当于 “延迟加锁” . 能不加锁就不加锁, 尽量来避免不必要的加锁开销。
但是该做的标记还是得做的, 否则无法区分何时需要真正加锁。

举个不恰当的例子：现在很多年轻人同居但不结婚，这个同居就如同我们之间做了一个标记一样，它的好处就是我们不用像结婚之后承担那么多东西，也可以很甜蜜的生活在一起。但是有一天，男方或者女方有其他的人在追，于是另外一方就希望赶紧结婚，将这段关系进行法律上的认证，让其他追求者死心。那么这个结婚过程就是偏向锁升级到轻量级锁的过程。

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

通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
如果更新成功, 则认为加锁成功
如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU)

自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源.
因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了.
也就是所谓的 “自适应”。

（3）重量级锁
如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁。
此处的重量级锁就是指用到内核提供的 mutex ：

执行加锁操作, 先进入内核态；
在内核态判定当前锁是否已经被占用；
如果该锁没有占用, 则加锁成功, 并切换回用户态；
如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒；
经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁。

2.2. 锁粗化

锁粗化对应的就是锁细化，这里的粗细指的是锁的粒度。
锁的粒度：加锁代码涉及到的范围，加锁代码的范围越大，认为锁的粒度越粗；范围越小，则认为粒度越细。

在这里插入图片描述

实际开发过程中, 使用细粒度锁, 是期望释放锁的时候其他线程能使用锁，但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释放锁。

那么到底锁的粒度粗好还是细好？
各有各的好，如果锁粒度比较细的话，多个线程之间的并发性就更高；如果锁粒度比较粗的话，加锁解锁的开销就更小。

我们编译器和JVM面对锁的粒度问题会有这样的一个优化，如果某个地方的代码粒度太细了，也就是进行频繁的加锁解锁，它就会进行优化，使锁的粒度变粗；如果两次加锁之间的间隔较大，中间隔的代码多，一般不会进行这个优化。

2.3.锁消除

我们有些代码是不用加锁的，但是我们也给上锁了，这个时候编译器就会检查发现这个加锁好像没什么必要，就直接把锁给去掉了。比如说，我们的代码里面只有一个线程，这个时候加锁就没有意义了，编译会把我们加的锁去掉。

二、JUC(java.util.concurrent)

这个包里面提供了大量应用于线程的一些工具类,供我们在不同需求上进行应用。

1.Callable 接口

callable是一个interface，同时也是一个创建线程的方式。它相当于把线程封装了一个 “返回值”，方便程序猿借助多线程的方式计算结果。而我们的Runnable虽然也可以创建线程，但是它不适合让线程计算出一个结果。

例如，创建一个线程，让这个线程计算出1+2+3+…+1000。如果此时基于Runnable来实现的话，就会比较麻烦。而callable就能解决Runnable不方便返回结果的这个问题。

（1）使用Runnable方法来实现。

创建一个类 Result , 包含一个 sum 表示最终结果, lock 表示线程同步使用的锁对象.
main 方法中先创建 Result 实例, 然后创建一个线程 t. 在线程内部计算 1 + 2 + 3 + … + 1000.
主线程同时使用 wait 等待线程 t 计算结束. (注意, 如果执行到 wait 之前, 线程 t 已经计算完了, 就不必等待了).
当线程 t 计算完毕后, 通过 notify 唤醒主线程, 主线程再打印结果

public class Demo9 {
    static class Result{
        public int sum = 0;
        public Object lock = 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;
                }
                synchronized (result.lock){
                    result.sum = sum;
                    result.lock.notify();
                }
            }
        };
        t.start();

        synchronized (result.lock){
            while (result.sum == 0){
                result.lock.wait();
            }
            System.out.println(result.sum);
        }
    }
}

在这里插入图片描述
可以看到, 上述代码需要一个辅助类 Result, 还需要使用一系列的加锁和 wait notify 操作, 代码复杂, 容易出错.

(2)使用Callable接口

创建一个匿名内部类, 实现 Callable 接口. Callable 带有泛型参数. 泛型参数表示返回值的类型.
重写 Callable 的 call 方法, 完成累加的过程. 直接通过返回值返回计算结果.
把 callable 实例使用 FutureTask 包装一下.
创建线程, 线程的构造方法传入 FutureTask . 此时新线程就会执行 FutureTask 内部的 Callable 的call 方法, 完成计算. 计算结果就放到了 FutureTask 对象中.
在主线程中调用 futureTask.get() 能够阻塞等待新线程计算完毕. 并获取到 FutureTask 中的结果

public class Demo10 {
    public static void main(String[] args) {
        //通过callable来描述一个任务
        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<Integer> task = new FutureTask<>(callable);
        //创建线程，来完成这里的计算工作
        Thread t = new Thread(task);
        t.start();

        // 如果线程的任务没有执行完呢, get 就会阻塞.
        // 一直阻塞到, 任务完成了, 结果算出来了
        try {
            System.out.println(task.get());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }
}

在这里插入图片描述可以看到, 使用 Callable 和 FutureTask 之后, 代码简化了很多, 也不必手动写线程同步代码了

这里解释一下callable与FutureTask ：

Callable 和 Runnable 相对, 都是描述一个 “任务”. Callable 描述的是带有返回值的任务；
Runnable 描述的是不带返回值的任务；
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.那么FutureTask负责这个等待结果出来的工作。

相关面试题：介绍下 Callable 是什么？

Callable 是一个 interface . 相当于把线程封装了一个 “返回值”. 方便程序猿借助多线程的方式计算结果.
Callable 和 Runnable 相对, 都是描述一个 “任务”. Callable 描述的是带有返回值的任务,
Runnable 描述的是不带返回值的任务
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定，那么FutureTask负责这个等待结果出来的工作。

2.ReentrantLock

ReentrantLock是可重入锁，与synchronized一样。

ReentrantLock 的基本用法:

lock(): 加锁, 如果获取不到锁就死等.
trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁.
unlock(): 解锁

ReentrantLock 和 synchronized 的区别：

synchronized是一个关键字，背后的逻辑是JVM实现的，也就是用c++来写的；而ReentrantLock 是一个标准库中的类，背后的逻辑是Java代码写的。
synchronized不需要手动释放锁，出了代码块，锁自然释放；ReentrantLock 必须手动释放锁，因此，使用ReentrantLock 要记得释放。
synchronized如果竞争锁失败，就会阻塞等待；而ReentrantLock 锁竞争失败之后，除了会阻塞等待，还可以使用trylock操作，如果失败了就直接返回。
synchronized是一个非公平锁；而ReentrantLock 提供了公平锁与非公平锁两种，在构造方法中,我们可以通过参数来指定当前是公平锁还是非公平锁。
基于synchronized衍生出来的等待机制，是wait与notify,功能相对有限，每次唤醒的是一个随机等待的线程；而基于ReentrantLock 衍生出来的等待机制，是Condition类，功能会更丰富一些，可以更精确控制唤醒某个指定的线程。

那么我该如何选择这两个加锁工具呢？

锁竞争不激烈的时候, 使用 synchronized, 效率更高, 自动释放更方便.
锁竞争激烈的时候, 使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为, 而不是死等.
如果需要使用公平锁, 使用 ReentrantLock

但在我们的实际开发中，synchronized就够用了。

3.原子类

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

AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

这篇文章里面有原子类的介绍与用法：【JavaEE】常见锁策略与CAS手术刀剖析

4.线程池

这篇文章详细介绍了线程池：【JavaEE】多线程案例——定时器与线程池

5.信号量 Semaphore

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

举个例子：

可以把信号量想象成是停车场的展示牌: 当前有车位 100 个. 表示有 100 个可用资源.
当有车开进去的时候, 就相当于申请一个可用资源, 可用车位就 -1 (这个称为信号量的 P 操作)
当有车开出来的时候, 就相当于释放一个可用资源, 可用车位就 +1 (这个称为信号量的 V 操作)
如果计数器的值已经为 0 了, 还尝试申请资源, 就会阻塞等待, 直到有其他线程释放资源.

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

public class Demo11 {
    public static void main(String[] args) throws InterruptedException {
        //初始化值表示可用资源有4个
        Semaphore semaphore = new Semaphore(4);
        //申请资源，P操作
        semaphore.acquire();
        System.out.println("申请成功");
        semaphore.acquire();
        System.out.println("申请成功");
        semaphore.acquire();
        System.out.println("申请成功");
        semaphore.acquire();
        System.out.println("申请成功");
        semaphore.acquire();
        System.out.println("申请成功");

        //释放资源，V操作
        semaphore.release();
    }
}

在这里插入图片描述

6.CountDownLatch

CountDownLatch表示同时等待 N 个任务执行结束。
在现实生活中，比如说我们下载电影，如果通过多线程下载的话就可以提高下载速度了。因为我们可以把一个文件拆分成多个部分,每个线程负责下载其中的一个部分，然后等到所有的线程都下载完成了，我们的电影才算下载完毕。

CountDownLatch里面我们提供了两个方法：

countDown:给每个线程里面去调用,表示到达终点。
await：给等待线程去调用,当所有的任务都到达终点了await就从阻塞队列中返回，表示任务完成。

下面举一个例子：跑步比赛，10个选手依次就位,枪一响同时出发，但是我们要等到所有选手都通过了终点线，才公布成绩。

在这里插入图片描述

三、线程安全的集合类

线程安全与线程不安全的类：

线程不安全	线程安全
ArrayList	Vector (不推荐使用)
LinkedList	HashTable (不推荐使用)
HashMap	ConcurrentHashMap
TreeMap	StringBuffer
HashSet	String（特殊的）
TreeSet
StringBuilder

1.多线程环境使用 ArrayList

上面的表格里我们可以看到，ArrayList是一个线程不安全的类，那么我们在多线程的情况下该如何使用ArrayList呢？

我们有以下解决方案：

自己使用同步机制 (synchronized 或者 ReentrantLock)
Collections.synchronizedList(new ArrayList)：
synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List；
synchronizedList 的关键操作上都带有 synchronized
（这里会把我们传进去的ArrayList加一层锁，这里不像第一种自己加锁灵活，因为我们有的方法涉及到线程安全就加锁，有些不涉及到就不用加锁，而这里的这个操作就会全加，那这跟volatile其实就差不多。这是一个选择，但不是特别好的选择）
使用 CopyOnWriteArrayList
CopyOnWrite容器即写时复制的容器。
当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素。
添加完元素之后，再将原容器的引用指向新的容器。

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

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

缺点:

占用内存较多.
新写的数据不能被第一时间读取到

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

HashMap本身是线程不安全的，我们的解决方案有以下两种：

HashTable
ConcurrenHashMap

上面两种方式，我们不推荐使用HashTable，而是推荐使用ConcurrenHashMap。为什么呢？我们需要了解一下HashTable的内部构造，以及它与ConcurrenHashMap的区别。

HashTable是如何保证线程安全的呢？
HashTable保证线程安全的方式是给关键方法加锁：

在这里插入图片描述这相当于直接针对 Hashtable 对象本身加锁.

如果多线程访问同一个 Hashtable 就会直接造成锁冲突.
size 属性也是通过 synchronized 来控制同步, 也是比较慢的.
一旦触发扩容, 就由该线程完成整个扩容过程. 这个过程会涉及到大量的元素拷贝, 效率会非常低.

在这里插入图片描述

那么这里，我们的ConcurrenHashMap就能够解决这个问题。ConcurrenHashMap进行操作的时候，是针对这个元素所在的链表的头节点进行加锁的，如果两个线程操作的是针对两个不同的链表上的元素，那么没有线程安全的问题，不毕加锁。

由于在hash表中，链表的数目非常多,每个链表的长度是相对短的,因此可以保证锁冲突的概率就非常小了。
与上面的hashTable相比，这里的改动影响是非常大的。通过这样一个把大锁化小锁的，化整为零的过程，就可以巧妙的使我们的锁冲突大大降低。

总结：相比于 Hashtable 做出了一系列的改进和优化：

读操作没有加锁(但是使用了 volatile 保证从内存读取结果), 只对写操作进行加锁. 加锁的方式仍是是用 synchronized, 但是不是锁整个对象, 而是 “锁桶” (用每个链表的头结点作为锁对象), 大大降低了锁冲突的概率；
充分利用 CAS 特性. 比如 size 属性通过 CAS 来更新. 避免出现重量级锁的情况；
优化了扩容方式: 化整为零。
对于HashTable来说，只要这次的put触发了扩容,就会导致这次put操作非常卡顿。而对于ConcurrenHashMap来说：