有个线程池奇怪的问题，不知道有人遇到过没

不会是因为慢消息线程池开得多，所 cpu 核心都占用完了吧。

看下有没有死锁？

@visper 慢的 max 是 4 ，快的 max 是 32

没明白,
是 2 个线程池拉取 2 个队列的消息?
还是 2 个线程池拉取 1 个队列的消息?
如果是 2 个队列的消息那就说明快队列没有消息了.
如果是 1 个队列的消息, 那如何判断是快消息还是慢消息?且
快线程拉取到慢消息了或慢线程拉取快消息了怎么处理?

@vvtf 2 个线程池拉取 2 个队列的消息，实际情况是快消息队列出现了消息堆积

插眼关注，感觉不是线程问题（或者看下 2 楼说的？有资源竞争问题吗）。在排查下队列问题吧，有些队列有调度机制，会不会认为你的处理速度上有问题，然后给的调度少了，楼主用的什么队列，可以的话剥离业务逻辑，show your code

不是 jvm 会倾向于运行上下文切换次数少的线程，是 CPU 分配时间资源肯定是顺序分配，给 A 了，A 执行完了再给 B ，B 执行完了再给 A ，你的 sleep 1s 也是 CPU 时间开销。

你线程池 max32 ，你逻辑 cpu 数量有 32 个嘛？

架构设计也有问题，快慢是消息优先级不同，通道一致。

就应该分成两个服务，放到不同的物理机器上。快/慢线程池都是你自己人为指定的，操作系统并不知道，没法确定两个线程池的优先级。现在可能就是因为当前 CPU 的所有核心都去处理慢消息了，导致快线程池无法抢占，造成积压。
我觉得哪怕给两个线程池手动设置优先级都不太合理，就得分开到不同物理服务器中。

为啥：“如果拉不到就惩罚性 sleep 1s” ？

如果实际情况是出现消息堆积，那可能是消费者消费过慢，被踢出消费组了，之后就不消费了。。
所以为啥惩罚性呢？

`消息队列用了 redis 的 list left push right pop`
redis 的连接数是多少, 是不是被慢消息占满了?

如果慢消息线程运行时间长、上下文切换少，Linux 调度器会认为这些线程是“高效率线程”，从而倾向于继续调度它们。
快消息线程频繁上下文切换、睡眠（ sleep(1s)）反而会被认为“不活跃”，调度优先级降低。
这在 CFS （ Completely Fair Scheduler ）调度策略下尤其明显，低 CPU 占用线程不一定被“公平”处理。
JVM 本身不会偏向“上下文切换少”的线程，但底层的操作系统调度器（如 Linux CFS ）会对“常活跃线程”倾斜调度资源，从而导致你看到的“慢消息线程占用 CPU 、快消息线程饿死”现象。拆服务实现了资源隔离，自然就恢复了。

你应该把 jvm 的快消息线程池和线程状态打 log 下来看是处于什么状态，是线程因为比如 log 或者 sysout 死锁了，还是线程不活跃了，还是其他的原因。不过大概率是写法有问题，你慢的 max 是 4 ，注定吃不完 cpu

你慢的时候拉下 Thread Dumps 贴出来看下
你看下 redis 链接是不是不够用?
命令换成 brpop 不要做 sleep?

看线程堆栈，跑火焰图，看看 cpu 到底在干嘛

阻塞式 pop ，不要睡了，怕连接数不足？