优先选用FixedThreadPool，慎用CachedThreadPool；其因CachedThreadPool无限制创建线程易致GC风暴或资源耗尽，而FixedThreadPool通过固定线程数与有界队列保障稳定性和可控性。
线程池类型选择：优先用 FixedThreadPool，慎用 CachedThreadPool
在 Elasticsearch 客户端（如 RestHighLevelClient）高并发批量写入场景中，客户端内部的异步请求执行器（RestClient 的 HttpClient 底层）默认使用 Executors.newCachedThreadPool()，但它会无限制创建线程，容易引发 GC 风暴或系统资源耗尽。实际生产中更推荐显式配置一个有界线程池：
- 使用 Executors.newFixedThreadPool(n) 或更优的 new ThreadPoolExecutor(core, max, keepAlive, unit, workQueue)
- 核心线程数建议设为 CPU 核数 × 2 ~ × 4（例如 8 核机器设 16~32），避免过度抢占 CPU
- 队列类型推荐 ArrayBlockingQueue（有界），容量建议 100~500，防止 OOM；避免用 LinkedBlockingQueue（无界）或 SynchronousQueue（易拒绝）
批量写入与线程池的协同节奏：控制并发请求数 ≤ 线程池容量
很多问题源于“批量写入并发量”和“HTTP 客户端线程池”不匹配。例如：启动 100 个 bulkAsync() 请求，但线程池只有 8 个线程 + 队列满，会导致大量请求排队甚至超时。
- 建议通过信号量（Semaphore）或自定义批处理控制器，将并发请求数限制在线程池核心数的 1.5~2 倍以内（如线程池 20，最大并发 bulk 请求控制在 30~40）
- 每次 BulkRequest 包含文档数建议 500~2000 条（视文档大小而定），避免单次请求过大触发 ES 的 http.max_content_length 限制或 OOM
- 启用 bulk().setRefreshPolicy(RefreshPolicy.WAIT_UNTIL) 仅在必要时，否则增加延迟
连接池与超时参数必须同步调优
线程池只是客户端一环，底层 HTTP 连接池（Apache HttpClient）若未适配，会成为瓶颈：
- 设置最大连接数（setMaxConnTotal）≥ 线程池最大线程数（如线程池 max=32，则设 40+）
- 单路由最大连接数（setMaxConnPerRoute）建议 ≥ 线程池核心数（如 core=20，则设 24）
- 连接超时（setConnectionRequestTimeout）、连接建立超时（setConnectTimeout）、读取超时（setSocketTimeout）建议统一设为 10~30 秒，避免线程长时间阻塞等待
- 启用连接保活（setKeepAliveStrategy），复用连接减少握手开销
监控与熔断：别只看吞吐，要盯住拒绝率与队列堆积
调优后必须验证效果，关键指标不是“QPS 越高越好”，而是稳定性：
- 观察线程池的 getQueue().size() 和 getActiveCount()，持续 >80% 容量说明过载
- 捕获 EsRejectedExecutionException（ES 侧拒绝）和 RejectedExecutionException（客户端线程池拒绝），一旦出现需降并发或扩容
- 在批量写入逻辑中加入简单熔断：连续 3 次 bulk 失败或平均响应时间 >5s，自动暂停 1s 后重试
- 推荐接入 Micrometer + Prometheus，暴露 elasticsearch.bulk.queue.size、client.threadpool.active 等自定义指标
