“CPU 密集型任务设为 CPU 核数加一，I/O 密集型任务设为 CPU 核数乘二”是一个不错的起点，却不是生产配置的终点。
线程池真正需要回答三个问题：
- 任务阻塞时，谁会先被拖垮？
- 高峰来临时，应该排队、快速失败，还是降级？
- 下游服务能承受多大的并发？
一个为搜索构建的线程池和一个为支付回调构建的线程池，拒绝策略往往应该完全不同。前者可以快速失败并返回兜底结果，后者则更需要保序、重试和可追踪的补偿机制。
因此，参数配置应该从业务的失败语义开始，再结合监控数据持续调整。公式负责给出初值，工程设计才决定最终值。