Java多线程（四）锁策略（CAS，死锁）和多线程对集合类的使用

锁策略（CAS，死锁）和多线程对集合类的使用

锁策略

1.乐观锁VS悲观锁

2.轻量级锁VS重量级锁

3.自旋锁VS挂起等待锁

4.互斥锁VS读写锁

5.可重入锁vs不可重入锁

死锁的第一种情况

死锁的第二种情况

死锁的第三种情况

CAS

1.实现原子类

2.实现自旋锁

偏向锁：非必要，不加锁

锁消除

锁粗化

Callable 的用法

JUC（ava.util.concurrent）

原子类

信号量 Semaphore

CountDownLatch

多线程对集合类的使用

多线程环境使用顺序表

多线程环境使用队列

多线程环境使用哈希表

其他方面的改进：

更充分的利用了CAS机制--无锁编程

优化了扩容策略

锁策略

上面我说过，锁是为了解决线程冲突的问题。但是我也说过加锁操作会影响程序的效率。（因为阻塞），为了应对这个我们应该合理去进行加锁操作，那么就应该有策略的操作。

1.乐观锁VS悲观锁

乐观锁: 预测接下来冲突概率不大（做的工作少）--->效率会快一些

悲观锁：预测接下了的冲突概率不大（做的多）--->x效率会慢一些

其实这两个就是预测接下来的锁冲突（阻塞等待）的概率是大，还是不大，根据这个冲突的概率，决定接下来怎么做。

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

2.轻量级锁VS重量级锁

轻量级锁：加锁解锁的过程更快更高效。（一个乐观锁很可能是一个轻量级锁）

重量级锁：加锁解锁，过程更慢，更低效。（一个悲观锁很可能是一个重量级锁）

3.自旋锁VS挂起等待锁

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

加锁失败后，不停等待的去问是否可以加锁了

挂起等待锁：是重量级锁的一种典型实现（通过内核机制来实现挂起等待（时间更长了））

加锁失败后，先去做其他事情，等这个锁给我信号后我就回来加锁。

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

而Synchronized 会根据当前锁竞争的激烈程度，自适应；

如果冲突不激烈，以轻量级锁或者乐观锁的状态运行
如果激烈，以重量级锁或悲观锁的状态运行。

4.互斥锁VS读写锁

互斥锁：

synchronized是一个互斥锁，就单纯的加锁。通常只有两种操作：

进入代码块，加锁
出代码块，解锁

读写锁：

有一种锁，把读操作和写操作分开加锁（线程安全）：

给读加锁
给写加锁
解锁

约定：

读锁和读锁之间，不会锁竞争，不会产生冲突（不会影响程序之间的效率）
写锁和写锁之间，有锁竞争（减慢速度，保证准确性）
读锁和写锁之间，有锁竞争（减慢速度，保证准确性）

Java中专门提供了读锁一个类，写锁一个类。

5.可重入锁vs不可重入锁

如果一个锁，在一个线程中，连续对锁，锁了两次，不产生死锁，叫可重入锁。
如果一个锁，在一个线程中，连续对锁，锁了两次，产生死锁，叫不可重入锁。

死锁的第一种情况

如何产生死锁，我们对一个代码加两次锁，此时内部的锁要等待外部的锁释放才能加锁，而此时外部的锁释放，需要等待内部锁加锁成功。然后逻辑上矛盾了，于是产生了死锁。

死锁的第二种情况

两个线程两把锁，即使单个线程是可重入锁，也会死锁。

线程1的外部锁加锁，需要等待线程2内部锁释放，同理线程2外部锁加锁，需要等待线程1内部锁释放，此时逻辑矛盾，产生死锁。

死锁的第三种情况

哲学家，就餐问题（N个线程，M把锁）

一个桌子上有五只筷子。也有五个人，桌上有一碗面，每个人只能用一双筷子吃一口。诺是五个同时拿起一只筷子，场上就构不成一双筷子的条件，也就是谁都吃不了面。此时就死锁了。

怎么办，很简单，五个人约定一个规则，谁先吃，谁后吃，此时就可以避开死锁的情况。

死锁的四个必要条件

互斥使用：一个线程拿到一把锁后，另一个线程不能使用（根本问题锁的基本特点）
不可抢占：一个线程拿到锁，只能自己主动释放，不能是被其他线程强行占有
请求和保持：一个线程拿到一个锁，不去做事，反而想拿到第二把锁。
循环等待：逻辑冲突。谁都拿不到。

实践中如何避免死锁？

对锁进行编号，如果需要获取多把锁，就约定加锁顺序，务必先对编号小的加锁，在对编号大的加锁。

公平锁VS非公平锁

约定：

遵循先来后到，就是公平锁，不遵守先来后到的（等概率竞争是不公平的），非公平锁。

synchronized是非公平的，要实现公平就需要在synchronized的基础上，加个队列来记录这些加锁线程的顺序。

总结一下synchronized的特点：

既是乐观锁，也是悲观锁
既是轻量级锁，也是重量级锁
轻量级锁基于自旋锁实现，重量级锁基于挂起等待实现
不是读写锁
是可重入锁
是非公平锁

CAS

CAS: 全称Compare and swap，字面意思:“比较并交换”，一个 CAS 涉及到以下操作：

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

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

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

3. 返回操作是否成功。

真实的 CAS （即cpu的一条指令）是一个原子的硬件指令完成的（具有原子性），相当于我们不加锁，就能保证线程安全。

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

CAS 可以视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式)

讲到锁操作的时候，我们说过因为一个读一个写的两个线程，他们不会自己去检查变量是否发生过改变。但是CAS却可以进行自检，并返回是否成功。

基于CAS实现的操作：

1.实现原子类

标准库里提供AtomInteger类保证程序的原子性

AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

2.实现自旋锁

通过CAS的自检性，反复检查当前的锁状态，看是否解开了；

但是CAS不是没有问题，最典型的问题A->B->A问题，其实就是我们要内存改变的值与内存的值一样，是得不断在A--B--A中不断横跳。在具体一点就是，两个线程（t1，t2）对数据进行减法，（t3）还有一个对数据进行加法，而加的数据与减的数据一样。

那么就会有一个问题。两个线程中其中一个线程（t1）提前做了减操作，接下来是（t3）加操作，此时内存的值没变，t2线程发现值是原来的值，又做了一次减操作。（这显然不是我们所期望的）

如何解决呢？

加入一个衡量内存的值是否变化的量，俗称版本号，版本号只能增加无法减少，每一次修改版本+1，这样我只需对比版本号本身就可以避免aba问题。

synchronized的锁策略：锁升级

偏向锁：非必要，不加锁

先让线程针对锁，有个标记，如果整个代码执行过程中没有遇到别的线程和我竞争这个所，我就加锁了。但是如果有人来竞争，就升级为真的锁。这样既保证了效率，也保证了线程安全。

锁消除

基础逻辑是，非必要不加锁。编译器+JVM 判断锁是否可消除，如果可以，就直接消除。检测当前代码是否多线程执行，判断是否有必要加锁，如果没有必要，但是又加上了锁，就会在编译过程中自动取消掉。

比如StringBuffer，在源码内加入了synchronized关键字。诺是单线程就必要加锁了，也就可以取消掉。

锁粗化

锁的粒度，synchronized代码块，包含代码的多少（代码越多，粒度越粗，越少，粒度越细），多数情况希望锁的粒度更小。（串行代码少，意味着并发代码就多。）

如果有一个场景需要频繁的加锁解锁，此时就会将整个场景锁起来，变成一个更粗的锁

Callable 的用法

Callable 是一个 interface . 相当于把线程封装了一个 "返回值". 方便程序猿借助多线程的方式计算结果，非常类似于Runnable，只不过返回值不是void，而是泛型

创建线程计算 1 + 2 + 3 + ... + 1000（非callable）

//创建一个类 Result , 包含一个 sum 表示最终结果, lock 表示线程同步使用的锁对象
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() {
//main 方法中先创建 Result 实例, 然后创建一个线程 t. 在线程内部计算 1 + 2 + 3 + ... + 1000
            int sum = 0;
            for (int i = 1; i <= 1000; i++) {
                sum += i;
           }
            synchronized (result.lock) {
                result.sum = sum;
//主线程同时使用 wait 等待线程 t 计算结束
                result.lock.notify();
           }
       }
   };
    t.start();
    synchronized (result.lock) {
        //
        while (result.sum == 0) {
            result.lock.wait();
       }
//当线程 t 计算完毕后, 通过 notify 唤醒主线程, 主线程再打印结果.
        System.out.println(result.sum);
   }
}

创建线程计算 1 + 2 + 3 + ... + 1000（callable）

Callable<Integer> callable = new Callable<Integer>() {
    @Override
    public Integer call() throws Exception {
        int sum = 0;
        for (int i = 1; i <= 1000; i++) {
            sum += i;
       }
        return sum;
   }
};
FutureTask<Integer> futureTask = new FutureTask<>(callable);
Thread t = new Thread(futureTask);
t.start();
int result = futureTask.get();
System.out.println(result);

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

Callable中泛型是什么，就返回什么。

Callable 和 Runnable的区别

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

FutureTask 的理解，其实可以理解为，炖汤，通常炖汤我们将食物放入砂锅中，只需要等待时间过去2-3小时，砂锅就能为我们呈现一锅鲜美的汤。

JUC（ava.util.concurrent）

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

用法:

lock(): 加锁, 如果获取不到锁就死等.
trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁.（加锁失败，不会阻塞，直接返回false，更灵活）
unlock(): 解锁

ReentrantLock 和 Synchronized 的区别:

synchronized 是一个关键字, 是 JVM 内部实现的(大概率是基于 C++ 实现). ReentrantLock 是标准库的一个类, 在 JVM 外实现的(基于 Java 实现).
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更灵活, 但是也容易遗漏 unlock.
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.
synchronized 是非公平锁, ReentrantLock 默认是非公平锁，但是提供了公平和非公平两种工作模式. 可以通过构造方法传入一个 true 开启公平锁模式.
更强大的唤醒机制. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线程.

如何选择使用哪个锁?

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

原子类

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

AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

信号量 Semaphore

本质是一个计数器，描述了当前“可用资源”的个数

P操作，申请资源。计数器-1；
V操作，释放资源。计数器+1；

如果计数器为0，就阻塞等待，等待出现资源时，及继续申请等待。

创建 Semaphore 示例, 初始化为 4, 表示有 4 个可用资源。
acquire 方法表示申请资源(P操作), release 方法表示释放资源(V操作)
创建 20 个线程, 每个线程都尝试申请资源, sleep 1秒之后, 释放资源. 观察程序的执行效果。

Semaphore semaphore = new Semaphore(4);
Runnable runnable = new Runnable() {
    @Override
    public void run() {
        try {
            System.out.println("申请资源");
            semaphore.acquire();
            System.out.println("我获取到资源了");
            Thread.sleep(1000);
            System.out.println("我释放资源了");
            semaphore.release();
       } catch (InterruptedException e) {
            e.printStackTrace();
       }
   }
};
for (int i = 0; i < 20; i++) {
    Thread t = new Thread(runnable);
    t.start();
}

CountDownLatch

同时等待 N 个任务执行结束.

构造 CountDownLatch 实例, 初始化 10 表示有 10 个任务需要完成。
每个任务执行完毕, 都调用 latch.countDown() . 在 CountDownLatch 内部的计数器同时自减。
主线程中使用 latch.await(); （暗中计算有几个countDown被调用了）阻塞等待所有任务执行完毕. 相当于计数器为 0 了。

public class Demo {
    public static void main(String[] args) throws Exception {
        CountDownLatch latch = new CountDownLatch(10);
        Runnable r = new Runable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(Math.random() * 10000);
                    latch.countDown();
               } catch (Exception e) {
                    e.printStackTrace();
               }
           }
       };
        for (int i = 0; i < 10; i++) {
            new Thread(r).start();
       }
   // 必须等到 10 人全部回来
        latch.await();
        System.out.println("比赛结束");

   }
}

多线程对集合类的使用

常用的集合类：ArrayList，LinkedList，HashMap，PriorityQueue。。。线程是不安全的。

如果要使用怎么办？

1.可以手动对集合的修改操作加锁。（synchronized 或者 ReentrantLock）

2.使用java标准库提供的一些线程安全的版本的集合类。

多线程环境使用顺序表

ArrayList可用，Vertor代替，但是vertor该有的方法都用synchronized，是很老的集合，实际场景并不适用。

1.Collections.synchronizedList(new ArrayList);

synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List.
synchronizedList 的关键操作上都带有 synchronized

2.使用 CopyOnWriteArrayList

CopyOnWrite容器即写时复制的容器。

当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，
添加完元素之后，再将原容器的引用指向新的容器。

这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会

添加任何元素。

所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

优点:

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

缺点:

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

多线程环境使用队列

ArrayBlockingQueue 基于数组实现的阻塞队列
LinkedBlockingQueue 基于链表实现的阻塞队列
PriorityBlockingQueue 基于堆实现的带优先级的阻塞队列
TransferQueue 最多只包含一个元素的阻塞队列

多线程使用队列：BlockingQueue

多线程环境使用哈希表

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

Hashtable

是线程安全的，给关键方法加上synchronized，颗粒度比较粗。它对整个哈市表加锁，任何的增删查操作，都会触发加锁，也就意味着会有锁竞争。其实没有必要，哈希表是有桶的，修改值是要通过key计算hash值，然后将新元素放到链表上。

两个线程对不同量进行修改，不会产生冲突，但是由于方法上加了锁也就意味着，两个线程同时使用一个方法会阻塞。（所以不建议）

ConcurrentHashMap

线程是安全的，ConcurrentHashMap不是只有一把锁了，每个桶也就是链表的头结点作为一把，锁，这样针对不同的链表进行操作是不会产生的所冲突。大部分的加锁操作就没有锁冲突。

其他方面的改进：

更充分的利用了CAS机制--无锁编程

有些操作，比如获取或更新某个元素个数，就可以直接使用CAS完成，不必加锁

优化了扩容策略

对于hashTable来说，如果元素太多们就会涉及扩容，诺元素很多很多，上亿个，那么将原表大部分的元素搬到新的位置上，这个操作非常不流畅。所以呢ConcurrentHashMap，在此基础上，诺put触发扩容机制，就会一次性创建更大的内存空间，然后搬运一部分，此时就相当于存在两个hash表，此时对表操作，插入是对新表插入，删除是对旧表（看元素在那个表上）删除，查找是新旧表都查。（每一次操作。都会从旧表搬运一部分到新表）

Hashtable和HashMap、ConcurrentHashMap 之间的区别

HashMap: 线程不安全. key 允许为 null
Hashtable: 线程安全. 使用 synchronized 锁 Hashtable 对象, 效率较低. key 不允许为 null.
ConcurrentHashMap: 线程安全. 使用 synchronized 锁每个链表头结点, 锁冲突概率低, 充分利用CAS 机制. 优化了扩容方式. key 不允许为 null

Java多线程是如何实现数据共享的?