1. 课程导入与全景认知
在真实的高并发系统中，任务调度并不是一个“把任务丢给线程执行”的简单动作。它同时牵涉到请求到达速率、任务类型、资源上限、排队策略、拒绝策略、超时控制、监控告警以及故障隔离等多个维度。很多线上事故的根因，并不是业务逻辑写错，而是任务在进入执行阶段之前，就已经在队列里堆积、在资源上争抢、在策略上失控。因此，本课程的第一件事，是建立一张“全景认知图”：先看清高并发任务调度到底难在哪里，再理解线程池工程为什么是解决这些问题的核心抓手，最后明确整门课程的知识地图与实战目标。
一、高并发任务调度的核心挑战
高并发任务调度的本质，是在有限资源下对“任务流”进行有序、可控、可观测的分配。它面临的挑战可以归纳为四类。
第一，任务到达速率与处理能力不匹配。假设某服务每秒收到 8000 个请求，每个请求平均耗时 20ms，那么理论上需要的并发处理能力约为 8000 × 0.02 = 160 个并发执行单元。如果线程池最大线程数只有 64，队列容量为 200，那么系统在持续高压下会迅速进入“队列填满—拒绝—上游重试—压力更大”的恶性循环。这个简单估算说明：线程池参数不是拍脑袋决定的，而是与 QPS、任务耗时、资源上限直接相关。
第二，任务类型混杂导致资源争抢。同一个线程池里既有 5ms 的缓存查询，也有 2s 的远程调用，还有 500ms 的批量计算。短任务会被长任务阻塞，长任务会占满线程，最终所有任务一起变慢。这就是典型的“快慢任务混跑”问题，也是后续章节要重点解决的隔离与拆分问题。
第三，队列与拒绝策略的隐性风险。无界队列看似“不会丢任务”，实际上会把内存打满，最终触发 OOM；有界队列配合 AbortPolicy 会直接抛异常，如果上游没有正确处理，就会造成请求失败；CallerRunsPolicy 会把任务退回给提交线程执行，可能拖慢整个 Web 容器。不同策略没有绝对好坏，只有是否匹配当前业务场景。
第四，缺乏可观测性导致故障定位困难。线程池活跃线程数、队列长度、完成任务数、拒绝次数、任务等待时间，这些指标如果不上报，线上出现“接口变慢”时，你根本不知道是线程池满了、队列堵了，还是下游依赖慢了。没有度量，就没有控制。
二、线程池工程的价值定位
线程池工程的价值，不是“少创建几个线程”这么简单。它至少承担五个职责：资源复用，避免频繁创建销毁线程带来的开销；流量削峰，用队列缓冲突发流量；故障隔离，让不同业务使用不同线程池，避免相互拖垮；过载保护，通过有界队列和拒绝策略防止系统雪崩；可观测治理，通过指标暴露让容量规划和故障定位有据可依。
换句话说，线程池是连接“业务任务”和“系统资源”之间的调度层。它既不是单纯的工具类，也不是一劳永逸的配置项，而是一套需要持续观测、调整和治理的工程机制。
三、课程知识地图
整门课程围绕“认知—原理—参数—实战—治理”展开，共 30 章，可以划分为五个阶段。
| 阶段 | 核心内容 | 目标 |
|---|---|---|
| 认知与全景 | 核心挑战、价值定位、知识地图 | 建立全局视角，明确学习路径 |
| 原理与机制 | 线程池生命周期、任务提交、队列、拒绝策略、Worker 执行 | 理解底层运行机制 |
| 参数与容量 | 核心/最大线程数、队列容量、KeepAlive、QPS 与耗时估算 | 能根据业务场景计算合理参数 |
| 实战与调优 | 快慢隔离、动态调整、超时控制、上下文传递、压测验证 | 能落地到真实项目并验证效果 |
| 治理与排障 | 监控指标、告警规则、常见故障树、复盘方法 | 能定位问题并持续治理 |
四、实战目标与学习方式
本课程不是纯理论讲解，而是以“可运行、可观测、可验证”为目标。学完之后，你应该能够独立完成以下任务：
- 根据 QPS、平均耗时和资源上限，估算线程池核心参数，而不是凭经验拍数字；
- 识别快慢任务混跑、队列无界、拒绝策略不当等典型风险，并给出拆分或隔离方案；
- 为线程池接入活跃线程数、队列长度、拒绝次数等指标，并设置合理告警阈值；
- 在压测中观察线程池状态变化，判断瓶颈是在线程、队列、下游依赖还是数据库；
- 面对线上“接口变慢”类问题，能够按线程池—队列—下游依赖的顺序快速排查。