RedisMessageListenerContainer 默认不会阻塞主线程，但未配置 setTaskExecutor() 时，监听逻辑会在启动线程同步执行，导致消息串行处理、重连卡顿、监听失效；必须显式配置并初始化 ThreadPoolTaskExecutor 才能真正解耦。
RedisMessageListenerContainer 默认会阻塞主线程吗
不会。但如果你没配 setTaskExecutor()，它会在主线程（或 Spring 启动线程）里同步执行监听逻辑——这不是“容器阻塞”，而是你把耗时操作塞进了监听回调里，导致容器内部的订阅循环被拖慢，甚至卡住重连、心跳等后台任务。
常见错误现象：RedisMessageListenerContainer 启动日志有 “Starting…”，但后续无任何订阅日志；发布消息后监听器不触发；onMessage 方法里加了 Thread.sleep(5000) 就再也收不到新消息。
- 根本原因不是容器本身阻塞，而是它默认用
SimpleAsyncTaskExecutor（每次新建线程，不复用），且未显式指定线程池，导致监听回调和容器管理逻辑共用同一调度上下文 - Spring Boot 2.x 不再自动配置线程池，必须手动注入
ThreadPoolTaskExecutor - 别在
onMessage里做 DB 写入、HTTP 调用、文件 IO 等同步阻塞操作；这些该交给异步线程池或消息确认后延后处理
必须配置 setTaskExecutor() 才能真正解耦
setTaskExecutor() 不是可选项，是生产环境强制项。不设它，容器内部的 message dispatch 会退化成串行执行，一个慢监听器直接拖垮整个容器的消息吞吐能力。
正确配置示例：
@Bean
public RedisMessageListenerContainer redisMessageListenerContainer(RedisConnectionFactory connectionFactory) {
RedisMessageListenerContainer container = new RedisMessageListenerContainer();
container.setConnectionFactory(connectionFactory);
container.setTaskExecutor(taskExecutor()); // ← 关键
container.setAutoStartup(true);
container.addMessageListener(messageListener(), new ChannelTopic("order"));
return container;
}
@Bean
public ThreadPoolTaskExecutor taskExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(3);
executor.setMaxPoolSize(10);
executor.setQueueCapacity(50);
executor.setThreadNamePrefix("redis-listener-");
executor.initialize(); // ← 必须调用，否则不生效
return executor;
}
-
corePoolSize设为 2–5 即可，多数场景 3 足够；设太高会抢占主线程资源 -
queueCapacity别设过大（如 1000+），否则消息积压掩盖下游瓶颈，问题难定位 -
setThreadNamePrefix()强烈建议加上，jstack 或 GC 日志里能一眼识别出是哪个容器的线程 - 漏掉
executor.initialize()是高频坑：Spring 不报错，但线程池根本不启动，容器仍走默认 fallback
监听器内部阻塞比容器阻塞更危险
很多人以为只要配了线程池就万事大吉，结果在 onMessage() 里调用 restTemplate.postForObject() 或 jdbcTemplate.update()，照样卡死。因为这些操作本身是同步阻塞的，只是换了个线程执行而已。
- 真正要避免的是“监听线程内完成业务闭环”；推荐模式：监听线程只做轻量反序列化 + 提交到业务线程池，然后立即返回
- 如果必须同步调用外部服务，至少加超时：
restTemplate.execute(..., new ParameterizedTypeReference<?>(){}, 5000) - 别依赖
@Transactional在监听器方法上生效——事务传播行为不可控，且容易延长监听线程占用时间 - 每个
onMessage必须包try-catch：未捕获异常会导致RedisMessageListenerContainer中断当前订阅循环，后续消息全丢（不是抛异常，是静默跳过）
为什么 setSubscriptionTaskExecutor() 不能替代 setTaskExecutor()
setSubscriptionTaskExecutor() 只负责定期刷新订阅状态（防网络抖动断连），和消息消费完全无关。它不参与 onMessage() 的调度，也不影响监听器执行并发度。
- 这个 executor 只跑定时任务，比如每 30 秒发一次
SUBSCRIBE检查，开销极小 - 即使你配了它，没配
setTaskExecutor()，消息依然会串行执行、互相阻塞 - 两者用途完全不同，不能混用或相互替代；生产环境两个都得配，但优先级上
setTaskExecutor()更关键
executor.initialize() 的缺失。这两点不解决，线程池配得再好也白搭。 
