【JavaEE初阶】第二节.多线程( 进阶篇 ) 锁的优化、JUC的常用类、线程安全的集合类

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 

文章目录

• 前言
• 一、synchronized的优化操作
•        1.1 锁膨胀/锁升级
•        1.2 锁消除
•        1.3 锁粗化
• 二、JUC
•         2.1 Callable接口
•         2.2 ReentrantLock类（可重入锁）
•         2.3 原子类
•         2.4 Semaphore类（信号量）
•         2.5 CountDownLatch类
• 三、线程安全的集合类
•         3.1 多线程使用顺序表
•         3.2 多线程环境使用队列
•         3.3 多线程环境使用哈希表

---

---

前言

这篇博客主要介绍 synchronized 的底层工作原理，包括：锁膨胀/锁升级、锁消除、锁粗化 ；并且介绍了 关于JUC的详细知识点 ；以及一些线程安全的集合类 ;

---

一、synchronized的优化操作 

由上一篇博客，我们可以知道，synchronized 使用的锁策略 有以下特点：

1. 既是悲观锁，也是乐观锁（自适应）
2. 既是轻量级锁，也是重量级锁（自适应）
3. 轻量级锁部分基于自旋锁实现，重量级锁部分基于挂起等待锁来实现
4. 不是读写锁
5. 是非公平锁
6. 是可重入锁

1.1 锁膨胀/锁升级

现在，我们需要知道 synchronized 是怎样 自适应的?（这个过程，又叫做 锁膨胀/锁升级） 

synchronized 在加锁的时候要经历几个阶段：

1. 当线程没有加锁的时候，这个阶段叫做 无锁;
2. 当线程刚开始加锁，并没有产生竞争的时候，这个阶段叫做 偏向锁;
3. 当线程进行加锁，并且已经产生锁竞争了，这个阶段叫做 轻量级锁;
4. 如果此时锁竞争的更激烈了，这个阶段叫做 重量级锁;

图示解析：

当然，这几个阶段，并不是说 每一次加锁都会一直加到 最后，可能会到某一阶段之后，就会解锁了；不会每一个阶段都会经历，但会经历到某一部分 ；

像上面的，锁的状态不断的升级，锁的竞争也逐渐加剧 的情况，就叫做 锁膨胀/锁升级；

这里就先重点介绍一下 偏向锁；

所谓偏向锁，并不是 "真正加锁"，而是只使用一个标记表示 "这个锁是我的了"，在遇到其他线程来竞争锁之前，会一直保持着这个状态；

直到真的有线程来竞争锁了，此时才会真正的加锁；

这个过程类似于 单例模式中的 "懒汉模式" —— 在必要的时候进行加锁，从而会节省一定的开销；

因为如果没有额外的线程 来参与锁竞争的话，那么就会一直处于偏向锁的状态，也就省去了加锁和解锁的开销了；

1.2 锁消除

synchronized 除了锁升级，还有其他的优化操作，比如说：锁消除 

所谓锁消除，即 编译器自动锁定，如果认为这个代码没必要加锁，就不加了！！！

代码举例：

StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");
//就比如说，StringBuffer 是线程安全的，它的 append 等方法，都是带有synchronized,
//如果上述代码 都只是在同一个线程里面执行的，那么此时就没有必要加锁了
//此时，JVM 就自动悄悄的把锁给去掉了(这也属于编译器优化的一个方面)

但是，锁消除的操作 不是所有的情况下都会触发，实际上，大部分情况下不能被触发；

而 向偏向锁 则是每一次加锁，都会进入到偏向锁的状态；

1.3 锁粗化

锁粗化，也是 synchronized 的一种优化方式 ；

在这之前，我们需要知道 锁的粒度 这个概念；

所谓 锁的粒度，指的是 synchronized 包含的代码范围是大还是小；

范围越大，粒度越粗 ；范围越小，粒度越细！！！

锁的粒度越细，能够更好的提高线程的并发，但是也会增加 "加锁解锁" 的次数 ；

 锁粗化，也是类似的情况：它把一段代码中，频繁的加锁解锁，"粗化" 成一次加锁解锁了 ；

图示分析：

 毕竟，加锁解锁 也是需要开销的嘛 

 二、JUC

所谓 JUC，实际上指的是：java.util.concurrent，它是一个包；

在这个包里面 存放了很多和多线程开发 的相关的类、接口；

2.1 Callable接口

Callable接口 和 前面的Runnable 非常相似，都是可以在创建线程的时候，来指定一个 "具体的任务" ；

区别是：Callable 指定的任务是带返回值的，Runnable 指定的任务是不带返回值的；

Callable 提供的 call方法，可以方便的获取到代码的执行结果  ；
 

如：创建线程计算 1+2+3+ ... +1000，使用Callable版本 ；

代码示例：

package thread;
 
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
 
public class Demo29 {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Callable callable = new Callable() {
            @Override
            public Integer call() throws Exception {
                int sum = 0;
                for (int i = 1; i <= 1000; i++) {
                    sum += i;
                }
                return sum;
            }
        };
 
        //套上一层，目的是为了获取到后续的结果
        FutureTask task = new FutureTask<>(callable);
        Thread t = new Thread(task);
        t.start();
 
        //在 线程t 执行结果之前，get会阻塞，
        //直到 线程t 执行完了，结果算好了，get 才能返回，返回值就是 call方法 return 的内容
        //获取执行结果
        System.out.println(task.get());
    }
}

运行结果：

需要重点理解的是 下面一部分代码： 

//给 计算结果 一个小票
FutureTask task = new FutureTask<>(callable);

在线程需要计算结果的情况下，需要非常明确的知道 这个结果是谁来算的，不能像以前一样，直接把 callable 加到 Thread 的构造方法之中（之前使用 Runnable 的时候，不需要知道一个明确的结果）：

就类似于，去餐馆吃饭的时候，人多的时候，老板会给一个小票，到时候就可以凭着小票来取餐，不至于搞乱了 ；

2.2 ReentrantLock类（可重入锁）

我们已经知道，synchronized 已经是一个可重入锁了，但是 为啥还要再搞一个 ReentrantLock 呢？ 

实际上，ReentrantLock 还是和 synchronized 之间有很大的差别的：

1.synchronized 是一个单纯的关键字，以代码块为单位进行加锁解锁；ReentrantLock 则是一个类，提供 lock方法 加锁，unlock方法 解锁；

 2.ReentrantLock 在构造实例的时候，可以指定一个 fair参数 来决定锁对象是 公平锁还是非公平锁；synchronized 加的锁只能是非公平锁，不能指定为公平锁

3.ReentrantLock 还提供了一个特殊的加锁操作 —— tryLock() 方法；

4.ReentrantLock 提供了更加强大的 等待/唤醒 机制； 

说明：大部分情况下，使用锁还是以 synchronized 为主，特殊场景下，才使用 ReentrantLock 

2.3 原子类

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

原子类有以下几个：

1. AtomicBoolean
2. AtomicInteger
3. AtomicInterArray
4. AtomicLong
5. AtomicReference
6. AtomicStampedReference

举例说明：

以 AtomicInteger 为例，常见方法有：

addAndGet(int delta);  <=>  i += delta;
decrementAndGet();     <=>  --i;
getAndDecrement();     <=>  i--;
incrementAndGet();     <=>  ++i;
getAndIncrement();     <=>  i++;

2.4 Semaphore类（信号量） 

所谓信号量，可以理解成 计数器，描述了可用资源的个数;

举例说明：

比如说，停车场的入口处，会有牌子（上面显示：当前有车位 N 个）；

当有车开进去以后，N 就会减去一个；当有车从出口开出去以后，N 就会加上一个 ；

这个 N 就叫做 信号量 ；

如果当前 N 已经是 0 了，如果还有车想进来，那就进不去了，新来的车只能阻塞等待，直到有车给开出去 ；

如上所示：

把车开进去，称之为 申请一个可用资源，信号量 -= 1，称为 P 操作 ；

把车开出来，称之为 释放一个可用资源，信号量 +=1，称为 V 操作 ；

其实，信号量 可以把它视为一个 更广义的锁，当信号量的取值是 0~1 的时候，就退化成了一个普通的锁 ；

锁 相当于是一个可用资源是 1 的信号量，只要加锁成功，其他的线程就获取不了 ；

但是，信号量不一样，只要可用资源还有，就可以不断的进行 P 操作 ；

说明：我们需要知道，上面的信号量 +=1，-=1 都是原子的；

---

代码演示：

package thread;
 
import java.util.concurrent.Semaphore;
 
public class Demo31 {
    public static void main(String[] args) throws InterruptedException {
        //构造方法传入有效资源的个数是 3 个
        Semaphore semaphore = new Semaphore(3);
        //P操作 申请资源，使用 acquire方法
        //每一次使用一个资源，信号量 -1
        semaphore.acquire();
        System.out.println("申请资源");
        semaphore.acquire();
        System.out.println("申请资源");
        semaphore.acquire();
        System.out.println("申请资源");
        semaphore.acquire();
        System.out.println("申请资源");
    }
}

 运行结果：

有效资源是 3 份，即使 想要申请4份资源，但是在运行结果中显示，最终只是申请了 3 份资源 ；

只有前面的线程把资源释放了，才可以使用 ；

代码示例：

package thread;
 
import java.util.concurrent.Semaphore;
 
public class Demo31 {
    public static void main(String[] args) throws InterruptedException {
        //构造方法传入有效资源的个数是 3 个
        Semaphore semaphore = new Semaphore(3);
        //P操作 申请资源，使用 acquire方法
        //每一次使用一个资源，信号量 -1
        semaphore.acquire();
        System.out.println("申请资源");
        semaphore.acquire();
        System.out.println("申请资源");
        semaphore.acquire();
        System.out.println("申请资源");
        //V操作 释放资源，使用 release 方法
        //此时，信号量 = 0,线程进入阻塞，只有释放资源，线程才可以继续运行
        semaphore.release();
        System.out.println("释放资源成功");
        semaphore.acquire();
        System.out.println("申请资源成功");
        
    }
}

运行结果：

2.5 CountDownLatch类 

CountDownLatch类，相当于 在一个大的任务被拆分成若干个子任务的时候，用这个来衡量 什么时候这些子任务都执行结束 ；

举个例子：

此时在某地正在进行一场跑步比赛，只有当所以选手都到达终点的时候，裁判才可以吹哨结束比赛 ；

CountDownLatch 描述的就是啥时候所有选手都到达终点 ；

代码示例：

package thread;
 
import java.util.concurrent.CountDownLatch;
 
public class Demo32 {
    public static void main(String[] args) throws InterruptedException {
        //模拟跑步比赛
        //构造方法中设定有 10 个选手参赛
        CountDownLatch latch = new CountDownLatch(10);
        for (int i = 0; i < 10; i++) {
            Thread t = new Thread(() -> {
                try {
                    Thread.sleep(3000);
                    System.out.println(Thread.currentThread().getName()+" 到达终点");
                    //countDown 相当于 "撞线"
                    latch.countDown();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
            t.start();
        }
        //await 再等待所有的线程都 "撞线"
        //换句话说，调用 countDown 的次数达到初始化的时候 设定的值，
        //await 就返回，否则 await 就阻塞等待
        latch.await();
 
        System.out.println("比赛结束");
    }
}

运行结果：

 三、线程安全的集合类

原来的集合类，大部分都是 线程不安全的 ；

换句话来说，大部分集合类在多线程环境下使用 都是有问题的 ；

总结：

ArrayList、LinkedList、TreeSet、TreeMap、HashSet、HashMap、Queue 是线程不安全的；

Vector、Stack、HashTable 是线程安全的 ；

3.1 多线程使用顺序表 

（一）自己使用加锁操作

（二）使用 Collections.synchronizedList (new ArrayList);

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

synchronizedList 的关键操作上都带有 synchronized ；

（三）使用 CopyOnWriteArrayList；

如果出现修改操作，就把 Ar rayList 进行复制 ;

先拷贝一份数据（创建一份副本），再接着新线程修改副本，修改完成后，再用副本替换原有的数据 ;

这就叫做 写实拷贝 ;

不过这种行为的 拷贝成本可能会很高，所以 一般元素个数多的时候会用到 ;

3.2 多线程环境使用队列 

多线程环境下常常使用以下阻塞队列：

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

3.3 多线程环境使用哈希表 

HashMap本身不是线程安全的，在多线程环境下可以使用：

1. HashTable
2. ConcurrentHashMap

HashTable

---

其中，HashTable 直接搞了一个大锁，这就导致了 在多个线程去修改上面的元素 的时候，都需要去进行加锁控制，就会有锁冲突，比较低效： 

对于两个不同的哈希桶上的元素，不牵扯修改同一个变量，就不会发生线程安全问题（此时加锁的话，意义不大）；

但是，如果两个修改涉及到同一个哈希桶上，就会有线程安全问题 ;

于是，HashTable 就会显得低效 ;

ConcurrentHashMap

相比之下，ConcurrentHashMap类 做出了重大的改进 —— 把锁的粒度细化了！！！

接下来介绍的 ConcurrentHashMap类 基于 java 1.8 的 ;

该类是基于哈希表中的每一个链表对象进行加锁，线程需要对哪个链表对象进行操作，就在哪里加锁;

由于哈希表中链表数量很多，链表对象的元素个数较少，可以有效地降低锁竞争的概率 ;

 ConcurrentHashMap 优化特点：

[ 最重要 ] 把锁的粒度细化，降低锁冲突的概率;
有一个激进的操作：读没加锁，写才加锁;
更充分的使用了 CAS 特性，达到一个更高效的操作（如 维护 size 的时候）;
针对扩容场景进行了优化（化整为零，不会一口气的完成扩容；而是 每次基本操作，都扩容一点点，逐渐完成整个扩容 —— 不会特别卡）; 

总结

今天的关于多线程( 进阶篇 ) 锁的优化、JUC的常用类、线程安全的集合类就讲到这里，我们下一节内容再见！！！！