场景
一个线程从某个地方接收消息(数据)，可以是其他主机或者消息队列，然后转由另外的一个线程池来执行具体处理消息的逻辑，并且消息的处理速度小于接收消息的速度。这种情景很常见，试想一下，你会怎么设计和实现？
直观想法
很显然采用JUC的线程框架，可以迅速写出代码。
消息接收者：
消息处理：
效果：这种方案导致的现象是接收到的消息会迅速堆积，我们从消息队列（或者其他地方）取出了大量消息，但是处理线程的速度又跟不上，所以导致的问题是大量的Task会堆积在线程池底层维护的一个阻塞队列中，这会极大的耗费存储空间，影响系统的性能。
分析：当execute()一个任务的时候，如果有空闲的worker线程，那么投入运行，否则看设置的最大线程个数，没有达到线程个数限制就创建新线程，接新任务，否则就把任务缓冲到一个阻塞队列中，问题就是这个队列，默认的大小是没有限制的，所以就会大量的堆积任务，必然耗费heap空间。
计数限制
面对上述问题，想到了要限制消息接收的速度，自然就想到了各种线程同步的原语，不过在这里最简单的就是使用一个Volatile的计数器。
消息接收者：
消息处理：
效果：通过控制消息的个数来阻塞消息的接收过程，就不会导致任务的堆积，系统的内存消耗会比较平缓，限制消息的个数本质就和下面限制任务队列大小一样。
使用同步队列 SynchronousQueue
SynchronousQueue 虽名为队列，但是其实不会缓冲任务的对象，只是作为对象传递的控制点，如果有空闲线程或者没有达到最大线程限制，就会交付给worker线程去执行，否则就会拒绝，我们需要自己实现对应的拒绝策略RejectedExecutionHandler，默认的是抛出异常RejectedExecutionException。
消息接收者同上。
消息处理：
效果：能够控制消息的接收速度，但是我们需要在rejectedExecution中实现某种阻塞的操作，但是选择在发生拒绝的时候把任务重新放回队列，带来的问题就是这个Task会发生饥饿现象。
使用大小限制的阻塞队列
使用LinkedBlockingQueue作为线程框架底层的任务缓冲区，并且设置大小限制，思想上和上述方案一样，都是有一个阻塞的点，但是通过最后的jvm monitor看到这里的CPU消耗更少，内存使用有所降低，并且波动小（具体原因有待探索）。
消息接收者同上。
消息处理：
总结
多线程是比较容易出问题的地方，特别当对方法不熟悉的时候
感兴趣的可以自己来我的Java架构群，可以获取免费的学习资料，群号：855801563对Java技术，架构技术感兴趣的同学，欢迎加群，一起学习，相互讨论。