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

      线程切换的开销的确是比较厉害的。这是从今天的实验中得出的结果。

      为了解决上次提出的疑问，今天在实验室做了一个试验，来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响，所以，具体的测试环境就不提了，只要每次实验在同等的条件下即可。

      首先，在MQ的Server端启动100个读线程，100个写线程，100个消息deliver线程，客户端同时启动100个发送者，100个接收者，对4个queue进行不断发送1K大小的消息，测试结果为大约每秒可以发送＆接收600个左右的消息。而此时客户端的cpu消耗大概在80％左右，服务器端的cpu消耗在100％，但是线程切换大概占了30％左右。也就是说，只有70％的cpu用于消息的处理。

     接着，在MQ的Server端启动10个读线程，10个写线程，10个消息deliver线程，客户端同时启动100个发送者，100个接收者，对4个queue进行不断发送1K大小的消息，测试结果为大约每秒可以发送＆接收800个左右的消息。此时客户端的cpu消耗一般在90％以上，服务器端的cpu消耗在100％，而线程切换大概占了10％左右。也就是说，有90％的cpu用于消息的处理。

     随后，又对server端采用4个读写线程、消息deliver线程，以及20个，50个等不同线程数进行了测试，测试结果都没有优于10个线程数的情况。

    所以，可以得出结论，对于单cpu的情况，线程的切换的确会带来相当大的开销。今天的测试结果同时也表明了JTangMQ在100个发送者，100个接收者的情况下已经比JBossMQ每秒多发送＆接收100个消息，而在400个发送者，400个接收者的情况下，发送速度比JBossMQ多出几十个，接收着少了几十个，总体性能已经相当。当然，在发送者＆接收者数目较少的时候，性能明显优于JBossMQ。所以，接下来的目标是在多发送者＆接收者的条件下，超过JBossMQ，做到性能的全部提升。