线程池大小需匹配i/o特性，核心线程数建议cpu核数×2～4（如4核配16），用有界队列（如arrayblockingqueue(100)），maxpoolsize设为core的1.5～2倍，拒绝策略优选callerrunspolicy，keepalivetime设30～60秒并自定义命名threadfactory。
处理外部 API 并发调用时，线程池不是越大越好，关键在于匹配 I/O 特性、控制资源消耗、避免雪崩。核心是让线程数与等待时间、机器能力形成合理配比。
按 I/O 密集型任务设定核心线程数
外部 API 调用本质是 I/O 密集型：线程大部分时间在等待网络响应，而非占用 CPU 计算。此时线程数应显著高于 CPU 核心数。
- 基础公式：corePoolSize ≈ CPU 核心数 × 2～4（常见取值为 8～32，视单次调用平均耗时和并发量而定）
- 例如：4 核机器 + 平均响应 300ms 的 HTTP 接口，可先设 corePoolSize = 16
- 不建议直接用
Runtime.getRuntime().availableProcessors() * 2硬编码，需结合压测验证
用有界队列防止内存失控
无界队列（如 LinkedBlockingQueue()）极易引发 OOM，尤其在下游接口变慢或超时时，任务持续堆积。
- 优先选用
ArrayBlockingQueue，容量建议设为 50～200（与核心线程数呈 3～5 倍关系） - 示例：
new ArrayBlockingQueue(100) - 避免
SynchronousQueue用于批量场景——它要求提交瞬间就有空闲线程，否则直接触发拒绝策略，容错性差
最大线程数与拒绝策略协同设计
maximumPoolSize 不是兜底数字，而是“可控扩容上限”。配合拒绝策略，才能让系统在压力下仍可预期地降级。
- maxPoolSize 可设为 corePoolSize 的 1.5～2 倍（如 core=16，则 max=24～32）
- 拒绝策略推荐
CallerRunsPolicy：当队列满且线程达上限时，由调用方线程（如 Web 请求线程）执行任务，自然限流，避免丢任务也不激增线程 - 慎用
AbortPolicy（默认），它抛异常可能让上游未捕获而失败；DiscardPolicy适合日志类等可丢失任务
空闲线程回收与线程命名便于排查
非核心线程若长期闲置却不释放，会白白占用堆外内存（如连接池、TLS 缓冲区）；无意义的线程名则增加运维定位难度。
- 设置合理的
keepAliveTime（如 30～60 秒），让临时扩容的线程及时退出 - 务必使用自定义
ThreadFactory，为线程命名（如"api-call-pool-%d"），方便在堆栈、监控中识别来源 - 避免使用
Executors.newFixedThreadPool()—— 它隐藏了参数细节且无法设命名工厂
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
