LDAP批量认证需按响应延迟反推线程数，核心线程数≈目标QPS÷单线程每秒处理数，初始设CPU核数×3～5并向下取整至服务端连接上限；最大线程数为core的1.2～1.5倍；队列用ArrayBlockingQueue（容量200～500），拒绝策略选CallerRunsPolicy；须配连接超时、复用连接池并压测调优。
LDAP批量认证是典型的IO密集型任务——大量时间花在等待目录服务器响应上，而非本地CPU计算。线程池配置不当，轻则吞吐上不去，重则打爆LDAP服务端连接数或触发防火墙限流。关键不是“并发越多越好”，而是让线程数与LDAP服务端承载能力、网络延迟、客户端资源形成匹配。
核心线程数：按LDAP响应延迟反推
不能只看CPU核数。假设单次bind操作平均耗时 80ms（含网络RTT + 服务端处理），其中真正占用线程的时间约 5ms，其余 75ms 是阻塞等待。那么单线程每秒最多完成约 12 次认证（1000ms ÷ 80ms）。若目标吞吐是 600 QPS，理论最小线程数 ≈ 600 ÷ 12 = 50。
实际配置建议：
- 初始值设为 CPU核数 × 3～5（例如16核机器配48～80）
- 必须结合 LDAP服务端最大并发连接数（如OpenLDAP默认 slapd.conf 中
threads或conn_max_pending设置）向下取整 - 若使用连接池（如UnboundID LDAP SDK），核心线程数 ≤ 连接池最大空闲连接数，避免连接争抢
最大线程数：严守下游水位线
LDAP服务端通常对并发连接/请求有硬限制。盲目扩大 maximumPoolSize，只会导致大量连接超时、TCP重传、甚至服务端拒绝新连接。
立即学习“Java免费学习笔记（深入）”；
推荐策略：
- 设为 corePoolSize 的 1.2～1.5 倍（如 core=60，则 max=72～90），保留小幅弹性
- 绝对不要超过 LDAP 服务端明确声明的并发上限（例如 Active Directory 默认每DC约 100～200 并发bind）
- 配合监控：一旦活跃线程数持续 > 90% max，说明上游压力已逼近临界，应触发告警而非继续扩容
队列类型与容量：用有界队列守住内存底线
LDAP认证失败或超时任务不会自动释放连接资源，无界队列（如 LinkedBlockingQueue 默认 Integer.MAX_VALUE）极易堆积失败任务，引发 OOM 或掩盖真实瓶颈。
务必采用：
- ArrayBlockingQueue，容量设为 200～500（与预期峰值QPS匹配，例如目标峰值800 QPS，队列设为300较稳妥）
- 禁用 Executors.newFixedThreadPool() 等封装——它们底层用无界队列，生产环境属高危配置
- 队列满时，拒绝策略优先选 CallerRunsPolicy：让Web容器线程（如Tomcat线程）同步执行认证，天然实现反压，避免雪崩
拒绝策略与连接管理：失败不丢，超时可控
单纯丢弃任务（AbortPolicy/DiscardPolicy）会导致认证丢失，业务不可接受；而盲目重试可能加剧服务端压力。
更务实的做法：
- 自定义 RejectedExecutionHandler，记录被拒请求的用户DN、时间戳，并写入本地环形缓冲区供快速排查
- 为每个LDAP连接设置明确超时：connectTimeout=3s，responseTimeout=5s，避免线程长期卡死
- 复用连接池（如LdapConnectionPool），连接空闲回收时间 ≤ keepAliveTime，防止连接泄漏
- keepAliveTime 设为 60～120秒，既释放闲置资源，又避免频繁重建连接开销
不复杂但容易忽略：参数定好后，必须用真实LDAP服务做压测，观察服务端连接数、CPU、bind成功率三指标拐点，再微调。上线后持续采集线程池活跃数、队列长度、拒绝数，这些才是真实水位标尺。
