Java并发思维导图（含面试问题整理）

Runnable 接口 run 方法无返回值

Callable 接口 call 方法有返回值（泛型，和Future、FutureTask配合使用）可获取异步执行的结果

Runnable 接口 run 方法只能抛出运行时异常，且无法捕获处理

Callable 接口 call 方法允许抛出异常，可以获取异常信息

调用 t.start()，NEW --> RUNNABLE

可运行

运行

阻塞（操作系统阻塞、IO阻塞）

结束状态

t 线程用 synchronized(obj) 获取了对象锁后

当前线程调用 t.join() 方法时，当前线程从 RUNNABLE --> WAITING

当前线程调用 LockSupport.park() 方法会让当前线程从 RUNNABLE --> WAITING

t 线程用 synchronized(obj) 获取了对象锁时如果竞争失败，从 RUNNABLE --> BLOCKED（EntryList）

t 线程用 synchronized(obj) 获取了对象锁后

当前线程调用 t.join(long n) 方法时，当前线程从 RUNNABLE --> TIMED_WAITING

当前线程调用 Thread.sleep(long n) ，当前线程从 RUNNABLE --> TIMED_WAITING

当前线程调用 LockSupport.parkNanos(long nanos) 或 LockSupport.parkUntil(long millis) 时，
当前线程从 RUNNABLE --> TIMED_WAITING

线程刚被创建，还没有调用 start() 方法

线程对象创建后，线程调用 start()方法，进入就绪状态，等待线程调度cpu执行

join()等待执行状态

可运行状态(runnable)的线程获得了cpu时间片（timeslice），执行程序代码

处于运行状态中的线程由于某种原因，暂时放弃对 CPU的使用权，停止执行，此时进入阻塞状态

直到其进入到就绪状态，才有机会再被 CPU 调用进入运行状态

Monitor对象的EntryList（BLOCKED），waitSet（WAITING）

声明抛出 InterruptedException

没有声明任何异常

打断状态置false

Thread.currentThread().isInterrupted()来控制正常程序是否退出

取代stop()方法

查看当前中断信号是true还是false

如果一个线程被中断，第一次调用 interrupted 则返回 true，之后的打断标记为 false 

增加临界区操作上的原子性

只读操作，则线程安全

有读写操作，则这段代码为临界区，需要考虑线程安全

没有逃离方法的作用范围，线程安全

该对象逃离方法的作用范围，需要考虑线程安全

说说为什么使用final？

private 或 final 提供【安全】，开闭原则中的【闭】

public，子类方法覆盖，线程不安全

replace，substring如何保证线程安全？

SimpleDateFormat可变类

DateTimeFormatter不可变类

Byte, Short, Long 缓存的范围都是 -128~127

Character 缓存的范围是 0~127

Boolean 缓存了 TRUE 和 FALSE

本身的原子操作是线程安全的，组合起来获取值设置值是不安全的。

Integer i1 = 40;
Integer i2 = 40;//在-128~127之间，对象重用
Integer i3 = 0;
Integer i4 = new Integer(40);
Integer i5 = new Integer(40);
Integer i6 = new Integer(0);
System.out.println("i1==i2\t" + (i1 == i2));//true （i1、i2等于400为false）
System.out.println("i1==i2+i3\t" + (i1 == i2 + i3));//true
System.out.println("i4==i5\t" + (i4 == i5));//false
System.out.println("i4==i5+i6\t" + (i4 == i5 + i6));//true

class Test{
public void test() {
synchronized(this) {}}}

class Test{
public static void test() {
synchronized(Test.class) {}}}

让锁记录中对象引用指向锁对象，并尝试用 cas 替换锁定对象的 Mark Word，
将 Mark Word 的值存入锁记录

这时 Thread-1 加轻量级锁失败，进入锁膨胀流程

单核 CPU 自旋占用 CPU 时间

只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word ，
之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

Object Header (64 bits)

Mark Word (32 位)

Klass Word (32 bits)

多了array length(32bits)数组长度记录

再用 jstack 定位死锁，如 jstack 33200（id）

线程

Sychronized是关键字方式，对象加Monitor

创建对象方式加锁，成对出现

Synchronized无法获取超时时间（主动打断）

Synchronized不可中断（被动打断）

支持可打断设置：lock.lockInterruptibly();

Synchronized只有一个条件变量，不满足条件，进入waitset

ReentrantLock多个条件变量使用要点

Syn不会记录阻塞顺序

公平锁一般没有必要，会降低并发度

可以用来修饰成员变量和静态成员变量

不能修饰局部变量（线程私有的）

static int x;
static Object m = new Object();
new Thread(()->{
synchronized(m) {
x = 10;//线程解锁 m 之前对变量的写
}
},"t1").start();
new Thread(()->{
synchronized(m) {
System.out.println(x);//接下来对 m 加锁的其它线程对该变量的读可见
}
},"t2").start();

volatile static int x;
new Thread(()->{
x = 10;//线程对 volatile 变量的写
},"t1").start();
new Thread(()->{
System.out.println(x);//对接下来其它线程对该变量的读可见
},"t2").start();

static int x;
x = 10;//线程 start 前对变量的写
new Thread(()->{
System.out.println(x);//对该线程开始后对该变量的读可见
},"t2").start();

static int x;
Thread t1 = new Thread(()->{
x = 10;//线程结束前对变量的写
},"t1");
t1.start();
t1.join();//比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束
System.out.println(x);//对其它线程得知它结束后的读可见

static int x;
public static void main(String[] args) {
Thread t2 = new Thread(()->{
while(true) {
if(Thread.currentThread().isInterrupted()) {
System.out.println(x);
break;
}
}
},"t2");
t2.start();
new Thread(()->{
sleep(1);
x = 10;//线程 t1 打断 t2（interrupt）前对变量的写
t2.interrupt();//通过t2.interrupted 或 t2.isInterrupted
},"t1").start();
while(!t2.isInterrupted()) {
Thread.yield();
}
System.out.println(x);//对于其他线程得知 t2 被打断后对变量的读可见
}

volatile static int x;
static int y;
new Thread(()->{
y = 10;
x = 20;//对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
},"t1").start();
new Thread(()->{
// x=20 对 t2 可见, 同时 y=10 也对 t2 可见
System.out.println(x);
},"t2").start();

CAS 的底层是 lock cmpxchg 指令（X86 架构），在单核 CPU 和多核 CPU 下都能够保证【比较-交换】的原子性。

在多核状态下，某个核执行到带 lock 的指令时，CPU 会让总线锁住，当这个核把此指令执行完毕，再开启总线

这个过程中不会被线程的调度机制所打断，保证了多个线程对内存操作的准确性，是原子的。

依赖Unsafe类，value变量使用volatile修饰令其他线程可见，自增加减乘除操作使用CAS保证线程安全。

获取并自增（i = 0, 结果 i = 1, 返回 0），类似于 i++

自增并获取（i = 1, 结果 i = 2, 返回 2），类似于 ++i

自减并获取（i = 2, 结果 i = 1, 返回 1），类似于 --i

获取并自减（i = 1, 结果 i = 0, 返回 1），类似于 i--

加值并获取（i = 5, 结果 i = 0, 返回 0）

支持加减乘除操作

AtomicBoolean

AtomicLong

只要有其它线程【动过了】共享变量，那么自己的 cas 就算失败，这时，仅比较值是不够的，需要再加一个版本号

stamped，邮戳

static AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);

ref.compareAndSet(ref.getReference(), "B", ref.getStamp(), ref.getStamp() + 1));

AtomicStampedReference 可以给原子引用加上版本号，追踪原子引用整个的变化过程

如： A -> B -> A -> C ，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了几次。

但是有时候，并不关心引用变量更改了几次，只是单纯的关心是否更改过

corePoolSize 核心线程数目 (最多保留的线程数)

maximumPoolSize 最大线程数目

keepAliveTime 生存时间 - 针对救急线程

unit 时间单位 - 针对救急线程

workQueue 阻塞队列

threadFactory 线程工厂 - 可以为线程创建时起个好名字

handler 拒绝策略

AbortPolicy 让调用者抛出 RejectedExecutionException 异常，这是默认策略

CallerRunsPolicy 让调用者运行任务

DiscardPolicy 放弃本次任务

DiscardOldestPolicy 放弃队列中最早的任务，本任务取而代之

Dubbo （RPC框架）的实现，在抛出 RejectedExecutionException 异常之前会记录日志，并 dump 线程栈信息，方便定位问题

Netty 的实现，是创建一个新线程来执行任务（网络通信框架，达不到限制线程池总数目的）

ActiveMQ （消息队列）的实现，带超时等待（60s）尝试放入队列，类似我们之前自定义的拒绝策略

核心线程数 == 最大线程数（没有救急线程被创建），因此也无需超时时间

阻塞队列是无界的，可以放任意数量的任务

核心线程数是 0， 最大线程数是 Integer.MAX_VALUE，救急线程的空闲生存时间是 60s

全部都是救急线程（60s 后可以回收）

救急线程可以无限创建

队列采用了 SynchronousQueue 实现特点是，它没有容量，没有线程来取是放不进去的（一手交钱、一手交货）

（没有可用线程，任务无法放入）

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

Executors.newSingleThreadExecutor() 线程个数始终为1，不能修改

Executors.newFixedThreadPool(1) 初始时为1，以后还可以修改

ScheduledExecutorService executor = Executors.newScheduledThreadPool(2);

pool.schedule

pool.scheduleAtFixedRate(() -> {
log.debug("running...");
sleep(2);
}, 1, 1, TimeUnit.SECONDS);

pool.scheduleWithFixedDelay(()-> {
log.debug("running...");
sleep(2);
}, 1, 1, TimeUnit.SECONDS);

try/catch

加返回值，为callable，使用Future捕获；不加返回值，runnable

如果总线程数达到 maximumPoolSize

Tomcat连接器（对外沟通，用到线程池）、容器（实现servlet组件）

有Executor以Executor为准

提交给 Fork/Join 线程池的任务需要继承 RecursiveTask（有返回值）或 RecursiveAction（没有返回值）

需要有终止条件

任务拆分，线程池内多个线程来处理，如何拆分是递归思想

让一个线程去执行此任务，fork（），来源于ForkJoinPool线程池

合并(join)结果

核心线程：传入任务，启动线程立即执行；

救急线程：去阻塞队列获取任务

线程池维持引用、线程回收消除引用

记录日志抛出异常、创建一个新任务来执行、带超时等待放入队列

设置更高的核心线程数、最大线程数

关注如何使用有限的资源，尽可能在单位时间内处理更多的任务，吞吐量优先问题；
设置队列去缓冲并发任务，调整合适的corePoolSize去设置处理任务的线程数。

提高响应速度：使用同步队列，任务不应该被缓存，而是立即执行

提升吞吐量：使用有界队列缓冲大批量任务，声明队列容量，防止任务无限制堆积

封装线程池，允许线程池监听同步外部的消息，根据消息进行修改配置增加线程池监控，告警

getState - 获取 state 状态

setState - 设置 state 状态

compareAndSetState - cas 机制设置 state 状态（CAS防止多个线程来修改state状态）

独占模式是只有一个线程能够访问资源，而共享模式可以允许多个线程访问资源（提供访问上限）

// 如果获取锁失败
if (!tryAcquire(arg)) {
// 入队, 可以选择阻塞当前线程 park unpark
}

// 如果释放锁成功
if (tryRelease(arg)) {
// 让阻塞线程恢复运行
}

是否持有独占锁

尝试获取锁，state初始值为0，未加锁的独占锁。CAS方式保证state原子性。

尝试释放锁，直接setState，此时没有其他线程竞争，所以不用CAS操作。volatile的setState放在置空语句后面，volatile之前语句可以加入写屏障，保证了资源的可见性

while(state 状态不允许获取) {
if(队列中还没有此线程) {
入队并阻塞}
}
当前线程出队

if(state 状态允许了) {
恢复阻塞的线程(s) }

原子维护 state 状态

阻塞及恢复线程

维护队列

先从构造器开始看，默认为非公平锁实现

NonfairSync 继承自 AQS

没有竞争时

第一个竞争出现时

当前线程进入 acquireQueued 逻辑

设置 exclusiveOwnerThread 为 null

state = 0

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

找到队列中离 head 最近的一个 Node（没取消的），unpark 恢复其运行，即为 Thread-1

回到 Thread-1 的 acquireQueued 流程

如果加锁成功（没有竞争），会设置

如果这时候有其它线程来竞争（非公平的体现），例如这时有 Thread-4 竞争

若被 Thread-4 抢占

加锁状态自增

解锁状态自减

在此模式下，即使它被打断，仍会驻留在 AQS 队列中，一直要等到获得锁后方能得知自己被打断了

如果没有获得到锁

进入可打断的获取锁流程

在 park 过程中如果被 interrupt 

这时候抛出异常, 而不会再次进入循环等待

开始 Thread-0 持有锁，调用 await，进入 ConditionObject 的 addConditionWaiter 流程

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

没有占位节点（区别非公平锁），-2条件变量为等待含义

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

unpark AQS 队列中的下一个节点，竞争锁，假设没有其他竞争线程，那么 Thread-1 竞争成功

park 阻塞 Thread-0

假设 Thread-1 要来唤醒 Thread-0

进入 ConditionObject 的 doSignal 流程，取得等待队列中第一个 Node，即 Thread-0 所在 Node

执行 transferForSignal 流程，将该 Node 加入 AQS 队列尾部，将 Thread-0 的 waitStatus 改为 0，Thread-3 的waitStatus 改为 -1

更新时，是先清缓存还是先更新数据库

使用读写锁实现一个简单的按需加载缓存

没有考虑缓存容量

没有考虑缓存过期

一张表一把锁的方式，可以提高并发性

t1 成功上锁，流程与 ReentrantLock 加锁相比没有特殊之处，不同是写锁状态占了 state 的低 16 位，而读锁使用的是 state 的高 16 位

t2 执行 r.lock，这时进入读锁的 sync.acquireShared(1) 流程，首先会进入 tryAcquireShared 流程。如果有写锁占据，那么 tryAcquireShared 返回 -1 表示失败

这时会进入 sync.doAcquireShared(1) 流程，首先也是调用 addWaiter 添加节点，不同之处在于节点被设置为Node.SHARED 模式而非 Node.EXCLUSIVE 模式，注意此时 t2仍处于活跃状态

t2 会看看自己的节点是不是第二位，如果是，还会再次调用 tryAcquireShared(1) 来尝试获取锁

如果没有成功，在 doAcquireShared 内 for (;;) 循环一次，把前驱节点的 waitStatus 改为 -1，再 for (;;) 循环一次尝试 tryAcquireShared(1) 如果还不成功，那么在 parkAndCheckInterrupt() 处 park

假设又有 t3 加读锁和 t4 加写锁，这期间 t1 仍然持有锁

这时会走到写锁的 sync.release(1) 流程，调用 sync.tryRelease(1) 成功

接下来执行唤醒流程 sync.unparkSuccessor，即让第二个node恢复运行，这时 t2 在 doAcquireShared 内parkAndCheckInterrupt() 处恢复运行。这回再来一次 for (;;) 执行 tryAcquireShared 成功则让读锁计数加一

这时 t2 已经恢复运行，接下来 t2 调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点

在 setHeadAndPropagate 方法内还会检查下一个节点是否是 shared，如果是则调用doReleaseShared() 将 head 的状态从 -1 改为 0 并唤醒第二个，这时 t3 在 doAcquireShared 内parkAndCheckInterrupt() 处恢复运行

这回再来一次 for (;;) 执行 tryAcquireShared 成功则让读锁计数加一

这时 t3 已经恢复运行，接下来 t3 调用 setHeadAndPropagate(node, 1)，它原本所在节点被置为头节点

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

t2 进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，但由于计数还不为零

t3 进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，这回计数为零了，进入doReleaseShared() 将头节点从 -1 改为 0 并唤醒老二

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

long stamp = lock.readLock();

lock.unlockRead(stamp);

long stamp = lock.writeLock();

lock.unlockWrite(stamp);

无锁，验戳的方式提高性能

验戳不通过（数据有变动），再加上读锁

乐观读锁进行优化，验证戳通过，直接返回结果。验证不成立进行锁的升级

ReentrantLock独占式的

Semaphore对共享线程数量限制

类比：停车场，公示牌，汽车做线程，Semaphore管理车库

acquire方法、release方法（finally代码块释放资源），竞争失败进入 AQS队列park阻塞

创建 semaphore 对象

10个线程同时运行

获取许可

释放许可

加锁解锁流程

CountDownLatch latch = new CountDownLatch(3);

latch.await();

latch.countDown();

latch.getCount();

一次性使用

Blocking

CopyOnWrite

Concurrent

见：读操作get为什么是线程安全的

哈希桶数组包含多个segment，一个segment包含多个HashEntry（桶）

segment上锁不影响其他segment操作

segment继承ReentrantLock

访问可见性

根据 key 计算出 hash 值定位到具体的 Segment ，再根据 hash 值获取定位 HashEntry 对象，并对 HashEntry 对象进行链表遍历，找到对应元素。

volatile 可以保证内存可见性，所以不会读取到过期数据

先定位到相应的 Segment 

程序不产生锁竞争的最大线程数

JDK8对Sychronized做大量优化后相对ReentrantLock可以减少内存开销 。

因为只对桶下标进行上锁。ReentrantLock对每个节点都需要通过继承 AQS 来获得同步支持

提升查询效率

尾插法的优势

饿汉式创建非常消耗资源

get，无锁操作（仅需要保证可见性，除Treebin的读写锁），扩容过程中 get 操作拿到的是 ForwardingNode 它会让 get 操作在新table 进行搜索

get 流程

读操作一般不加锁(TreeBin的读写锁除外)，读写操作可并行；因为C13Map的写操作都要获取bin头部的syncronized互斥锁，能保证最多只有一个线程在做更新，单线程写、多线程读的并发安全性的问题。

如果读取的bin是一个链表,
头节点是个普通Node

如果读取的bin是一个红黑树，
说明头节点是TreeBin节点。

首先会判断 key、value 是否为空，如果为空就抛异常！

判断桶数组为空，创建桶数组

判断当前数组下标是否第一次插入，为空，使用casTabAt创建Node头结点

扩容期间hash桶插入数据会发生什么？

最后判断是否进行扩容操作

addCount：在调用 addCount 方法增加集合元素计数后发现当前集合元素个数到达扩容阈值时就会触发扩容

helpTransfer：扩容状态下其他线程对集合进行插入、修改、删除、合并、compute 等操作时遇到 ForwardingNode 节点会触发扩容

tryPresize：putAll 批量插入或者插入节点后发现存在链表长度达到 8 个或以上，但数组长度为 64 以下时会触发扩容

hash值MOVED=-1 ，ForwardingNode存在表示集合正在扩容状态，nextTable 指向扩容后的数组。

扩容时如果table某个bin（头结点）迁移完毕, 用 ForwardingNode 作为旧 table bin 的头结点（占位功能）

get遍历到旧table，如果头结点标识为ForwardingNode，则到新表中get遍历，不会阻塞查询操作（转发功能）

新建而未初始化时

初始化过程中

初始化完成后

正在扩容时

初始化链表 last = head = new Node<E>(null); Dummy 节点用来占位，item 为 null

当一个节点入队 last = last.next = node;

再来一个节点入队 last = last.next = node;

出队

【高明之处】用了两把锁和 dummy 节点

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

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

队列，出队入队两把锁提升效率

线程安全分析

主要列举 LinkedBlockingQueue 与 ArrayBlockingQueue 的性能比较

Acceptor ：处理请求接收连接，生产SocketChannel对象

poller：处理读写事件的，监控SocketChannel对象的读写生产者消费者的关系

ConcurrentLinkedQueue（CAS性能更高）将SocketChannel包装为事件对象

增删改操作会将底层数组拷贝一份，更改操作在新数组上执行，这时不影响其它线程的并发读，实现读写分离，读写并发。

读写锁只是读读并发

适合『读多写少』的应用场景

synchronized (lock)

Object[] es = getArray()

es = Arrays.copyOf(es, len + 1);

Concurrent集合类、CopyOnWrite集合类都有get弱一致性问题

不要觉得弱一致性就不好