ThreadPoolExecutor 构建弹性爬虫引擎的关键是动态伸缩：用 SynchronousQueue 配合 corePoolSize=2~4、maximumPoolSize=50~200、keepAliveTime=60s，并启用 allowCoreThreadTimeOut(true) 实现扩缩容；任务提交需节流、超时控制与拒绝处理。
用 ThreadPoolExecutor 构建弹性伸缩的爬虫引擎，核心不是“堆线程”，而是让线程池能随任务负载自动增减——关键在合理配置 corePoolSize、maximumPoolSize、keepAliveTime 和拒绝策略，并配合动态任务提交与空闲收缩机制。
选对线程池类型：用 SynchronousQueue + 无界队列策略
爬虫任务 I/O 密集、响应时间波动大，不适合用有界队列（易触发拒绝）或 LinkedBlockingQueue（线程数卡死在 corePoolSize，无法弹性）。推荐：
- 使用
SynchronousQueue：不缓存任务，新任务直接尝试创建新线程（只要未达 maximumPoolSize），天然支持“按需扩容” - 设置
corePoolSize = 2~4：保底处理基础请求，避免空转开销 - 设置
maximumPoolSize = 50~200（根据机器 CPU+网络带宽实测调整）：上限防雪崩，非固定值，可结合监控动态调优 -
keepAliveTime = 60L秒：空闲线程超时后回收，实现“缩容”
让线程真正“活”起来：避免空转，主动释放资源
默认情况下，即使所有任务完成，corePoolSize 内的线程也常驻。爬虫低峰期需主动收缩：
- 调用
allowCoreThreadTimeOut(true)：使 core 线程也受 keepAliveTime 约束，空闲后销毁 - 搭配
prestartAllCoreThreads()可选：启动时预热 core 线程，减少首波请求延迟 - 不依赖 shutdown()：爬虫是长期服务，用
awaitTermination()配合信号控制更合适
任务提交要带反馈，防止盲目堆积
弹性不等于无节制提交。需结合爬取目标的响应节奏做节流：
立即学习“Java免费学习笔记（深入）”；
- 提交任务时捕获
RejectedExecutionException：说明已达 maximumPoolSize 或线程创建失败，此时应退避（如 sleep 后重试）或降级（写入本地队列暂存） - 用
execute()而非submit()：避免 Future 对象堆积内存；若需结果，统一用 CompletionService 包装 - 给每个 URL 任务封装超时控制（如
CompletableFuture.orTimeout(10, TimeUnit.SECONDS)），防止单个慢请求拖垮整池
加一层轻量级自适应调节（可选但实用）
纯静态参数难适配全天流量曲线。可加简单反馈环：
- 统计每分钟成功/失败/超时请求数、平均响应时间、当前活跃线程数
- 当失败率 > 15% 且活跃线程 ≈ maximumPoolSize → 临时下调 maximumPoolSize（如 -10），观察恢复情况
- 当平均响应时间持续
- 用 AtomicIntegerFieldUpdater 或 volatile int 控制参数，避免锁竞争
不复杂但容易忽略：弹性 ≠ 无限扩容，而是“够用即止、闲则释放”。把 ThreadPoolExecutor 当作呼吸器官来调——吸（扩容）靠任务驱动，呼（缩容）靠空闲倒计时，再加点感知能力，爬虫引擎就能稳住脉搏跑一整天。
