Java中线程池与消息队列是互补关系：消息队列缓冲流量、解耦系统，线程池高效可控处理消息；需设限队列容量、匹配业务特征配置线程池参数、按场景选择拒绝策略并保障幂等性与可观测闭环。
Java 中线程池与消息队列不是二选一的方案，而是互补协作的关系：消息队列负责“缓冲流量、解耦系统”，线程池负责“消费端高效、可控地处理消息”。两者结合才能真正实现稳定可靠的削峰填谷和异步处理。
消息队列做入口缓冲，承接洪峰流量
用户请求（如秒杀下单）不直接打到数据库或下游服务，而是先发往 RabbitMQ/Kafka/RocketMQ 等消息队列。队列容量需显式设限（例如 LinkedBlockingQueue 容量 2000），避免无界堆积导致 OOM。当队列水位超过 80%，可联动触发限流或告警；低于 20% 则说明消费能力富余，可考虑缩容消费者实例。
关键点：
- 生产者发送消息时启用 confirm 模式，确保消息可靠抵达 Broker
- 消息体应轻量，避免序列化开销过大；敏感字段如用户 ID 可加密或脱敏
- 设置合理的 TTL（过期时间），防止死信积压，必要时配置死信交换机做补偿
消费者端用定制化线程池驱动消息处理
消息消费者不是单线程拉取+串行处理，而应基于 Spring Boot 的 @RabbitListener 或 KafkaListener 配合自定义线程池，实现并发消费。重点在于线程池参数必须匹配业务特征：
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型任务（如加签验签、图像缩略图生成）：corePoolSize = CPU 核数 + 1，maximumPoolSize 接近 core，避免频繁线程切换
- IO 密集型任务（如调用 HTTP 接口查库存、写 DB）：corePoolSize 可设为 2～4 倍 CPU 核数，maximumPoolSize 控制在 32～64 区间，配合 keepAliveTime=60s 动态回收空闲线程
- 阻塞队列必须有界（推荐 ArrayBlockingQueue 或有界 LinkedBlockingQueue），禁用无界队列
拒绝策略与失败闭环要贴合业务语义
当消费者线程池满、消息来不及处理时，不能简单抛异常或丢弃。需按场景选择策略：
- 订单创建类强一致链路：用 AbortPolicy，让上游捕获 RejectedExecutionException 后走降级逻辑（如返回“系统繁忙，请稍后再试”）
- 日志上报、埋点采集类弱一致链路：用 DiscardPolicy，静默丢弃不影响主流程
- 通知类时效敏感任务：用 DiscardOldestPolicy，优先保障最新消息被处理
- 后台批处理任务：用 CallerRunsPolicy，由提交线程自己执行，天然限流且不丢失
同时配套重试机制（如 RabbitMQ 的 manual ack + 死信 + 延迟重试队列）和监控（消费延迟、积压量、失败率），形成可观测的闭环。
避免常见反模式
很多团队踩过坑，以下做法要规避：
- 把 newCachedThreadPool 当万能解——它会无限创建线程，极易引发 OOM 和上下文切换风暴
- 消费者里直接 new Thread() 处理每条消息——无法复用、无管控、易失控
- 消息体中塞大对象（如完整订单 POJO + 图片 Base64）——拖慢序列化、占满网络带宽和内存
- 忽略消息幂等性——重复消费导致库存扣两次、短信发两遍，必须在消费逻辑开头加唯一键判重（如 orderId + eventTime）
