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

文章目录

前言
一、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.1 锁膨胀/锁升级

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

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

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

图示解析：

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

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

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

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

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

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

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

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<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> task = new FutureTask<>(callable);
        Thread t = new Thread(task);
        t.start();
 
        //在 线程t 执行结果之前，get会阻塞，
        //直到 线程t 执行完了，结果算好了，get 才能返回，返回值就是 call方法 return 的内容
        //获取执行结果
        System.out.println(task.get());
    }
}
运行结果：

需要重点理解的是下面一部分代码：
//给 计算结果 一个小票
FutureTask<Integer> 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++ 高很多；

原子类有以下几个：

AtomicBoolean
AtomicInteger
AtomicInterArray
AtomicLong
AtomicReference
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 多线程环境使用队列

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

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

3.3 多线程环境使用哈希表

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

HashTable
ConcurrentHashMap

HashTable

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

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

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

于是，HashTable 就会显得低效 ;

ConcurrentHashMap

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

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

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

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

ConcurrentHashMap 优化特点：

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