BUG产生复现

在一台电脑上启动生产者、消费者、MQ。当启动32线程进行多发多收压力测试时， 此时CPU占用率会暴涨，达到99%-100%，启动一段时间，消费者线程会全部断开，并且无法重连（此时使用断线重连机制 failover ）但是生产者依旧继续发送，但是其速度会由于得不到消费者的回执而慢慢降低，以至于消息积压。直至宕机。

BUG原因分析

目前暂时想到的原因有两个

机器自身CPU的保护机制

由于CPU的使用率一直在98%以上，可能由于CPU的某种保护机制会使消费者线程挂起，然后超过了MQ自身重连的时间，导致重连失败。（由于笔者对CPU的机制不甚了解，此原因暂时没有依据验证）。

MQ自身的保护机制

因为MQ的内存限制，当积压消息空间大于内存空间时，会使MQ宕机，但是可以选择MQ的临时转储功能来保证此情况不会发生，此时BUG就产生了 当转储后消费者就不会再消费消息了，此时生产者依旧会产生消息从而产生积压。但是原理上来说MQ应该要去限制生产者，而不是限制消费者。所以认为这是一个BUG。

目前解决方法

在MQ的生产者端添加如下代码

connectionFactory.setProducerWindowSize(10240);

该代码的作用是判断回执的窗口大小，默认是102400 将其降低为10240可有效的解决该情况的发生，在网上查阅资料得知102400说的是发送Byte大小，但是进行验证后发现，更像是发送的条数的多少，与Byte的大小关系并不是很大。
此时由于窗体大小的原因会使生产者发送速率降低，测试后发现10240与102400相比差异较小，但是5120与10240相比时间差异比较大。推荐使用10240窗体大小，具体情况视机器性能而定。

问题

但是使用上述方法依旧会偶发的出现积压问题，但是好消息是，出现积压后转储到磁盘，消费者不会停掉，依然会接收消息，但是速度会因为磁盘读写速度而导致变慢，生产者则不受影响。此刻停掉生产者，让消费者消费完成接收，就会从转储磁盘返回到内存来。

如有错误，恳请各位大佬指正