双缓冲队列尝试

提出背景：
在C/S模式的系统里面，服务器端的主线程，除了要接收消息之外，还要处理消息。这使得主线程的工作量不但很大，而且工作很繁杂。这种情况在软件设计的角度来看，是很不好的：第一，这样让主线程类看起来异常的臃肿和难易阅读，第二，软件设计追求的目标是“尽量让每个类处理的工作都很单一，这样便于以后的调试和进一步对程序的扩展和移植”，这样的设计背离了软件设计中“模块化设计”的原则。
为此，很多程序员会设计一个全局的LinkedBlockingQueue对象来存放服务器主线程所收到的消息，即主线程收到消息之后，不做任何业务逻辑处理，直接put到阻塞队列中去，然后再启动一个处理消息的线程来从阻塞队列中take消息，这样就让服务器端程序大大解耦了，也便于阅读了，当然，最重要的是，效率也提高了不少。
但是在负荷量很大的系统里面，这样做仍然不是最好的办法。上面的解决办法中，仍然存在两个线程竞争一个资源的情况，即仍然存在同步的问题，只是LinkedBlockingQueue在底层进行了处理，在负荷量很大，并且要频繁访问同一个LinkedBlockingQueue对象的情况下，会使得效率较原始情况没有多大的提高。分析一下：主线程每次拿到消息M，都要put到LinkedBlockingQueue对象中，这样在LinkedBlockingQueue底层就要处理一次线程同步问题，当工作量很大很频繁的时候，这样的操作未免就显得有些累赘了，浪费了很多的时间和资源。同样在处理线程，每次take一个消息M，就会处理一次线程同步，同样降低了效率。注意，只是在负荷量很大的情况下(如中国移动CMPP短信网关)，这样的弱点才会很明显地暴露出来。

问题分析：
暴露出了问题，就需要我们想办法去解决，通过上面的分析，发现瓶颈在于，我们是对同一个LinkedBlockingQueue进行的操作，才会引起这么多的滞后。那么能不能试着去用两个LinkedBlockingQueue对象进行操作呢？一个专门给主线程put，另外一个专门给处理线程take和处理，当他们处理完了，再来交换？这样的话，就保障了基本上在每个时刻，每个线程都是在处理自己独自占有的资源，没有引发同步问题。这称之为：双缓冲队列。
当然，上面的解决方案是在一种很理想的情况下，即两个队列，在同一时刻被放满和取空，这样他们在程序运行过程中所达到的效率是最高的，因为没有任何消息被延后处理。所有消息都按照原定计划被处理了。现实情况往往没有这般顺利，但是上面的方案也不失为我们提供了一种解决思路，这其中还涉及到很多的处理机制。为了分析方便，我们暂且将两个LinkedBlockingQueue对象分别称之为LP(主线程控制的专门put的队列)，LT(处理线程控制的，专门take的队列)。
第一，    LP和LT队列什么时候才进行交换？肯定是在LT将所有的消息处理完了之后才进行交换，如果LT里面的消息都没有处理完就被交换了，那有可能LT里面的消息有些几年甚至永远不会被处理，这样的系统是无法投入使用的。
第二，    如果在LT处理完了，LP中还没有收到任何消息会怎么办？这是一种很极端的情况，但是也必须考虑到，延伸一下，如果LT里面的消息处理完了，而LP里面却只有一两条消息，该怎么办？要继续交换，还是等待一段时间以后再进行交换？在这里，笔者采用的是前者。目的是为了让消息都能及时地被处理。