线程池是防御恶意请求的第一道资源闸门，需通过合理配置核心参数（如maxThreads、acceptCount、connectionTimeout）、选用有界队列与反压型拒绝策略（如CallerRunsPolicy）、前置限流校验及实时监控实现可观察、可响应的防护体系。
线程池本身不是“防火墙”，但它是防御恶意大量请求的第一道资源闸门。关键不在于堆大参数，而在于让线程池在资源真正耗尽前就主动拒绝、缓冲或降级，把冲击控制在可观察、可响应的范围内。
合理配置线程池核心参数，堵住连接与执行层漏洞
Tomcat 或 Spring Boot 内嵌容器默认线程池往往偏宽松，需按实际硬件和业务压力调整：
- maxThreads：建议设为 CPU 核心数 × 20～30（如 8 核设 160～240），避免线程数远超系统承载能力；超过此数的新请求将排队或被拒，而非无序创建线程
- acceptCount：设为 50～200 的有界值（如 100），作为“缓冲队列”。它不是无限等待区，而是明确告诉系统：“最多容你等这么多”，超出即快速失败，防止恶意长连接占满连接槽位
- connectionTimeout：设为 10～20 秒（如 15000ms），强制断开空闲连接，缩短攻击者维持半开连接的时间窗口
选用有界队列 + 匹配的拒绝策略，避免任务静默丢失
无界队列（如 LinkedBlockingQueue 无参构造）是高危配置——它会让所有超额请求堆积在内存中，最终触发 OOM。必须用有界队列，并搭配能反馈行为的拒绝策略：
- 用 ArrayBlockingQueue(容量) 替代无界队列，容量建议设为 maxThreads 的 1～2 倍（如 200 线程配 300 队列）
- 慎用默认 AbortPolicy（抛异常丢任务）：若上层未捕获 RejectedExecutionException，请求会无声失败
- 推荐 CallerRunsPolicy：当线程池和队列都满时，由调用方线程（如 Tomcat 工作线程）同步执行该任务。这会自然拖慢请求吞吐，形成反压，给系统喘息时间，且不丢失任务
- 更稳妥的做法是自定义拒绝策略，记录日志 + 上报监控（如 Prometheus + AlertManager），实现“可感知的拒绝”
分层限流 + 参数校验，不让恶意请求抵达线程池
线程池是最后一道防线，不能指望它扛下全部攻击流量。必须前置拦截：
- 在网关层（Nginx / Spring Cloud Gateway）做 IP/用户级 QPS 限流，例如
limit_req zone=api burst=20 nodelay，防代理池轮询 - 在 Controller 层用 @Valid + 自定义注解 拦截畸形参数：对 Base64 编码字段做长度限制、对 JSON 入参做深度/大小校验（如 Jackson 的
JsonParser.Feature.STRICT_DUPLICATE_DETECTION） - 对上传接口强制设置
spring.servlet.multipart.max-file-size=5MB和max-request-size=10MB，防大文件耗尽内存 - 对含正则的校验逻辑（如邮箱、密码规则）启用 TIMEOUT 机制，避免回溯炸弹导致单线程卡死数秒
监控与动态响应，让防护策略可验证、可演进
没有监控的限流等于盲操作。必须持续观测线程池真实水位：
- 暴露
/actuator/metrics/jvm.threads.live、/actuator/metrics/executor.completed等指标，接入 Grafana 看板 - 重点关注 active threads > 90% maxThreads、queue size 持续 > 80% 容量、rejected tasks 每分钟突增 这三类信号
- 结合 ELK 分析被拒请求的 User-Agent、IP 段、URL 路径，识别是否为扫描器或代理集群，动态加入黑名单
- 在灰度环境模拟恶意压测（如用 JMeter 发起 2000 QPS + 长连接 + 大参数），验证线程池参数与拒绝策略是否按预期生效
