线程的上下文开销真得那么厉害吗（1）？

      终究还是郁闷着了，为了JTangMQ的性能。

      都是因为MQ，这个令人又爱又恨的家伙。想起当初刚刚开始设计JTangMQ的豪言壮志，为MQ设计、coding的三百多个日夜历历在目，如今却坐在椅子上一声叹息。为何JTangMQ的性能还是那么不尽如人意？为什么呢？ 最初的设计目标是“超过国产MQ，迈向SonicMQ”，而现在的产品同JBossMQ相比还有那么一点的差距。这个差距令人诧异的地方是发送者＆接受者分别在10个以下的时候，比JBossMQ要优越许多，而当发送者&接收者分别多于100个的时候，测试数据表明速度比JBossMQ还要少上几十个。记得当初设计的时候，就是因为JBossMQ为每个连接创建一个读线程＆一个写线程，随着连接数的上升，线程数便会成倍增长，线程的切换会导致过多的cpu开销的原因，才利用NIO来设计JTangMQ的通讯层，想籍此点来提高JTangMQ在多连接数的性能。而现在的测试结构与原来的设计恰恰相反，连接数少的时候性能反而好。难道是因为线程的切换开销反不及减少线程数导致的cpu开销？是不是服务器端的线程数不够多呢？线程数在什么数量上才会是最好的选择呢？

      也许试验才是最好的方式，明天再试试吧。不管行不行，都得继续走下去。