一、Java 线程基础

1、线程创建

Thread

Runnable

• 直接使用 Thread 是重写了 run 方法

• Thread 是把线程和任务合并在了一起，Runnable 是把线程和任务分开了

• 用 Runnable 更容易与线程池等高级 API 配合

• 用 Runnable 让任务类脱离了 Thread 继承体系（解耦），更灵活（组合优于继承）

• 同一个 Runnable 线程任务对象可以被包装成多个线程对象，适合多个多个线程去共享同一个资源

Callable

• FutureTask 就是 Runnable 对象，因为 Thread 类只能执行 Runnable 实例的任务对象，所以把 Callable 包装成 FutureTask 对象

• public V get()：同步等待 task 执行完毕的结果，如果在线程中获取另一个线程执行结果，会阻塞等待，用于线程同步
• get() 线程会阻塞等待任务执行完成
• run() 执行完后会把结果设置到 FutureTask 的一个成员变量，get() 线程可以获取到该变量的值

2、线程方法

API

start 与 run

• run：称为线程体，包含了要执行的这个线程的内容，方法运行结束，此线程随即终止。直接调用 run 是在主线程中执行了 run，没有启动新的线程，需要顺序执行

• start：使用 start 是启动新的线程，此线程处于就绪 Runnable（可运行）状态，通过新的线程间接执行 run 中的代码

• 因为父类中没有抛出任何异常，子类不能比父类抛出更多的异常

• 异常不能跨线程传播回 main() 中，因此必须在本地进行处理

sleep 与 yield

• 调用 sleep 会让当前线程从 Running 进入 Timed Waiting 状态（阻塞）

• 调用方式：Thread.sleep()

• sleep() 方法的过程中，会放弃 CPU 资源，锁资源不会释放

• 其它线程可以使用 interrupt 方法打断正在睡眠的线程，这时 sleep 方法会抛出 InterruptedException

• 睡眠结束后的线程未必会立刻得到执行，需要抢占 CPU

• 建议用 TimeUnit 的 sleep 代替 Thread 的 sleep 来获得更好的可读性

• 调用 yield 会让提示线程调度器让出当前线程对 CPU 的使用，从 Running 进入 Runnable 就绪状态

• 调用方式：Thread.yield()

• 具体的实现依赖于操作系统的任务调度器

• 会放弃 CPU 资源，锁资源不会释放

join

• join 方法是被 synchronized 修饰的，本质上是一个对象锁，其内部的 wait 方法调用也是释放锁的，但是释放的是当前的线程对象锁，而不是外面的锁

interrupt

• public void interrupt()：打断这个线程，异常处理机制

• public static boolean interrupted()：判断当前线程是否被打断，打断返回 true，清除打断标记，连续调用两次一定返回 false

• public boolean isInterrupted()：判断当前线程是否被打断，不清除打断标记

• 会清除打断标记，即置为 false

• 不会清除打断标记，即仍为 true

• park 作用类似 sleep，打断 park 线程，不会清空打断状态（true）

• 如果打断标记已经是 true, 则 park 会失效
• 将 isInterrupted 方法改为 interrupted 方法，会将标记重置为false，即后面的 park 会生效

• 使用线程对象的 stop() 方法停止线程：stop 方法会真正杀死线程，如果这时线程锁住了共享资源，当它被杀死后就再也没有机会释放锁，其它线程将永远无法获取锁

• 使用 System.exit(int) 方法停止线程：目的仅是停止一个线程，但这种做法会让整个程序都停止

• 阻塞时被打断：会重置标记为false，需在抛异常后重置标记为true

• 正常运行时被打断

daemon

• 用户线程：平常创建的普通线程

• 守护线程：服务于用户线程，只要其它非守护线程运行结束了，即使守护线程代码没有执行完，也会强制结束。守护进程是脱离于终端并且在后台运行的进程，脱离终端是为了避免在执行的过程中的信息在终端上显示

• 垃圾回收器线程就是一种守护线程

• Tomcat 中的 Acceptor 和 Poller 线程都是守护线程，所以 Tomcat 接收到 shutdown 命令后，不会等待它们处理完当前请求

不推荐

• public final void stop()：停止线程运行
废弃原因：方法粗暴，除非可能执行 finally 代码块以及释放 synchronized 外，线程将直接被终止，如果线程持有 JUC 的互斥锁可能导致锁来不及释放，造成其他线程永远等待的局面

• public final void suspend()：挂起（暂停）线程运行
废弃原因：如果目标线程在暂停时对系统资源持有锁，则在目标线程恢复之前没有线程可以访问该资源，如果恢复目标线程的线程在调用 resume 之前会尝试访问此共享资源，则会导致死锁

• public final void resume()：恢复线程运行

3、线程状态

• NEW → RUNNABLE：当调用 t.start() 方法时，由 NEW → RUNNABLE

• RUNNABLE <—> WAITING：
• 调用 obj.wait() 方法时，t 线程从 RUNNABLE —> WAITING
• 调用 obj.notify()、obj.notifyAll()、t.interrupt()：
• 竞争锁成功，t 线程从 WAITING —> RUNNABLE
• 竞争锁失败，t 线程从 WAITING —> BLOCKED
• 当前线程调用 t.join() 方法，注意是当前线程（例如main线程）在 t 线程对象的监视器上等待
• 当前线程调用 LockSupport.park() 方法，当前线程从 RUNNABLE —> WAITING

• RUNNABLE <--> TIMED_WAITING：调用 obj.wait(long n) 方法、当前线程调用 t.join(long n) 方法、当前线程调用 Thread.sleep(long n)

• RUNNABLE <--> BLOCKED：t 线程用 synchronized(obj) 获取了对象锁时竞争失败，进入锁对象的 entryList 阻塞

二、管程

• 阻塞式的解决方案：synchronized，lock

• 非阻塞式的解决方案：原子变量

0、线程安全分析

• 没有共享，线程安全

• 被共享
• 只读，线程安全
• 读写，非线程安全

• 局部变量线程安全

• 局部变量引用的对象不一定线程安全
• 没有逃离方法作用域，线程安全
• 逃离方法作用域，非线程安全
• 例如：局部变量引用的对象被子类重写方法进行了写操作

• 若无状态，则线程安全

1、synchronized

锁使用

• 互斥是保证临界区的竞态条件发生，同一时刻只能有一个线程执行临界区代码

• 同步是由于线程执行的先后、顺序不同、需要一个线程等待其它线程运行到某个点

• 同步代码块
• 对象锁
• 类锁

• 同步方法
• 静态方法 class
• 非静态方法 this
• synchronized 修饰的方法的不具备继承性，所以子类是线程不安全的，如果子类的方法也被synchronized 修饰，两个锁对象其实是一把锁，而且是子类对象作为锁

锁原理

• mark word + class 指针

• 32 位虚拟机

• 64 位虚拟机

• 管程，监视器，操作系统里的概念

• 每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针，这就是重量级锁

1. 开始时 Monitor 中 Owner 为 null

2. 当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor 中只能有一个 Owner，obj 对象的 Mark Word 指向 Monitor，把对象原有的 MarkWord 存入线程栈中的锁记录中（轻量级锁部分详解）

3. 在 Thread-2 上锁的过程，Thread-3、Thread-4、Thread-5 也执行 synchronized(obj)，就会进入 EntryList BLOCKED（双向链表）

4. Thread-2 执行完同步代码块的内容，根据 obj 对象头中 Monitor 地址寻找，设置 Owner 为空，把线程栈的锁记录中的对象头的值设置回 MarkWord

5. 唤醒 EntryList 中等待的线程来竞争锁，竞争是非公平的，如果这时有新的线程想要获取锁，可能直接就抢占到了，阻塞队列的线程就会继续阻塞

6. WaitSet 中的 Thread-0，是以前获得过锁，但条件不满足进入 WAITING 状态的线程（wait-notify 机制）

• synchronized 必须是进入同一个对象的 Monitor 才有上述的效果

• 不加 synchronized 的对象不会关联 Monitor，不遵从以上规则

• 线程获取到锁和释放锁会有obj对象头mark word 与线程栈帧锁记录数据的交换

• 通过异常 try-catch 机制，确保一定会被解锁

• 方法级别的 synchronized 不会在字节码指令中有所体现

锁升级过程

• 随着竞争的增加，只能锁升级，不能降级

轻量级锁

• 一个对象有多个线程要加锁，但加锁的时间是错开的（没有竞争），可以使用轻量级锁来优化，轻量级锁对使用者是透明的（不可见）

• 可重入锁：线程可以进入任何一个它已经拥有的锁所同步着的代码块，可重入锁最大的作用是避免死锁

• 轻量级锁在没有竞争时（锁重入时），每次重入仍然需要执行 CAS 操作，Java 6 才引入的偏向锁来优化

• 创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结构，存储锁定对象的 Mark Word（01无锁，00轻量级锁）

• 让锁记录中 Object reference 指向锁住的对象，并尝试用 CAS 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录

• 如果 CAS 替换成功，对象头中存储了锁记录地址和状态 00（轻量级锁） ，表示由该线程给对象加锁

• 如果 CAS 失败，有两种情况：
• 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
• 如果是线程自己执行了 synchronized 锁重入，就添加一条 Lock Record 作为重入的计数
• 每次重入都会添加一个锁记录，锁记录个数就是重入次数
• 除了第一个锁记录会存储对象头 mark word 外，其他锁记录只会存储 null

• 当退出 synchronized 代码块（解锁时）
• 如果有取值为 null 的锁记录，表示有重入，这时重置锁记录（即释放这个锁记录内容），表示重入计数减 1
• 如果锁记录的值不为 null，这时使用 CAS 将 Mark Word 的值恢复给对象头
• 成功，则解锁成功
• 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

重量级锁（锁膨胀）

• 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁

• Thread-1 加轻量级锁失败，进入锁膨胀流程：为 Object 对象申请 Monitor 锁，通过 Object 对象头获取到持锁线程，将 Monitor 的 Owner 置为 Thread-0，将 Object 的对象头指向重量级锁地址，然后自己进入 Monitor 的 EntryList BLOCKED

• 当 Thread-0 退出同步块解锁时，使用 CAS 将 Mark Word 的值恢复给对象头失败，这时进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程

偏向锁

轻量级锁没有竞争时，每次重入都要进行 CAS 操作，因此 Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

• 当锁对象第一次被线程获得的时候进入偏向状态，标记为 101，同时使用 CAS 操作将线程 ID 记录到 Mark Word。如果 CAS 操作成功，这个线程以后进入这个锁相关的同步块，查看这个线程 ID 是自己的就表示没有竞争，就不需要再进行任何同步操作

• 当有另外一个线程去尝试获取这个锁对象时，偏向状态就宣告结束，此时撤销偏向（Revoke Bias）后恢复到未锁定或轻量级锁状态

• 如果开启了偏向锁（默认开启），那么对象创建后，MarkWord 值为 0x05 即最后 3 位为 101，thread、epoch、age 都为 0

• 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 XX:BiasedLockingStartupDelay=0 来禁用延迟。JDK 8 延迟 4s 开启偏向锁原因：在刚开始执行代码时，会有好多线程来抢锁，如果开偏向锁效率反而降低

• 当一个对象已经计算过 hashCode，就再也无法进入偏向状态了

• 添加 VM 参数 XX:-UseBiasedLocking 禁用偏向锁

• 调用对象的 hashCode：偏向锁的对象 MarkWord 中存储的是线程 id，调用 hashCode 导致偏向锁被撤销

• 当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁

• 调用 wait/notify，需要申请 Monitor，进入 WaitSet

• 批量重偏向：当撤销偏向锁阈值超过 20 次后，JVM 会觉得是不是偏向错了，于是在给这些对象加锁时重新偏向至加锁线程

• 批量撤销：当撤销偏向锁阈值超过 40 次后，JVM 会觉得自己确实偏向错了，根本就不该偏向，于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

锁优化-自旋锁

• 自旋占用 CPU 时间，单核 CPU 自旋就是浪费时间，因为同一时刻只能运行一个线程，多核 CPU 自旋才能发挥优势

• 自旋失败的线程会进入阻塞状态

• 在 Java 6 之后自旋锁是自适应的，若一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，比较智能

• Java 7 之后不能控制是否开启自旋功能，由 JVM 控制

锁优化-锁消除

• 可使用 jvm 参数 -XX:-EliminateLocks 关闭锁消除优化（默认开启）

锁优化-锁粗化

多把锁

• 好处，是可以增强并发度

• 坏处，如果一个线程需要同时获得多把锁，就容易发生死锁

活跃性

1. 互斥条件，即当资源被一个线程使用（占有）时，别的线程不能使用

2. 不可剥夺条件，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放

3. 请求和保持条件，即当资源请求者在请求其他的资源的同时保持对原有资源的占有

4. 循环等待条件，即存在一个等待循环队列：p1 要 p2 的资源，p2 要 p1 的资源，形成了一个等待环路

• Linux 下可以通过 top 先定位到 CPU 占用高的 Java 进程，再利用 top -Hp 进程id 来定位是哪个线程，最后再用 jstack <pid>的输出来看各个线程栈

• 避免死锁：避免死锁要注意加锁顺序

• 可以使用 jconsole 工具，在 jdk\bin 目录下

2、wait & notify

基本 API

• notify：从 monitor 的 waitSet 随机唤醒一个

• notifyAll：从 monitor 的 waitSet 唤醒全部

• wait：使线程进入 monitor 的 waitSet 等待，直到调用 notify 方法唤醒

• wait(n)：有时限等待，超过时间未被唤醒，不会继续等待，会继续进入 entryList 等待抢占锁

底层原理

• Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态

• BLOCKED 和 WAITING 的线程都处于阻塞状态，不占用 CPU 时间片

• BLOCKED 线程会在 Owner 线程释放锁时唤醒

• WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，唤醒后并不意味者立刻获得锁，需要进入 EntryList 重新竞争

与 Sleep 对比

• 类所属不同：sleep() 方法是属于 Thread 类，wait() 方法属于 Object 类，用于线程间通信

• 锁处理机制不同：sleep() 方法不会释放对象锁， wait() 方法线程会放弃对象锁，进入锁对象 monitor 的 waitSet；都会释放 CPU

• 使用区域不同：wait() 方法必须放在同步控制方法和同步代码块（先获取锁）中使用，sleep() 方法则可以放在任何地方使用

• 相同点：线程状态都是 TIMED_WAITING

虚假唤醒及解决优化

使用模板

3、join 原理

• join 是等待另一个线程结束，而保护性暂停时等待另一个线程结果

• 同样 while 防止虚假唤醒

4、park & unpark

基本使用

• LockSupport.park()：暂停当前线程，挂起原语

• LockSupport.unpark(暂停的线程对象)：恢复某个线程的运行

与 wait notify 对比

• wait，notify 和 notifyAll 必须配合 Object Monitor 一起使用，而 park、unpark 不需要

• park & unpark 以线程为单位来阻塞和唤醒线程，而 notify 只能随机唤醒一个等待线程，notifyAll 是唤醒所有等待线程

• park & unpark 可以先 unpark，而 wait & notify 不能先 notify。

• wait 会释放锁资源进入等待队列，park 不会释放锁资源，只负责阻塞当前线程，会释放 CPU

原理

1. 当前线程调用 Unsafe.park() 方法

2. 检查 _counter ，本情况为 0，这时获得 _mutex 互斥锁

3. 线程进入 _cond 条件变量挂起

4. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1

5. 唤醒 _cond 条件变量中的 Thread_0，Thread_0 恢复运行，设置 _counter 为 0

1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1

2. 当前线程调用 Unsafe.park() 方法

3. 检查 _counter ，本情况为 1，这时线程无需挂起，继续运行，设置 _counter 为 0

5、同步模式

单任务保护性暂停

• 有一个结果需要从一个线程传递到另一个线程，让它们关联同一个 GuardedObject

• 如果有结果不断从一个线程到另一个线程那么可以使用消息队列（见生产者/消费者）

• JDK 中，join 的实现、Future 的实现，采用的就是此模式

• 已知传入的最大等待时间 millis，需要积累开始时间 begin、已经等待时间 timePassed

• 为防止 while 循环多等待，因此需要再进入 while 后首先判断还需要等待的时间 millis - timePassed，不需要等待则直接 break

• 若还没有到最大等待时间则继续等待 millis - timePassed

• 若在 wait 时被提前唤醒，条件还不满足则继续等待 millis - timePassed

多任务保护性暂停

• 居民：既充当写信人也充当收信人

• 邮箱：存放邮件

• 邮员：从邮箱取对应邮件，一对一

• 邮件：response 结果，传递的资源

顺序输出

交替输出

• 用一个三种状态的标记标识即可

• 上一个线程执行完毕后将标记改为下一个要执行的标记即可

• 三个条件变量可代替 wait notify 的 flag 标记

• 刚开始三个线程分别在对应条件队列等待

• 一秒后主线程唤醒 a 开始循环

• 三个线程先 park 等待

• 一秒后主线程唤醒 a 线程进行循环

6、异步模式

生产者消费者

• 与前面的保护性暂停中的 GuardObject 不同，不需要产生结果和消费结果的线程一一对应

• 消费队列可以用来平衡生产和消费的线程资源

• 生产者仅负责产生结果数据，不关心数据该如何处理，而消费者专心处理结果数据

• 消息队列是有容量限制的，满时不会再加入数据，空时不会再消耗数据

• JDK 中各种阻塞队列，采用的就是这种模式

三、内存

1、JMM 内存模型

• 主内存：存储所有共享变量的值

• 工作内存：存储该线程使用到的共享变量在主内存的的值的副本拷贝

2、可见性

• 使用 volatile 关键字修饰变量即可，可强制线程去主存读取最新值；轻量级操作

• 或使用 synchronized 进行加锁，重量级操作

3、原子性

4、有序性

5、volatile

概述

• 保证可见性

• 不保证原子性（指令交错）

• 保证有序性（禁止指令重排）

• 有序性：加了锁之后，只能有一个线程获得到了锁，获得不到锁的线程就要阻塞，所以同一时间只有一个线程执行，相当于单线程，由于数据依赖性的存在，单线程的指令重排是没有问题的

• 可见性：线程加锁前，将清空工作内存中共享变量的值，使用共享变量时需要从主内存中重新读取最新的值；线程解锁前，必须把共享变量的最新值刷新到主内存中

原理

• 对 volatile 变量的写指令后会加入写屏障

• 对 volatile 变量的读指令前会加入读屏障

• 确保对内存的读-改-写操作原子执行

• 有序性：阻止屏障两侧的指令重排序

• 可见性：强制把缓存中的脏数据写回主内存，让缓存行中相应的数据失效

• 写屏障保证在该屏障之前的，对共享变量的改动，都同步到主存当中

• 读屏障保证在该屏障之后的，对共享变量的读取，从主存刷新变量值，加载的是主存中最新数据

• 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

• 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

• 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证其他线程的读跑到写屏障之前

• 有序性的保证也只是保证了本线程内相关代码不被重排序

6、happen-before

1. 程序次序规则 (Program Order Rule)：一个线程内，逻辑上书写在前面的操作先行发生于书写在后面的操作 ，因为多个操作之间有先后依赖关系，则不允许对这些操作进行重排序

2. 锁定规则 (Monitor Lock Rule)：一个 unlock 操作先行发生于后面（时间的先后）对同一个锁的 lock 操作，所以线程解锁 m 之前对变量的写（解锁前会刷新到主内存中），对于接下来对 m 加锁的其它线程对该变量的读可见

3. volatile 变量规则 (Volatile Variable Rule)：对 volatile 变量的写操作先行发生于后面对这个变量的读

4. 传递规则 (Transitivity)：具有传递性，如果操作 A 先行发生于操作 B，而操作 B 又先行发生于操作 C，则可以得出操作 A 先行发生于操作 C

5. 线程启动规则 (Thread Start Rule)：Thread 对象的 start()方 法先行发生于此线程中的每一个操作

6. 线程中断规则 (Thread Interruption Rule)：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生

7. 线程终止规则 (Thread Termination Rule)：线程中所有的操作都先行发生于线程的终止检测，可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值手段检测到线程已经终止执行

8. 对象终结规则（Finaizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始

7、两阶段终止模式改进

四、无锁

1、CAS

简介

• CAS 并发原语体现在 Java 语言中就是 sun.misc.Unsafe 类的各个方法，调用 UnSafe 类中的 CAS 方法，JVM 会实现出 CAS 汇编指令，这是一种完全依赖于硬件的功能，实现了原子操作

• CAS 是一种系统原语，原语属于操作系统范畴，是由若干条指令组成 ，用于完成某个功能的一个过程，并且原语的执行必须是连续的，执行过程中不允许被中断，所以 CAS 是一条 CPU 的原子指令，不会造成数据不一致的问题，是线程安全的

• 程序是在单核处理器上运行，会省略 lock 前缀，单处理器自身会维护处理器内的顺序一致性，不需要 lock 前缀的内存屏障效果

• 程序是在多核处理器上运行，会为 cmpxchg 指令加上 lock 前缀。当某个核执行到带 lock 的指令时，CPU 会执行总线锁定或缓存锁定，将修改的变量写入到主存，这个过程不会被线程的调度机制所打断，保证了多个线程对内存操作的原子性

特点

• CAS 体现的是无锁并发、无阻塞并发，线程不会陷入阻塞，线程不需要频繁切换状态（上下文切换，系统调用）

• CAS 是基于乐观锁的思想

• CAS 由于要获取共享变量的最新值，因此共享变量一定要使用 volatile 修饰，CAS 必须借助 volatile 才能读取到共享变量的最新值来实现【比较并交换】的效果

缺点

• 执行的是循环操作，如果比较不成功一直在循环，最差的情况某个线程一直取到的值和预期值都不一样，就会无限循环导致饥饿，使用 CAS 线程数不要超过 CPU 的核心数，采用分段 CAS 和自动迁移机制
• 竞争激烈重试必然频繁发生，效率会有影响

• 只能保证一个共享变量的原子操作
• 对于一个共享变量执行操作时，可以通过循环 CAS 的方式来保证原子操作
• 对于多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候只能用锁来保证原子性

• 会有 ABA 问题

2、原子类 Atomic

原子整数

• public AtomicInteger()：初始化一个默认值为 0 的原子型 Integer

• public AtomicInteger(int initialValue)：初始化一个指定值的原子型 Integer

原子引用

• 构造方法：AtomicReference<T> atomicReference = new AtomicReference<T>()

• 常用 API：
• public final boolean compareAndSet(V expectedValue, V newValue)：CAS 操作
• public final void set(V newValue)：将值设置为 newValue
• public final V get()：返回当前值

原子数组

原子更新器

• static <U> AtomicIntegerFieldUpdater<U> newUpdater(Class<U> c, String fieldName)：构造方法

• abstract boolean compareAndSet(T obj, int expect, int update)：CAS

原子累加器

• LongAddr 与 LongAccumulator 类都是使用非阻塞算法 CAS 实现的

• LongAddr 类是 LongAccumulator 类的一个特例，只是 LongAccumulator 提供了更强大的功能，可以自定义累加规则，当accumulatorFunction 为 null 时就等价于 LongAddr

• 调用 casBase 时，LongAccumulator 使用 function.applyAsLong(b = base, x) 来计算，LongAddr 使用 casBase(b = base, b + x)

• LongAccumulator 类功能更加强大，构造方法参数中
• accumulatorFunction 是一个双目运算器接口，可以指定累加规则，比如累加或者相乘，其根据输入的两个参数返回一个计算值，LongAdder 内置累加规则
• identity 则是 LongAccumulator 累加器的初始值，LongAccumulator 可以为累加器提供非0的初始值，而 LongAdder 只能提供默认的 0

3、原子累加器 Adder 原理

原子累加器要比原子整数做相同的累加类操作时快很多，原因在下方解析：

优化机制

• 在发生竞争时，创建 Cell 数组用于将不同线程的操作离散（通过 hash 等算法映射）到不同的节点上

• 设置多个累加单元（会根据需要扩容，最大为 CPU 核数），Therad-0 累加 Cell[0]，而 Thread-1 累加 Cell[1] 等，最后将结果汇总

• 在累加时操作的不同的 Cell 变量，因此减少了 CAS 重试失败，从而提高性能

伪共享

源码分析

• cells 占用内存是相对比较大的，是惰性加载的，在无竞争或者其他线程正在初始化 cells 数组的情况下，直接更新 base 域

• 在第一次发生竞争时（casBase 失败）会创建一个大小为 2 的 cells 数组，将当前累加的值包装为 Cell 对象，放入映射的槽位上

• 分段累加的过程中，如果当前线程对应的 cells 槽位为空，就会新建 Cell 填充，如果出现竞争，就会重新计算线程对应的槽位，继续自旋尝试修改

• 分段迁移后还出现竞争就会扩容 cells 数组长度为原来的两倍，然后 rehash，数组长度总是 2 的 n 次幂，默认最大为 CPU 核数，但是可以超过，如果核数是 6 核，数组最长是 8

• LongAdder#add：累加方法

• Striped64#longAccumulate：cell 数组创建

4、UnSafe

5、不可变

• 类用 final 修饰保证了该类中的方法不能被覆盖，防止子类无意间破坏不可变性

• 无写入方法（set）确保外部不能对内部属性进行修改

• 属性用 final 修饰保证了该属性是只读的，不能修改

• 更改 String 类数据时，会构造新字符串对象，生成新的 char[] value，通过创建副本对象来避免共享的方式称之为保护性拷贝

6、final 原理

• 数据同步到主存，保证可见性

• 防止屏障上方代码重排到下方

• 数值较小会复制一份放入栈中直接访问，指令为bipush，效率高

• 大于 short 最大值会将其复制到类的常量池，访问时从常量池获取，指令为ldc

• 不使用 final 修饰，指定为 getstatic ，需要从共享内存获取，效率低

7、享元模式

8、无状态

五、线程池

1、自定义线程池

阻塞队列实现

• 实现阻塞获取方法 task()

• 实现带超时阻塞获取方法 poll()

• 实现阻塞插入方法 put()

• 实现带超时阻塞插入方法 offer()

线程池ThreadPool实现

• 线程池持有任务队列、线程集合、核心线程数、超时时间、时间单位

• 由于线程池的线程要实现复用，因此使用Worker将其包装一层
• worker 线程会在持有的任务Runnable task 不为空或者线程池持有的任务队列不为空时持续执行任务
• 当二者都为空时，如果使用阻塞的 task() 方法会一直阻塞等待队列直到有元素出现，也可以替换为 poll() 方法超时后退出循环
• 当退出循环时候将当前worker 线程释放，即从workers集合移除即可
• 由于worker 集合为hashSet，因此需要加锁处理来保证线程安全性

• 实现线程池的执行 execute 方法
• 当workers集合的线程数小于核心线程数时，可以新创建worker线程，加入集合，随后启动本线程
• 否则，即待执行任务数超过已存在的核心线程数时，将任务线程加入任务队列进行等待。

拒绝策略

当任务数超过核心线程数时，需要给用户一个选择来决定超量的任务该如何处理，因此这里可以使用策略模式来实现这个逻辑。

• 若队列容量已满，使用拒绝策略处理

• 否则，加入任务队列，唤醒消费者来消费即可

测试

由调用者实现几种拒绝策略：

2、ThreadPoolExecutor

线程池状态

线程池创建

• corePoolSize：核心线程数，定义了最小可以同时运行的线程数量

• maximumPoolSize：最大线程数，当队列中存放的任务达到队列容量时，当前可以同时运行的数量变为最大线程数，创建线程并立即执行最新的任务，与核心线程数之间的差值又叫救急线程数

• keepAliveTime：救急线程最大存活时间，当线程池中的线程数量大于 corePoolSize 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等到 keepAliveTime 时间超过销毁

• unit：keepAliveTime 参数的时间单位

• workQueue：阻塞队列，存放被提交但尚未被执行的任务

• threadFactory：线程工厂，创建新线程时用到，可以为线程创建时起名字

• handler：拒绝策略，线程到达最大线程数仍有新任务时会执行拒绝策略
RejectedExecutionHandler 下有 4 个实现类：
• AbortPolicy：让调用者抛出 RejectedExecutionException 异常，默认策略
• CallerRunsPolicy：让调用者运行的调节机制，将某些任务回退到调用者，从而降低新任务的流量
• DiscardPolicy：直接丢弃任务，不予任何处理也不抛出异常
• DiscardOldestPolicy：放弃队列中最早的任务，把当前任务加入队列中尝试再次提交当前任务
补充：其他框架拒绝策略
• Dubbo：在抛出 RejectedExecutionException 异常前记录日志，并 dump 线程栈信息，方便定位问题
• Netty：创建一个新线程来执行任务
• ActiveMQ：带超时等待（60s）尝试放入队列
• PinPoint：它使用了一个拒绝策略链，会逐一尝试策略链中每种拒绝策略

工作原理

1. 创建线程池，这时没有创建线程（懒惰），等待提交过来的任务请求，调用 execute 方法才会创建线程

2. 当调用 execute() 方法添加一个请求任务时，线程池会做如下判断：
• 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务
• 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列
• 如果这时队列满了且正在运行的线程数量还小于 maximumPoolSize，那么会创建非核心线程立刻运行这个任务，对于阻塞队列中的任务不公平。这是因为创建每个 Worker（线程）对象会绑定一个初始任务，启动 Worker 时会优先执行
• 如果队列满了且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会启动饱和拒绝策略来执行

3. 当一个线程完成任务时，会从队列中取下一个任务来执行

4. 当一个线程空闲超过一定的时间（keepAliveTime）时，线程池会判断：如果当前运行的线程数大于 corePoolSize，那么这个线程就被停掉，所以线程池的所有任务完成后最终会收缩到 corePoolSize 大小

3、Executors 工具类

Executors

• newFixedThreadPool：创建一个拥有 n 个线程的线程池
• 核心线程数 == 最大线程数（没有救急线程被创建），因此也无需超时时间
• LinkedBlockingQueue 是一个单向链表实现的阻塞队列，默认大小为 Integer.MAX_VALUE，也就是无界队列，可以放任意数量的任务，在任务比较多的时候会导致 OOM（内存溢出）
• 适用于任务量已知，相对耗时的长期任务

• newCachedThreadPool：创建一个可扩容的线程池
• 核心线程数是 0， 最大线程数是 29 个 1，全部都是救急线程（60s 后可以回收），可能会创建大量线程，从而导致 OOM
• SynchronousQueue 作为阻塞队列，没有容量，对于每一个 take 的线程会阻塞直到有一个 put 的线程放入元素为止（类似一手交钱、一手交货）
• 适合任务数比较密集，但每个任务执行时间较短的情况

• newSingleThreadExecutor：创建一个只有 1 个线程的单线程池
• 保证所有任务按照指定顺序执行，线程数固定为 1，任务数多于 1 时会放入无界队列排队，任务执行完毕，这唯一的线程也不会被释放

• 创建一个单线程串行执行任务，如果任务执行失败而终止那么没有任何补救措施，线程池会新建一个线程，保证池的正常工作

• Executors.newSingleThreadExecutor() 线程个数始终为 1，不能修改。FinalizableDelegatedExecutorService 应用的是装饰器模式，只对外暴露了 ExecutorService 接口，因此不能调用 ThreadPoolExecutor 中特有的方法
原因：父类不能直接调用子类中的方法，需要反射或者创建对象的方式，可以调用子类静态方法

• Executors.newFixedThreadPool(1) 初始时为 1，可以修改。对外暴露的是 ThreadPoolExecutor 对象，可以强转后调用 setCorePoolSize 等方法进行修改

开发要求

• 线程资源必须通过线程池提供，不允许在应用中自行显式创建线程
• 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题
• 如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者过度切换的问题

• 线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式更加明确线程池的运行规则，规避资源耗尽的风险
Executors 返回的线程池对象弊端如下：
• FixedThreadPool 和 SingleThreadPool：请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM
• CacheThreadPool 和 ScheduledThreadPool：允许创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，导致 OOM

• 一般来说池中总线程数是核心池线程数量两倍，确保当核心池有线程停止时，核心池外有线程进入核心池

• 过小会导致程序不能充分地利用系统资源、容易导致饥饿

• 过大会导致更多的线程上下文切换，占用更多内存
上下文切换：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态，任务从保存到再加载的过程就是一次上下文切换

• CPU 密集型任务 (N+1)： 这种任务消耗的是 CPU 资源，可以将核心线程数设置为 N (CPU 核心数) + 1，比 CPU 核心数多出来的一个线程是为了防止线程发生缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 某个核心就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间
CPU 密集型简单理解就是利用 CPU 计算能力的任务比如在内存中对大量数据进行分析

• I/O 密集型任务： 这种系统 CPU 处于阻塞状态，用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用，因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N 或 CPU 核数/ (1-阻塞系数)，阻塞系数在 0.8~0.9 之间
IO 密集型就是涉及到网络读取，文件读取此类任务 ，特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上

4、ExecutorService 接口

提交方法

• execute 只能执行 Runnable 类型的任务，没有返回值； submit 既能提交 Runnable 类型任务也能提交 Callable 类型任务，底层是封装成 FutureTask，然后调用 execute 执行

• execute 会直接抛出任务执行时的异常，submit 会吞掉异常，可通过 Future 的 get 方法将任务执行时的异常重新抛出

关闭方法

处理异常

• future.get() 会抛出异常

5、Timer

• 需使用 ScheduledThreadPoolExecutor 优化

6、ScheduledThreadPoolExecutor

• 使用内部类 ScheduledFutureTask 封装任务

• 使用内部类 DelayedWorkQueue 作为线程池队列

• 重写 onShutdown 方法去处理 shutdown 后的任务

• 提供 decorateTask 方法作为 ScheduledFutureTask 的修饰方法，以便开发者进行扩展

• ScheduledFuture<?> schedule(Runnable/Callable<V>, long delay, TimeUnit u)：延迟执行任务

• ScheduledFuture<?> scheduleAtFixedRate(Runnable/Callable<V>, long initialDelay, long period, TimeUnit unit)：定时执行周期任务，参数为初始延迟时间、间隔时间、单位
• 执行时间为 Max(上一个任务执行耗时，period)

• ScheduledFuture<?> scheduleWithFixedDelay(Runnable/Callable<V>, long initialDelay, long delay, TimeUnit unit)：定时执行周期任务，参数为初始延迟时间、间隔时间、单位
• 执行时间为上一个任务end之后延期delay后执行

成员属性

• shutdown 后是否继续执行周期任务：

• shutdown 后是否继续执行延迟任务：

• 取消方法是否将该任务从队列中移除：

• 任务的序列号，可以用来比较优先级：

延迟任务

• 任务序列号：

• 执行时间：
fixed-rate：两次开始启动的间隔，fixed-delay：一次执行结束到下一次开始启动

• 实际的任务对象：

• 任务在队列数组中的索引下标：

• 构造方法：

• compareTo()：ScheduledFutureTask 根据执行时间 time 正序排列，如果执行时间相同，在按照序列号 sequenceNumber 正序排列，任务需要放入 DelayedWorkQueue，延迟队列中使用该方法按照从小到大进行排序

• run()：执行任务，非周期任务直接完成直接结束，周期任务执行完后会设置下一次的执行时间，重新放入线程池的阻塞队列，如果线程池中的线程数量少于核心线程，就会添加 Worker 开启新线程
周期任务正常完成后任务的状态不会变化，依旧是 NEW，不会设置 outcome 属性。但是如果本次任务执行出现异常，会进入 setException 方法将任务状态置为异常，把异常保存在 outcome 中，方法返回 false，后续的该任务将不会再周期的执行

• reExecutePeriodic()：准备任务的下一次执行，重新放入阻塞任务队列

• cancel()：取消任务

7、Tomcat 线程池

• LimitLatch 用来限流，可以控制最大连接个数，类似 J.U.C 中的 Semaphore 后面再讲

• Acceptor 只负责【接收新的 socket 连接】

• Poller 只负责监听 socket channel 是否有【可读的 I/O 事件】

• 一旦可读，封装一个任务对象（socketProcessor），提交给 Executor 线程池处理

• Executor 线程池中的工作线程最终负责【处理请求】

• 如果总线程数达到 maximumPoolSize
• 这时不会立刻抛 RejectedExecutionException 异常
• 而是再次尝试将任务放入队列，如果还失败，才抛出 RejectedExecutionException 异常

8、ForkJoin

• Fork/Join 在分治的基础上加入了多线程，把每个任务的分解和合并交给不同的线程来完成，提升了运算效率

• ForkJoin 使用 ForkJoinPool 来启动，是一个特殊的线程池，默认会创建与 CPU 核心数大小相同的线程池

• 任务有返回值继承 RecursiveTask，没有返回值继承 RecursiveAction

• 每个线程都维护了一个双端队列，用来存储需要执行的任务

• 工作窃取算法允许空闲的线程从其它线程的双端队列中窃取一个任务来执行

• 窃取的必须是最晚的任务，避免和队列所属线程发生竞争，但是队列中只有一个任务时还是会发生竞争

9、Future & FutureTask

线程使用

成员属性

• 任务状态：

• 任务对象：

• 存储任务执行的结果，这是 run 方法返回值是 void 也可以获取到执行结果的原因：

• 执行当前任务的线程对象：

• 线程阻塞队列的头节点：

• 内部类：

成员方法

• FutureTask#run：任务执行入口
FutureTask#set：设置正常返回值，首先将任务状态设置为 COMPLETING 状态代表完成中，逻辑执行完设置为 NORMAL 状态代表任务正常执行完成，最后唤醒 get() 阻塞线程
FutureTask#setException：设置异常返回值
FutureTask#finishCompletion：唤醒 get() 阻塞线程
FutureTask#handlePossibleCancellationInterrupt：任务中断处理

• FutureTask#get：获取任务执行的返回值，执行 run 和 get 的不是同一个线程，一般有多个线程 get，只有一个线程 run
FutureTask#awaitDone：get 线程封装成 WaitNode 对象进入阻塞队列阻塞等待
FutureTask#report：封装运行结果，可以获取 run() 方法中设置的成员变量 outcome，这是 run 方法的返回值是 void 也可以获取到任务执行的结果的原因

• FutureTask#cancel：任务取消，打断正在执行该任务的线程

六、同步器

1、AQS

核心思想

• 独占模式是只有一个线程能够访问资源，如 ReentrantLock

• 共享模式允许多个线程访问资源，如 Semaphore，ReentrantReadWriteLock 是组合式

• 如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置锁定状态

• 请求的共享资源被占用，AQS 用队列实现线程阻塞等待以及被唤醒时锁分配的机制，将暂时获取不到锁的线程加入到队列中
CLH 是一种基于单向链表的高性能、公平的自旋锁，AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配

• 使用者继承 AbstractQueuedSynchronizer 并重写指定的方法

• 将 AQS 组合在自定义同步组件的实现中，并调用其模板方法，这些模板方法会调用使用者重写的方法

• 默认情况下，每个方法都抛出 UnsupportedOperationException

• 这些方法的实现必须是内部线程安全的

• AQS 类中的其他方法都是 final ，所以无法被其他类使用，只有这几个方法可以被其他类使用

自定义不可重入锁

基本原理

• state 使用了 32bit int 来维护同步状态，独占模式 0 表示未加锁状态，大于 0 表示已经加锁状态

• state 使用 volatile 修饰配合 cas 保证其修改时的原子性

• state 表示线程重入的次数（独占模式）或者剩余许可数（共享模式）

• state API：
• protected final int getState()：获取 state 状态
• protected final void setState(int newState)：设置 state 状态
• protected final boolean compareAndSetState(int expect,int update)：CAS 安全设置 state

• 使用 volatile 修饰配合 CAS 保证其修改时的原子性

• 表示 Node 节点的状态，有以下几种状态：

• 使用 park & unpark 来实现线程的暂停和恢复，因为命令的先后顺序不影响结果

• park & unpark 是针对线程的，而不是针对同步器的，因此控制粒度更为精细

• park 线程可以通过 interrupt 打断

• 使用了 FIFO 先入先出队列，并不支持优先级队列，同步队列是双向链表，便于出队入队

2、ReentrantLock

与 synchronized 对比

1. 锁的实现：synchronized 是 JVM 实现的，而 ReentrantLock 是 JDK 实现的

2. 性能：新版本 Java 对 synchronized 进行了很多优化，synchronized 与 ReentrantLock 大致相同

3. 使用：ReentrantLock 需要手动解锁，synchronized 执行完代码块自动解锁

4. 可中断：ReentrantLock 可中断，而 synchronized 不行

5. 公平锁：公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁
• ReentrantLock 可以设置公平锁，synchronized 中的锁是非公平的
• 不公平锁的含义是阻塞队列内公平，队列外非公平

6. 锁超时：尝试获取锁，超时获取不到直接放弃，不进入阻塞队列
• ReentrantLock 可以设置超时时间，synchronized 会一直等待

7. 锁绑定多个条件：一个 ReentrantLock 可以同时绑定多个 Condition 条件变量

8. 两者都是可重入锁

基本语法

• public void lock()：获得锁
• 如果锁没有被另一个线程占用，则将锁定计数设置为 1
• 如果当前线程已经保持锁定，则保持计数增加 1
• 如果锁被另一个线程保持，则当前线程被禁用线程调度，并且在锁定已被获取之前处于休眠状态

• public void unlock()：尝试释放锁
• 如果当前线程是该锁的持有者，则保持计数递减
• 如果保持计数现在为零，则锁定被释放
• 如果当前线程不是该锁的持有者，则抛出异常

可重入

可打断

• 如果没有竞争此方法就会获取 lock 对象锁

• 如果有竞争就进入阻塞队列，可以被其他线程用 interrupt 打断

原理-不可打断

• 被打断后只是保存了一个标记，只有在 acquireQueued 方法里进入第一个if后（即获得到锁）之后才会返回被打断的标记

• 然后触发一次打断效果（线程是运行状态，因此只会重置打断标记）

原理-可打断

• 可打断模式：AbstractQueuedSynchronizer#acquireInterruptibly，被打断后会直接抛出异常

锁超时

公平锁

原理-非公平锁

• 没有竞争：ExclusiveOwnerThread 属于 Thread-0，state 设置为 1

• 第一个竞争出现：Thread-1 执行，CAS 尝试将 state 由 0 改为 1，结果失败（第一次），进入 acquire 逻辑

• 进入 tryAcquire 尝试获取锁逻辑，这时 state 已经是1，结果仍然失败（第二次）
• 当前 AQS 处于无锁状态（不检查aqs队列体现非公平性）
• 加锁线程就是当前线程，说明发生了锁重入

• 接下来进入 addWaiter 逻辑，构造 Node 队列（不是阻塞队列），前置条件是当前线程获取锁失败，说明有线程占用了锁
• 图中黄色三角表示该 Node 的 waitStatus 状态，其中 0 为默认正常状态
• Node 的创建是懒惰的，其中第一个 Node 称为 Dummy（哑元）或哨兵，用来占位，并不关联线程

• 线程节点创建Node成功，进入 AbstractQueuedSynchronizer#acquireQueued 逻辑阻塞线程
• acquireQueued 会在一个自旋中不断尝试获得锁，失败后进入 park 阻塞
• 如果当前线程是在 head 节点后，会再次 tryAcquire 尝试获取锁，state 仍为 1 则失败（第三次）
• 进入 shouldParkAfterFailedAcquire 逻辑，将前驱 node 的 waitStatus 改为 -1，返回 false；waitStatus 为 -1 的节点用来唤醒下一个节点
• shouldParkAfterFailedAcquire 执行完毕回到 acquireQueued ，再次 tryAcquire 尝试获取锁，这时 state 仍为 1 获取失败（第四次）
• 当再次进入 shouldParkAfterFailedAcquire 时，这时其前驱 node 的 waitStatus 已经是 -1 了，返回 true
• 进入 parkAndCheckInterrupt， Thread-1 park（灰色表示）

• 再有多个线程经历竞争失败后：

• 进入 tryRelease，设置 exclusiveOwnerThread 为 null，state = 0

• 当前队列不为 null，并且 head 的 waitStatus = -1，进入 unparkSuccessor

• 进入 AbstractQueuedSynchronizer#unparkSuccessor 方法，唤醒当前节点的后继节点
• 找到队列中距离 head 最近的一个没取消的 Node，unpark 恢复其运行，本例中即为 Thread-1
• 回到 Thread-1 的 acquireQueued 流程
从后向前的唤醒的原因：enq 方法中，节点是尾插法，首先赋值的是尾节点的前驱节点，此时前驱节点的 next 并没有指向尾节点，从前遍历会丢失尾节点

• 唤醒的线程会从 park 位置开始执行，如果加锁成功（没有竞争），会设置
• exclusiveOwnerThread 为 Thread-1，state = 1
• head 指向刚刚 Thread-1 所在的 Node，该 Node 会清空 Thread
• 原本的 head 因为从链表断开，而可被垃圾回收（图中有错误，原来的头节点的 waitStatus 被改为 0 了）

• 如果这时有其它线程来竞争（非公平），例如这时有 Thread-4 来了并抢占了锁
• Thread-4 被设置为 exclusiveOwnerThread，state = 1
• Thread-1 再次进入 acquireQueued 流程，获取锁失败，重新进入 park 阻塞

原理-公平锁

条件变量

• void await()：当前线程从运行状态进入等待状态，释放锁

• void signal()：唤醒一个等待在 Condition 上的线程，但是必须获得与该 Condition 相关的锁

• await / signal 前需要获得锁

• await 执行后，会释放锁进入 ConditionObject 等待

• await 的线程被唤醒去重新竞争 lock 锁

• 线程在条件队列被打断会抛出中断异常

• 竞争 lock 锁成功后，从 await 后继续执行

原理-条件变量

• 开始 Thread-0 持有锁，调用 await，线程进入 ConditionObject 等待，直到被唤醒或打断，调用 await 方法的线程都是持锁状态的，所以说逻辑里不存在并发

• 创建新的 Node 状态为 -2（Node.CONDITION），关联 Thread-0，加入等待队列尾部

• 接下来 Thread-0 进入 AQS 的 fullyRelease 流程，释放同步器上的锁

• fullyRelease 中会 unpark AQS 队列中的下一个节点竞争锁，假设 Thread-1 竞争成功

• Thread-0 进入 isOnSyncQueue 逻辑判断节点是否移动到阻塞队列，没有就 park 阻塞 Thread-0

• await 线程 park 后如果被 unpark 或者被打断，都会进入 checkInterruptWhileWaiting 判断线程是否被打断：在条件队列被打断的线程需要抛出异常

• 最后开始处理中断状态：

• 假设 Thread-1 要来唤醒 Thread-0，进入 ConditionObject 的 doSignal 流程，取得等待队列中第一个 Node，即 Thread-0 所在 Node，必须持有锁才能唤醒, 因此 doSignal 内线程安全

• 执行 transferForSignal，先将节点的 waitStatus 改为 0，然后加入 AQS 阻塞队列尾部，将 Thread-3 的 waitStatus 改为 -1

• Thread-1 释放锁，进入 unlock 流程

3、ReentrantReadWriteLock

基本使用

• 读-读能共存、读-写不能共存、写-写不能共存

• 读锁不支持条件变量

• 构造方法：默认是非公平锁，可以指定参数创建公平锁

• 重入时升级不支持：持有读锁的情况下去获取写锁会导致获取写锁永久等待，需要先释放读，再去获得写

• 重入时降级支持：持有写锁的情况下去获取读锁，造成只有当前线程会持有读锁，因为写锁会互斥其他的锁

缓存应用

• 先清缓存：可能造成刚清理缓存还没有更新数据库，线程直接查询了旧数据

• 先更新据库：可能造成刚更新数据库，还没清空缓存就有线程从缓存拿到了旧数据

原理-加锁

• t1 线程：w.lock（写锁），成功上锁 state = 0_1

• t2 r.lock（读锁），进入 tryAcquireShared 流程：
• 返回 -1 表示失败
• 如果返回 0 表示成功
• 返回正数表示还有多少后继节点支持共享模式，读写锁返回 1

• 获取读锁失败，进入 sync.doAcquireShared(1) 流程开始阻塞，首先也是调用 addWaiter 添加节点，不同之处在于节点被设置为 Node.SHARED 模式而非 Node.EXCLUSIVE 模式，注意此时 t2 仍处于活跃状态
如果没有成功，在 doAcquireShared 内 for (;;) 循环一次，shouldParkAfterFailedAcquire 内把前驱节点的 waitStatus 改为 -1，再 for (;;) 循环一次尝试 tryAcquireShared，不成功在 parkAndCheckInterrupt() 处 park

• 这种状态下，假设又有 t3 r.lock，t4 w.lock，这期间 t1 仍然持有锁，就变成了下面的样子

原理-解锁

• t1 w.unlock， 写锁解锁

• 唤醒流程 sync.unparkSuccessor，这时 t2 在 doAcquireShared 的 parkAndCheckInterrupt() 处恢复运行，继续循环，执行 tryAcquireShared 成功则让读锁计数加一

• 接下来 t2 调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点；还会检查下一个节点是否是 shared，如果是则调用 doReleaseShared() 将 head 的状态从 -1 改为 0 并唤醒下一个节点，这时 t3 在 doAcquireShared 内 parkAndCheckInterrupt() 处恢复运行，唤醒连续的所有的共享节点

• 下一个节点不是 shared 了，因此不会继续唤醒 t4 所在节点

• t2 读锁解锁，进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，但计数还不为零，t3 同样让计数减一，计数为零，进入doReleaseShared() 将头节点从 -1 改为 0 并唤醒下一个节点

• t4 在 acquireQueued 中 parkAndCheckInterrupt 处恢复运行，再次 for 这次自己是头节点的临节点，并且没有其他节点竞争，tryAcquire(1) 成功，修改头结点，流程结束

4、StampedLock

• 在使用读锁、写锁时都必须配合戳使用

• StampedLock 不支持条件变量

• StampedLock 不支持重入

• 加解读锁：

• 加解写锁：

• 乐观读，StampedLock 支持 tryOptimisticRead() 方法，读取完毕后做一次戳校验，如果校验通过，表示这期间没有其他线程的写操作，数据可以安全使用，如果校验没通过，需要重新获取读锁，保证数据一致性

• 读-读可以优化

• 读-写优化读，补加读锁

5、Semaphore

基本使用

• public Semaphore(int permits)：permits 表示许可线程的数量（state）

• public Semaphore(int permits, boolean fair)：fair 表示公平性，如果设为 true，下次执行的线程会是等待最久的线程

• public void acquire()：表示获取许可

• public void release()：表示释放许可，acquire() 和 release() 方法之间的代码为同步代码

原理-加解锁

• Semaphore 的 permits（state）为 3，这时 5 个线程来获取资源
假设其中 Thread-1，Thread-2，Thread-4 CAS 竞争成功，permits 变为 0，而 Thread-0 和 Thread-3 竞争失败，进入 AQS 队列park 阻塞

• 这时 Thread-4 释放了 permits，状态如下

• 接下来 Thread-0 竞争成功，permits 再次设置为 0，设置自己为 head 节点，并且 unpark 接下来的共享状态的 Thread-3 节点，但由于 permits 是 0，因此 Thread-3 在尝试不成功后再次进入 park 状态

6、CountDownLatch

基本使用

• public CountDownLatch(int count)：初始化唤醒需要的 down 几步

• public void await() ：让当前线程等待，必须 down 完初始化的数字才可以被唤醒，否则进入无限等待

• public void countDown()：计数器进行减 1（down 1）

7、CyclicBarrier

基本使用

• public CyclicBarrier(int parties, Runnable barrierAction)：用于在线程到达屏障 parties 时，执行 barrierAction
• parties：代表多少个线程到达屏障开始触发线程任务
• barrierAction：线程任务

• public int await()：线程调用 await 方法通知 CyclicBarrier 本线程已经到达屏障

• 基于 ReentrantLock 和 Condition 条件队列

七、线程安全集合

1. Blocking Queue

2. CopyOnWrite List

3. Concurrent Map

1、ConcurrentHashMap

集合对比

1. Hashtable 和 HashMap（JDK7） 底层是数组 + 链表，JDK8 以后 HashMap 和 ConcurrentHashMap 底层是数组 + 链表 + 红黑树

2. ConcurrentHashMap、Hashtable 不允许 null key 和 null value， HashMap 允许 null key 和 value

3. ConcurrentHashMap、HashMap 的初始容量为 16，Hashtable 初始容量为11，填充因子默认都是 0.75，两种 Map 扩容是当前容量翻倍：capacity * 2，Hashtable 扩容时是容量翻倍 + 1：capacity*2 + 1

4. HashMap JDK 1.7 是头插法，会产生并发死链问题，JDK 8 是尾插法，没有并发死链问题，但仍然会有其他问题（例如扩容丢失数据）
1. 并发死链：头插法会导致链表在多线程下的迁移指针产生错乱，导致链表成环：A→B→A

总体步骤

1. 初始化，cas 懒惰初始化 table

2. 树化，当 table.length < 64 时，先尝试扩容，超过 64 时，并且 bin.length > 8 时，会将链表树化，树化过程会用 synchronized 锁住链表头

3. put，如果该 bin 尚未创建，只需要使用 cas 创建 bin；如果已经有了，锁住链表头进行后续 put 操作，元素添加至 bin 的尾部

4. get，无锁操作仅需要保证可见性，扩容过程中 get 操作拿到的是 ForwardingNode 会让 get 操作在新 table 进行搜索
1. 扩容迁移完毕会将 bin 头节点标记为 ForwardingNode
2. 若已被标记则去新数组查找，否则直接在旧数组查找

5. 扩容，扩容时以 bin 为单位进行，需要对 bin 进行 synchronized，但这时其它竞争线程也不是无事可做，它们会帮助把其它 bin 进行扩容

6. size，元素个数保存在 baseCount 中，并发时的个数变动保存在 CounterCell[] 当中，最后统计数量时累加（类似 LongAdder 原理来提高累加效率）

JDK7 原理

• 优点：如果多个线程访问不同的 segment，实际是没有冲突的，这与 JDK8 中是类似的

• 缺点：并发度固定，Segments 数组默认大小为16，这个容量初始化指定后就不能改变了，并且不是懒惰初始化

基本信息

• 存储数组：

• 散列表的长度：

• 负载因子，JDK1.8 的 ConcurrentHashMap 中是固定值：

• 阈值：

• 节点哈希值：

• 扩容过程：volatile 修饰保证多线程的可见性

• 累加统计：

• 控制变量：
sizeCtl < 0：
• 1 表示当前 table 正在初始化（有线程在创建 table 数组），当前线程需要自旋等待
• 其他负数表示当前 map 的 table 数组正在进行扩容，高 16 位表示扩容的标识戳；低 16 位表示 (1 + nThread) 当前参与并发扩容的线程数量 + 1
sizeCtl = 0，表示创建 table 数组时使用 DEFAULT_CAPACITY 为数组大小
sizeCtl > 0：
• 如果 table 未初始化，表示初始化大小
• 如果 table 已经初始化，表示下次扩容时的触发条件（阈值，元素个数，不是数组的长度）

• 无参构造， 散列表结构延迟初始化，默认的数组大小是 16：

• 多个参数构造方法：

PUT

• putVal()

• spread()：扰动函数
将 hashCode 无符号右移 16 位，高 16bit 和低 16bit 做异或，最后与 HASH_BITS 相与变成正数，与树化节点和转移节点区分，把高低位都利用起来减少哈希冲突，保证散列的均匀性

• initTable()：初始化数组，延迟初始化

• treeifyBin()：树化方法

• addCount()：添加计数，代表哈希表中的数据总量

扩容方法

• 当链表中元素个数超过 8 个，数组的大小还未超过 64 时，此时进行数组的扩容，如果超过则将链表转化成红黑树

• put 数据后调用 addCount() 方法，判断当前哈希表的容量超过阈值 sizeCtl，超过进行扩容

• 增删改线程发现其他线程正在扩容，帮其扩容

• transfer()：数据转移到新表中，完成扩容
链表处理的 LastRun 机制，可以减少节点的创建

• helpTransfer()：帮助扩容机制

GET

• get()：获取指定数据的方法

• ForwardingNode#find：转移节点的查找方法

删除方法

• remove()：删除指定元素

• replaceNode()：替代指定的元素，会协助扩容，增删改（写）都会协助扩容，查询（读）操作不会，因为读操作不涉及加锁

2、LinkedBlockingDeque

入队出队

加锁分析

• 用一把锁，同一时刻，最多只允许有一个线程（生产者或消费者，二选一）执行

• 用两把锁，同一时刻，可以允许两个线程同时（一个生产者与一个消费者）执行
• 消费者与消费者线程仍然串行
• 生产者与生产者线程仍然串行

• 当节点总数大于 2 时（包括 dummy 节点），putLock 保证的是 last 节点的线程安全，takeLock 保证的是head 节点的线程安全。两把锁保证了入队和出队没有竞争

• 当节点总数等于 2 时（即一个 dummy 节点，一个正常节点）这时候，仍然是两把锁锁两个对象，不会竞争

• 当节点总数等于 1 时（就一个 dummy 节点）这时 take 线程会被 notEmpty 条件阻塞，有竞争，会阻塞

性能比较

• Linked 支持有界，Array 强制有界

• Linked 实现是链表，Array 实现是数组

• Linked 是懒惰的，而 Array 需要提前初始化 Node 数组

• Linked 每次入队会生成新 Node，而 Array 的 Node 是提前创建好的

• Linked 两把锁，Array 一把锁

3、CopyOnWriteArrayList

原理分析

• 存储结构：

• 全局锁：保证线程的执行安全

• 新增数据：需要加锁，创建新的数组操作

• 读操作：不加锁，在原数组上操作
适合读多写少的应用场景

• 迭代器：CopyOnWriteArrayList 在返回迭代器时，创建一个内部数组当前的快照（引用），即使其他线程替换了原始数组，迭代器遍历的快照依然引用的是创建快照时的数组，所以这种实现方式也存在一定的数据延迟性，对其他线程并行添加的数据不可见

弱一致性

• 强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值

• 弱一致性：系统并不保证进程或者线程的访问都会返回最新的更新过的值，也不会承诺多久之后可以读到

安全失败

• 快速失败：在 A 线程使用迭代器对集合进行遍历的过程中，此时 B 线程对集合进行修改（增删改），或者 A 线程在遍历过程中对集合进行修改，都会导致 A 线程抛出 ConcurrentModificationException 异常
• AbstractList 类中的成员变量 modCount，用来记录 List 结构发生变化的次数，结构发生变化是指添加或者删除至少一个元素的操作，或者是调整内部数组的大小，仅仅设置元素的值不算结构发生变化
• 在进行序列化或者迭代等操作时，需要比较操作前后 modCount 是否改变，如果改变了抛出 CME 异常

• 安全失败：采用安全失败机制的集合容器，在迭代器遍历时直接在原集合数组内容上访问，但其他线程的增删改都会新建数组进行修改，就算修改了集合底层的数组容器，迭代器依然引用着以前的数组（快照思想），所以不会出现异常

4、ConcurrentLinkedDeque

• 加锁，这种实现方式是阻塞队列

• 使用循环 CAS 算法实现，这种方式是非阻塞队列

1. 不允许 null 入列

2. 队列中所有未删除的节点的 item 都不能为 null 且都能从 head 节点遍历到

3. 删除节点是将 item 设置为 null，队列迭代时跳过 item 为 null 节点

4. head 节点跟 tail 不一定指向头节点或尾节点，可能存在滞后性

入队

• 将入队节点设置成当前队列尾节点的下一个节点

• 更新 tail 节点，如果 tail 节点的 next 节点不为空，则将入队节点设置成 tail 节点；如果 tail 节点的 next 节点为空，则将入队节点设置成 tail 的 next 节点，所以 tail 节点不总是尾节点，存在滞后性

• 线程 1 线程 2 同时入队，无论从哪个位置开始并发入队，都可以循环 CAS，直到入队成功，线程安全

• 线程 1 遍历，线程 2 入队，所以造成 ConcurrentLinkedQueue 的 size 是变化，需要加锁保证安全

• 线程 1 线程 2 同时出列，线程也是安全的

出队

• 当 head 节点里有元素时，直接弹出 head 节点里的元素，而不会更新 head 节点

• 当 head 节点里没有元素时，出队操作才会更新 head 节点