想象你开了一家生意火爆的快餐店。后厨里，主厨们抢着用唯一一口“招牌炒锅”，订单像雪花一样飞来。为了让后厨不闹成一锅粥，你装了一道“智能门禁”：门上的数字牌显示锅里有没有人用，进不去的人必须在门外排队——这就是并发世界的 AQS 内核。接着，你给炒锅定了“一人专用、可重复使用”的规矩（ReentrantLock）；配菜没备好时，厨师们去“备料等待室”歇着，备菜员备好菜喊号召唤（Condition）；至于怎么安排人手，则是另一门学问：长期主厨（核心线程）、排队区（任务队列）、临时帮厨（最大线程）、忙不过来就拒单（拒绝策略）——这一整套就是线程池调度。读完全文，你会像一位老练的店长：知道什么时候该加人、什么时候该排队、什么时候该拒单，也明白两个厨师互不相让为何会“死锁”。

岗位关联

高并发是 AI 服务的生命线：掌握 AQS 与线程池调优，你才能让大模型推理、向量检索等后端服务在流量洪峰中稳稳不崩，这是 AI 工程师从“能跑”走向“能扛”的关键一步。

目录
  1. 可视化演示
  2. AQS核心原理
  3. ReentrantLock实现
  4. Condition协作
  5. 线程池参数
  6. 执行流程与复用
  7. 死锁与饥饿
  8. 调优与监控
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态展示二叉搜索树通过比较键值逐步定位插入位置并添加新节点的过程，直观呈现BST的有序性维持原理。

本节配有交互动效（进入视口后自动加载，约 3KB）。

二叉搜索树插入 - 初始状态 从根节点开始比较键值大小 小于则走左子树，大于则走右子树 left<root<right 中序遍历有序

AQS核心原理

想象你的快餐店后厨装了一道“智能门禁”。门上的数字牌（state）显示现在有没有人在里面用锅：0 表示空，1 表示有人。想进去的厨师都得先刷门禁：数字牌是 0 就开门进去并把牌子翻成 1；牌子是 1 就得在门外排队，等里面的人出来翻回 0。这道“先看牌、再决定进不进”的规则，就是并发世界大名鼎鼎的 AQS 内核。

AQS 全称 AbstractQueuedSynchronizer，是 java.util.concurrent 的“地基”。它不具体管你锁的是什么，只提供三样东西：一个 int 类型的 state 状态变量、一个存储等待线程的 CLH 双向队列、以及一套固定不变的获取/释放模板流程。像 ReentrantLock、Semaphore、CountDownLatch 这些工具，本质都是继承 AQS 然后自定义“怎么才算获取成功”。

门禁框架把“什么条件能进”交给子类实现，自己只负责“进不去怎么办”。acquire 流程就是模板：先调用子类实现的 tryAcquire 尝试获取，成功就更新 state 进入临界区；失败就把当前线程包装成队列节点，挂到 CLH 队列尾部并调用 LockSupport.park 阻塞自己。这就像门禁系统只负责叫号和排队，至于“什么情况能放行”由店长说了算。

回到厨房：AQS 就像那套门禁的“施工图纸加排队护栏”，电磁锁的逻辑是固定的，但“什么条件放行”由店家自定义——装炒锅就是 ReentrantLock，装三个停车位就是 Semaphore，装“倒数 10 秒”就是 CountDownLatch。你只需要关心一件事：state 怎么定，其他排队、阻塞、唤醒的脏活累活，AQS 全包了。

acquire(n): tryAcquire(n)⇒{成功:state←state+n, 进入临界区失败:节点入队, park 阻塞等待唤醒\displaystyle \text{acquire}(n):\ \text{tryAcquire}(n) \Rightarrow \begin{cases} \text{成功}: & state \leftarrow state + n,\ \text{进入临界区} \\ \text{失败}: & \text{节点入队},\ \text{park 阻塞等待唤醒} \end{cases}
一句话：AQS 把“抢资源”拆成两步——子类决定能不能抢到（tryAcquire），模板决定抢不到怎么排队等待。
  1. tryAcquire 尝试获取子类实现的钩子方法，尝试获取 n 个同步状态，比如锁资源 n=1，返回是否成功。
    tryAcquire(n)⇒boolean\text{tryAcquire}(n) \Rightarrow \text{boolean}
  2. 更新 state获取成功时把资源计数加上 n，表示当前已占用资源数量由 0 变 n。
    state←state+n\text{state} \leftarrow \text{state} + n
  3. 失败入队阻塞获取失败则把当前线程包装成节点挂到 CLH 队列尾部，并挂起自己。
    node 入队尾; LockSupport.park(⋅)\text{node 入队尾};\ \text{LockSupport.park}(\cdot)
  4. 释放唤醒后继release 时把 state 减去 n，归零后唤醒队首的后继节点。
    state←state−n; state=0⇒unpark(队首)\text{state} \leftarrow \text{state} - n;\ \text{state} = 0 \Rightarrow \text{unpark}(\text{队首})

ReentrantLock实现

门禁装好了，现在给那口“招牌炒锅”上锁。一位厨师在炒菜时，其他厨师不能碰这口锅；但这位厨师自己可以随时再次“拿”起锅——比如炒完发现要回锅，他不必重新排队。这就是可重入：同一线程重复 lock 不会阻塞自己。

ReentrantLock 是 AQS 最经典的应用，lock() 对应 acquire(1)，unlock() 对应 release(1)。它把 state 当作“重入次数”：第一次获取 state 从 0 变 1，同线程再 lock 一次变 2，直到 unlock 减到 0 才算真正释放。锁内部还记录着当前持有线程的引用，这是判断“是不是我自己”的依据。

它提供公平与非公平两种模式。非公平锁（默认）像嗓门大的厨师可以直接插队抢锅，吞吐更高但可能让队首等待者饿着；公平锁严格先来先到，代价是频繁唤醒带来额外切换。加锁时先用 CAS 把 state 从 0 改 1，若 state 不为 0 再看持有者是不是自己，是就累加，不是就入队等着。

一口锅，一人用，重复用不排第二次队，用完了按次数还回去——这就是 ReentrantLock 的处世哲学。搞懂它，锁的世界你就解锁了一大半。

lock(非公平): state=0∧CAS(0→1)⇒获得锁;owner=当前线程⇒state←state+1\displaystyle \text{lock(非公平)}:\ \text{state}=0 \land \text{CAS}(0 \rightarrow 1) \Rightarrow \text{获得锁};\quad \text{owner}=\text{当前线程} \Rightarrow \text{state} \leftarrow \text{state}+1
一句话：ReentrantLock 就是“state 计数器 + 持有者身份”两件事，数到 0 才开门。
  1. 判断锁空闲当 state 为 0 表示锁空闲，尝试用 CAS 原子地把 state 从 0 改成 1。
    state=0∧CAS(0→1)\text{state} = 0 \land \text{CAS}(0 \to 1)
  2. 可重入累加如果锁已被当前线程持有，state 直接加一，无需排队。
    owner=当前线程⇒state←state+1\text{owner} = \text{当前线程} \Rightarrow \text{state} \leftarrow \text{state} + 1
  3. 释放递减unlock 每调用一次 state 减一，减到 0 才唤醒队列中等待的线程。
    state←state−1;state=0⇒唤醒队首\text{state} \leftarrow \text{state} - 1;\quad \text{state} = 0 \Rightarrow \text{唤醒队首}

Condition协作

炒菜还有个现实问题：菜还没备好，厨师却已经占着锅。硬等会白占资源，于是你设了一间“备料等待室”：配菜没到，厨师先放下锅去等待室歇着（await），锅空出来给其他人用；备菜员把菜备好，对着叫号屏喊一声（signal），等待室里最先进去的厨师回来重新抢锅。

Condition 必须依附 Lock 使用，通过 lock.newCondition() 创建。它维护一条独立的“条件等待队列”，与 AQS 的 CLH 同步队列分开。await() 相当于“释放锁 + 挂起”，signal() 相当于“把一个条件节点从条件队列移到同步队列尾部”，从“等待菜”变成“等待锅”。

典型场景是生产者-消费者：一个 Condition 管“队列没满才允许放”，另一个管“队列非空才允许取”。这比 Object.wait/notify 的优势在于精准：synchronized 只有一个等待室，notify 随机喊人，可能喊醒一个不需要被喊的线程；Condition 每个等待室独立叫号，各喊各的。

一句话：synchronized 是大堂广播“谁醒了谁上”，Condition 是专线叫号“备菜好了，那几位请回来”。要避免惊群、提高协作精度，选后者。

await: 释放锁; 节点入条件队列; park 挂起;signal: 条件队列头→CLH 队列尾\displaystyle \text{await}:\ \text{释放锁};\ \text{节点入条件队列};\ \text{park 挂起};\qquad \text{signal}:\ \text{条件队列头} \rightarrow \text{CLH 队列尾}
一句话：await 是“让出锅 + 进等待室”，signal 是“从等待室叫一个人回同步队列重新抢锁”。
  1. 释放锁await 必须先持有锁，调用后立即释放，让其他线程有机会进临界区。
    state←0; unpark(同步队列头)\text{state} \leftarrow 0;\ \text{unpark}(\text{同步队列头})
  2. 进入条件队列当前线程包装成节点进入 Condition 自己的等待队列并挂起。
    node→条件队列尾; park()\text{node} \rightarrow \text{条件队列尾};\ \text{park}()
  3. signal 转移唤醒时把条件队列头部的节点转移到锁的 CLH 队列尾部。
    条件队列头→signalCLH 队列尾\text{条件队列头} \xrightarrow{\text{signal}} \text{CLH 队列尾}
  4. 重新竞争被唤醒的线程重新走 acquire 流程，可能再次失败排队，成功后才从 await 返回。

线程池参数

店越开越大，光靠一两个厨师不行了。店长定下排班四件套：长期主厨人数（corePoolSize）、最多能叫的临时帮厨数（maximumPoolSize）、排队区座位数（任务队列容量）、以及实在接不下时怎么对待新订单（拒绝策略）。

ThreadPoolExecutor 的核心构造参数就是这四件套。新任务来了先看主厨有没有空；主厨全员上灶就把订单放排队区；排队区坐满才考虑叫临时帮厨；帮厨也满了就得启动拒绝策略。注意：核心线程数是“底气”，最大线程数是“上限”，队列是“缓冲”，三者联动决定吞吐。

拒绝策略有四种内置实现：AbortPolicy 直接抛异常（默认，像店员大喊“接不了”）；CallerRunsPolicy 让提交任务的线程自己干（像店长亲自下厨）；DiscardPolicy 静默丢弃（像装作没看见）；DiscardOldestPolicy 丢掉排队区最老的订单腾出位置。生产环境按业务容忍度挑选。

排班表不是拍脑袋定的：核心线程数按任务类型算，队列按峰值流量留余量，拒绝策略按“丢单可不可接受”选。这四件套，就是线程池配置的全部秘密。

提交任务: worker<core?⇒新建线程;队列未满?⇒入队;worker<max?⇒新建线程;⇒拒绝策略\displaystyle \text{提交任务}: \ \text{worker} < \text{core}? \Rightarrow \text{新建线程};\quad \text{队列未满}? \Rightarrow \text{入队};\quad \text{worker} < \text{max}? \Rightarrow \text{新建线程};\quad \Rightarrow \text{拒绝策略}
一句话：先捡现成的（核心线程），再让订单排队（队列），排不下才招临时工（非核心），还不行就执行拒单策略。
  1. 核心线程判断当前线程数小于核心线程数时，优先新建核心线程执行任务。
    workerCount<corePoolSize⇒addWorker\text{workerCount} < \text{corePoolSize} \Rightarrow \text{addWorker}
  2. 队列缓冲核心线程都忙则尝试把任务放入阻塞队列等待。
    workQueue.offer(r)⇒true?\text{workQueue.offer}(r) \Rightarrow \text{true?}
  3. 扩容判断队列满了且线程数小于最大线程数，才新建非核心线程。
    workerCount<maximumPoolSize⇒addWorker\text{workerCount} < \text{maximumPoolSize} \Rightarrow \text{addWorker}
  4. 拒绝兜底队列满且线程数到顶，执行 RejectedExecutionHandler。
    reject(r)⇒拒绝策略处理器\text{reject}(r) \Rightarrow \text{拒绝策略处理器}

执行流程与复用

高峰时段来了，订单像雪花一样飘进来。店长的调度是固定的：先看有没有闲着的长期主厨，有就让他接；主厨都忙着，订单放排队区；排队区满了，叫临时帮厨；临时帮厨也满了，启动拒单策略。这个顺序不能乱，每一步都是一次“拦截”。

提交任务的源码流程正是如此：先 addWorker 建核心线程，失败就 offer 进队列，入队成功再二次检查是否需要回退，入队失败则尝试 addWorker 建非核心线程，再失败就 reject。之所以“先队列后扩容”，是为了尽量复用已有线程，避免频繁创建销毁。

线程池用一个小技巧管理这一切：一个 int 类型的 ctl 变量，高 3 位存运行状态（RUNNING/SHUTDOWN/STOP/TIDYING/TERMINATED），低 29 位存 worker 数量。核心线程干完活会在队列上阻塞等着接下一单（复用），非核心线程空闲超过 keepAliveTime 就被回收。

换成人话：店长先拣现成的用，实在排不下才花钱请临时工，临时工活少就辞退。搞懂这个“四级分流”和“核心复用/非核心回收”，线程池在你眼里就不再是黑盒。

ctl=runState≪29  ∣  workerCount;workerCount=ctl  &  (229−1)\displaystyle \text{ctl} = \text{runState} \ll 29 \;|\; \text{workerCount};\qquad \text{workerCount} = \text{ctl} \;\&\; (2^{29} - 1)
一句话：一个 int 打包了“店铺状态 + 在岗人数”，店长看一眼数字就知道全局。
  1. 打包状态把运行状态左移 29 位，再与线程数做按位或，一个变量存两样信息。
    ctl=runState≪29∣workerCount\text{ctl} = \text{runState} \ll 29 \mid \text{workerCount}
  2. 取出线程数与掩码做按位与，取出低 29 位的线程数量。
    workerCount=ctl  &  (229−1)\text{workerCount} = \text{ctl} \;\&\; (2^{29} - 1)
  3. 生命周期迁移线程池在五个状态间单向迁移，shutdown 走优雅关闭。
    RUNNING→SHUTDOWN→STOP→TIDYING→TERMINATED\text{RUNNING} \rightarrow \text{SHUTDOWN} \rightarrow \text{STOP} \rightarrow \text{TIDYING} \rightarrow \text{TERMINATED}

死锁与饥饿

最混乱的场景来了：厨师 A 抢到锅铲，厨师 B 抢到油锅，A 想再要油锅，B 想再要锅铲，两人谁也不肯先松手，后厨彻底停摆——这就是死锁。

死锁有四个必要条件：互斥（资源只能一个人用）、持有并等待（拿一个还等一个）、不可抢占（别人抢不走）、循环等待（你等我、我等你）。四个条件全部满足才会死锁，打破任意一个即可预防。

工程上常用“统一锁顺序”：所有线程都先拿锅铲再拿油锅，就不会出现交叉等待；或使用 tryLock(timeout) 拿不到锁就放弃；或缩小锁粒度减少持有时间。另一个相关问题是线程饥饿：非公平锁下，新线程不断插队，队首线程可能永远轮不到，表现为“个别任务迟迟不执行”。

死锁是“互不相让”的僵局，饥饿是“一直被插队”的苦等。前者靠顺序与超时打破，后者靠公平锁或限流缓解。排班再好，也得定好“先拿哪把刀、再开哪口锅”的规矩。

死锁⇔互斥∧持有并等待∧不可抢占∧循环等待\displaystyle \text{死锁} \Leftrightarrow \text{互斥} \land \text{持有并等待} \land \text{不可抢占} \land \text{循环等待}
一句话：四个条件凑齐就是锁死，拆掉任何一个条件就能救活整个后厨。
  1. 互斥条件资源同一时刻只能被一个线程占用，好比一口锅只能一人用。
    资源独占\text{资源独占}
  2. 持有并等待线程持有一把锁还想拿另一把锁，如 A 拿锅要铲。
    持有∧等待新资源\text{持有} \land \text{等待新资源}
  3. 不可抢占资源不能被强行夺走，只能等持有者主动释放。
    ¬抢占\neg \text{抢占}
  4. 循环等待多个线程形成头尾相接的等待环。
    线程1→线程2→⋯→线程1\text{线程1} \rightarrow \text{线程2} \rightarrow \cdots \rightarrow \text{线程1}

调优与监控

生意要做大，光排班还不够，得按客流类型算人手。如果后厨全是“纯炒菜”（CPU 密集），主厨数定成灶台数加一就够——多一个是为了扛住偶发等待；如果菜谱老是“边炒边等备菜”（IO 密集），一个主厨能同时照看两三口锅，人数就要按等待/计算比例放大。

业界经验公式：CPU 密集任务核心线程数约为 CPU 核数加一；IO 密集任务核心线程数约为 CPU 核数乘以（1 + 等待时间/计算时间）。但公式只是起点，最终要靠压测校准：观察队列积压长度、拒绝次数、线程池活跃度三个指标。

监控指标包括：activeCount（在岗厨师）、queue.size（排队人数）、completedTaskCount（累计出餐数）、rejectedCount（拒单数）。当队列长期不空且拒绝数上涨，说明人手不足，可调大 core 与 max；当队列常年为空且线程利用率低，说明浪费，应调小。许多框架还支持 setCorePoolSize 动态调整，像店长按小时改排班。

调优的本质是“让排队区和拒单数都回到零”——既不浪费人手，也不让订单等太久。公式给起点，监控给方向盘，动态调整就是油门和刹车。

Ncpu=Ncores+1;Nio=Ncores×(1+t等待t计算)\displaystyle N_{cpu} = N_{\text{cores}} + 1;\qquad N_{io} = N_{\text{cores}} \times \left(1 + \frac{t_{\text{等待}}}{t_{\text{计算}}}\right)
一句话：CPU 密集少招人，IO 密集多招人，最终以“队列不积压、拒绝数为零”为准。
  1. CPU 密集估算核心线程数设为 CPU 核数加一，减少上下文切换。
    Ncpu=Ncores+1N_{cpu} = N_{cores} + 1
  2. IO 密集估算核数乘以等待时间与计算时间之比加一。
    Nio=Ncores×(1+twait/tcompute)N_{io} = N_{cores} \times (1 + t_{wait} / t_{compute})
  3. 压测验证观察队列长度与拒绝数趋近于零，即参数健康。
    queue.size→0, rejected→0⇒参数合理\text{queue.size} \rightarrow 0,\ \text{rejected} \rightarrow 0 \Rightarrow \text{参数合理}

AI 应用场景

大模型推理服务的线程池调优

阶段：模型服务部署与性能优化

解决的问题：传统做法盲目把线程数拉满，导致 CPU 上下文切换失控、GPU 排队激烈；用本文的“四级分流”和 CPU/IO 估算公式，把推理请求合理送进有界队列，让资源利用率与响应延迟达到平衡。

具体案例：某推荐团队部署向量召回服务，压测发现 core=8、max=16、有界队列容量 1000、AbortPolicy 的组合最稳，p99 延迟从 800ms 降到 300ms，拒绝异常数从每分钟几十次降为零。

训练数据流水线的生产者-消费者协作

阶段：数据预处理与样本流水线

解决的问题：爬虫生产者往队列放样本、清洗消费者取样本，若用 Object.wait/notify 会出现惊群和随机唤醒；用 ReentrantLock 搭配两个 Condition（notEmpty 与 notFull）实现精准叫号，生产和消费互不干扰。

具体案例：某 CV 团队的数据管道用 lock.newCondition() 分别管理“队列非空”与“队列未满”，吞吐提升约 40%，且不再出现多消费者同时被唤醒的惊群现象。

分布式训练中的锁思想延伸

阶段：多机分布式训练协调

解决的问题：单机 AQS 的 state 思路可以延伸到分布式锁：多机训练任务抢占唯一模型注册表的写权限时，参考“state 计数 + 等待队列”设计基于 Redis 的公平锁，避免多机同时写坏 checkpoint。

具体案例：某大模型训练平台用 Redis 分布式锁 + 等待队列实现“同一时间只有一个 worker 上传梯度”，训练稳定性显著提升，不再出现 checkpoint 冲突。

Python 演示

python61 行
import queueimport threadingimport timefrom concurrent.futures import ThreadPoolExecutor  class KitchenScheduler:    """用餐厅订单分流模拟 Java ThreadPoolExecutor 的调度流程"""     def __init__(self, core_chefs=2, max_chefs=4, queue_capacity=3):        self.core_chefs = core_chefs          # 核心线程数: 长期主厨        self.max_chefs = max_chefs            # 最大线程数: 主厨+临时帮厨        self.queue_capacity = queue_capacity  # 任务队列容量        self.working = 0                      # 当前在岗厨师数        self.wait_queue = queue.Queue(maxsize=queue_capacity)  # 排队区        self.rejected = []                    # 被拒订单记录        self.guard = threading.Lock()         # 保护共享计数     def submit(self, order_no):        """提交任务: 核心线程 -> 队列 -> 非核心线程 -> 拒绝策略"""        with self.guard:            if self.working < self.core_chefs:                self.working += 1                return "RUNNING: core chef takes order %d" % order_no            if not self.wait_queue.full():                self.wait_queue.put(order_no)                return "QUEUED: order %d waits in line" % order_no            if self.working < self.max_chefs:                self.working += 1                return "RUNNING: temp chef takes order %d" % order_no            self.rejected.append(order_no)            return "REJECTED: order %d refused" % order_no     def finish(self):        """厨师完工, 释放一个执行名额"""        with self.guard:            if self.working > 0:                self.working -= 1  def real_pool_demo():    """用真实 ThreadPoolExecutor 演示 2 个线程处理 6 个任务"""    pool = ThreadPoolExecutor(max_workers=2, thread_name_prefix="chef")     def cook(order_no):        time.sleep(0.2)        return "order-%d done" % order_no     futures = [pool.submit(cook, i) for i in range(6)]    for f in futures:        f.result()    pool.shutdown(wait=True)  if __name__ == "__main__":    s = KitchenScheduler()    for order in range(8):        print(s.submit(order))    print("rejected orders:", s.rejected)    real_pool_demo()    print("real pool demo finished")
目的：用 Python 模拟 Java ThreadPoolExecutor 的“核心线程 → 队列 → 非核心线程 → 拒绝策略”四级调度，跑一遍就能直观看到每个订单被分到哪一步。
  1. with self.guard:加锁保护共享计数，模拟并发环境下的线程安全。
  2. if self.working < self.core_chefs:第一步：核心线程（主厨）有空就优先复用。
  3. if not self.wait_queue.full():第二步：核心线程忙，订单先进入排队区。
  4. if self.working < self.max_chefs:第三步：排队区满才扩容创建临时线程。
  5. self.rejected.append(order_no)第四步：全员告急，记录被拒订单。
  6. return "REJECTED: order %d refused" % order_no对应 Java 的 AbortPolicy 式拒单。
  7. pool = ThreadPoolExecutor(max_workers=2, thread_name_prefix="chef")真实线程池对照实验，验证 2 个线程也能复用处理 6 个任务。

常见误区

误区“我把核心线程数调到 500，总该够用了吧？反正内存大、CPU 核多，多开线程肯定更快。”

正解线程数是“人”，CPU 是“灶台”。500 个厨师抢 16 口锅，大部分时间耗在抢锅和交接切换上，吞吐反而下降。正确做法按任务类型估算：CPU 密集 = 核数 + 1，IO 密集按等待/计算比放大，最后用压测验证队列与拒绝率。

为何常见：直觉上“人越多干活越快”，忽略了上下文切换与资源争抢的开销。

误区“用无界队列就不会抛拒绝异常了，最安全，任务永远进得来。”

正解无界队列会“吞掉”全部任务，maximumPoolSize 永远不触发；当任务堆积到内存溢出时系统直接崩溃，比拒单严重得多。生产环境常用有界队列 + 明确拒绝策略，让压力在入口处可见可监控。

为何常见：只看到“不会抛异常”的表面优点，没意识到内存水位上涨和最大线程数失效的风险。

误区“Condition 的 await 不就是 wait 吗？synchronized 也能做到，没必要学新的。”

正解Object.wait 只有一个等待室，notify 无法指定唤醒谁；Condition 允许一把锁上创建多个等待室（多个 Condition），signal 可以精准叫号。比如生产者消费者的 notEmpty 与 notFull 分开管理，这就是“专线叫号”与“大堂广播”的区别。

为何常见：两者语义相似（释放锁 + 挂起），容易忽略精准唤醒的价值，直到出现惊群才醒悟。

误区“公平锁先来先服务，名字里带'公平'，生产环境肯定应该用公平锁。”

正解公平锁严格排队，但线程频繁 park/unpark 切换开销大，吞吐更低；非公平锁允许新线程插队，减少唤醒开销，吞吐更高，但极端流量下队首线程可能被饿着。所以 ReentrantLock 默认非公平，只有对延迟公平性有硬要求才用公平锁。

为何常见：把“公平”这个正面词直接等同于“更好”，忽略了吞吐与公平之间的取舍。

误区“线程空闲一段时间后，不管是核心还是非核心，都会超时回收。”

正解默认情况下核心线程是“长期主厨”，干完活原地待命不辞退（allowCoreThreadTimeOut=false）；keepAliveTime 只作用于非核心线程。若想回收核心线程，必须显式调用 allowCoreThreadTimeOut(true)。

为何常见：把“线程空闲回收”当成了统一规则，没注意核心线程与非核心线程的生命周期差异。

面试题

Q1. 在 AQS 中，整型变量 state 的主要作用是什么？

单选题 · easy

  • A.记录锁被获取的次数或线程数← 正确答案
  • B.存储等待队列的链表指针
  • C.保存当前持有锁的线程对象
  • D.标记线程池的运行状态

答案：A。state 是 AQS 的三大核心之一，表示共享资源的占用状态：互斥锁用 0/1 表示空闲与占用，可重入锁累加重入次数，信号量记录剩余许可数。等待队列指针由 CLH 队列管理，持有者身份由锁实现自己记录。

Q2. ReentrantLock 默认采用哪种锁策略？

单选题 · easy

  • A.公平锁先来先服务
  • B.非公平锁允许插队← 正确答案
  • C.读写锁读读并行
  • D.乐观锁不加锁同步

答案：B。ReentrantLock 默认是非公平锁，允许新线程直接 CAS 插队抢锁，减少线程唤醒切换从而提高吞吐；公平锁需要构造时传 true 开启。读写锁是 ReentrantReadWriteLock 的事，乐观锁则属于无锁编程。

Q3. 关于 Condition 的 await 与 signal，下列说法正确的是？

单选题 · mid

  • A.signal 会立即唤醒并运行等待线程
  • B.await 会让当前线程释放锁并挂起← 正确答案
  • C.signal 一次必定唤醒所有线程
  • D.await 不需要先持有锁就能调用

答案：B。await 会释放当前持有的锁并把线程放入条件队列挂起；signal 只把条件队列头部的节点转移到 CLH 队列尾部，并不会立即获得锁，需要重新竞争；唤醒全部用 signalAll；await 必须持有锁才能调用，否则抛异常。

Q4. ThreadPoolExecutor 提交任务时，正确的处理顺序是？

单选题 · mid

  • A.先入队再判断核心线程
  • B.先建临时线程再入队
  • C.核心队列非核心拒绝← 正确答案
  • D.队列满则直接拒绝

答案：C。标准顺序是：核心线程未满先建核心线程；核心已满则任务入队列；队列已满才建非核心线程；线程数到最大仍未接纳才执行拒绝策略。这个顺序既优先复用线程，又控制资源上限。

Q5. 使用无界任务队列时，maximumPoolSize 参数会？

单选题 · mid

  • A.正常生效帮助扩容
  • B.永不触发停在核心数← 正确答案
  • C.导致拒绝策略频繁触发
  • D.让核心线程全部回收

答案：B。无界队列永远不会满，任务永远能入队，因此“队列满才扩容非核心线程”这条路始终走不到，maximumPoolSize 形同虚设，线程数停留在核心数。这也说明配置队列与最大线程数必须配套考虑。

Q6. 关于线程饥饿与死锁，下列说法正确的是？

单选题 · hard

  • A.死锁只发生在多核 CPU 上
  • B.饥饿的线程占有锁但不放手
  • C.公平锁可降低线程饥饿风险← 正确答案
  • D.死锁四条件缺一仍会死锁

答案：C。公平锁先来先服务，新线程不能插队，可显著降低饥饿风险。死锁单核也会发生；饥饿的线程是抢不到锁而非不放手；死锁四条件缺一不可。区分“持有锁不放手”（死锁）与“一直抢不到锁”（饥饿）是高频考点。

Q7. 计算密集型任务的线程池核心线程数宜设置为？

单选题 · mid

  • A.CPU 核心数加一← 正确答案
  • B.CPU 核心数乘一百
  • C.总任务数的一半
  • D.固定为一保证串行

答案：A。CPU 密集任务几乎不等待，线程数超过核数只会增加上下文切换，业界经验为“核数 + 1”以应对偶发停顿；IO 密集任务才需要乘以等待/计算比放大线程数。

Q8. AQS 的三大核心组成部分包括哪些？

多选题 · hard

  • A.同步状态记录变量← 正确答案
  • B.CLH 双向等待队列← 正确答案
  • C.模板方法框架结构← 正确答案
  • D.内置哈希表缓存

答案：ABC。AQS 由 state 同步状态、CLH 双向等待队列、模板方法框架三部分组成：state 记录资源占用，CLH 队列管理等待线程，模板方法固定获取/释放流程，由子类通过 tryAcquire 等钩子定制。哈希表与 AQS 无关。

Q9. 以下哪些是 ThreadPoolExecutor 的内置拒绝策略？

多选题 · mid

  • A.Abort 策略直接抛异常← 正确答案
  • B.Caller 策略调用者执行← 正确答案
  • C.Discard 策略静默丢弃← 正确答案
  • D.Greedy 策略贪心扩容

答案：ABC。内置四种拒绝策略是 AbortPolicy（抛异常）、CallerRunsPolicy（调用者线程执行）、DiscardPolicy（静默丢弃）、DiscardOldestPolicy（丢弃最老任务）；GreedyPolicy 并不存在，是干扰项。

Q10. 死锁产生的必要条件有哪些？

多选题 · easy

  • A.互斥条件资源独占← 正确答案
  • B.持有并等待新资源← 正确答案
  • C.资源不可被强行抢占← 正确答案
  • D.循环等待四者齐备← 正确答案

答案：ABCD。死锁四个必要条件缺一不可：互斥、持有并等待、不可抢占、循环等待。预防死锁就是破坏其中任意一个条件，例如统一锁顺序破坏循环等待，tryLock 超时破坏不可抢占。