最近在看tomcat对于comet的实现，由一点很不解，就是comet要求将tomcat的连接器切换成nio形式，而按照我的理解，如果是使用长轮询方式实现serverpush，并不需要nio就能实现功能，comet可能出于这样一种顾虑，一般serverpush往往一个client要等待很长一段时间才得到反馈，这部分时间占用着系统连接将很大程度影响系统并发能力，所以用nio让一个连接服务多个客户端，让我疑惑的是虽然连接数少了，但是仍旧每个等待响应的客户占用一个阻塞的服务器线程，线程数会遏制并发。所以我很感兴趣的是，web应用中线程数和tcp连接数那个是并发数的瓶颈？
应该是web应用中线程数
关键是线程用赶快用完，适合轻量快速任务，很多应用需要立即返回响应，而在响应产生之前要处理很多任务，占据线程时间较长，导致该线程拥有的资源不能释放，服务器资源就这样被这些蚂蚁瓜分了。
线程池有最大个数，这个最大个数其实就是最多多少个线程能够把服务器资源全部被瓜分。
一般的javaEE中web项目都是同步调用，都是假定服务器端线程尽可能快的执行完，倘若换成异步模式，比如tomcat部署一个股票系统，50个人在线等着看股票的变化，那么服务器端50个线程始终不终结，很影响并发能力，既然主要瓶颈在线程数上，那么用不用nio又有何防？
NIO主要是Socket和线程之间通讯关系，原来，是用一个线程守卫Socket，不断的轮询，这很耗CPU，容易堵塞，而NIO则不需要线程轮询，来一个Socket连接事件，就立即自动触发启动一个处理线程。
两者差异就是：
1.派人去侦察，三班倒。
2.无需派人侦察，有情况自动触发报警，大家就可以立即Action。这就是reActor模式
NIO是在响应性和CPU资源之间的折中。这其实就好比，多线程中你是不断的轮询然后阻塞的方式呢，还是采用对象条件队列来操作(比如wait,notify等），当然我们一般会采用条件队列的方式，因为这样有利于响应性的同时也有利于CPU资源的利用。
1 如果没有消息来就会阻塞，不会一直轮询，难道这也会占大量CPU时间么？
2 在高并发系统里，既然上文说线程数是主要瓶颈，那么使用普通IO还没有拖垮CPU的时候线程数首先就拖垮了内存
高并发的网站都有硬件来做load balance的