<h1>firebody</h1>

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://firebody.blogbus.com/logs/398099.html

1）NIO确实能够使得大并发量长连接服务器的性能能够大幅度提升。主要原因如下：原来经典的开发模式是多线程，堵塞式。多线程必定带来系统性能的损耗，特别实在大并发量的时候，这种情况服务器肯定会down掉。而NIO采用事件监听模式，可以避免采用一个连接一个线程处理，或者说一个请求需要一个线程处理的弊病。NIO首先从Socket IO上实现非堵塞，使得服务器应用核心整体上能够实现非堵塞，少线程式的开发模式。我们开发nIO应用时，可以在堵塞点上使用一个线程守护，负责所有通过这个堵塞点的调用代理。使得核心应用执行不会堵塞，也就去除了使用线程的可能。

但是NIO的采纳，却给多阶段的服务器带来一些很难处理的复杂性，这里的多阶段还要比一般概念的多阶段来得更复杂一些，这里的多阶段是有步骤顺序的，多阶段构成一个请求交易的完整逻辑。如果在这种情况下，采用NIO，那么NIO的特点使得它会在多阶段的堵塞点上进行分割，分割逻辑如下如所示：

请求到来--->阶段1的业务处理（快速）--->阶段1的耗时操作--->阶段2的业务处理（快速）-->阶段2的耗时操作--->阶段3的业务处理（快速）-->结束交易

经典模式是将上面整个流程用一个线程处理

NIO引入后，可以这样考虑：

(NIO守护)请求到来->阶段1的业务处理(快速）-->(NIO守护,负责阶段1的耗时操作)-->阶段2的业务处理（快速）-->（NIO守护，否则阶段2的耗时处理)-->阶段3的业务处理（快速）-->交易结束

这里，NIO守护割断了紧密连在一起的多阶段，显然每一阶段需要作为NIO守护的监听者，每一阶段负责处理各自阶段独立的业务逻辑，然后将耗时的操作委托给NIO守护处理，NIO守护接收这个委托，在它完成这个委托之后，将多阶段的流程以事件的方式通知下一阶段继续执行。（很想一个工作流哦！）

虽然，这样的设计似乎可以解决多阶段的问题，然而，事情并没有那么简单，事实上，多阶段的业务流程是经常变化的，有可能增加，也可能减少。那么上面的设计显然是不可行的。

再考虑，将NIO守护与多阶段解除耦合，它只管它所负责的职责（比如连接远程服务器，发送接收报文等等），这样的设计显然要比前面的设计好得多。然而，因为独立导致我们监听器接收到的信息要足够并且增加很多判断逻辑才能进行阶段间的连续性，导致阶段监听器代码的大幅上升。（不过性能也跟着大幅上升哦！别忘了），具体项目实施中，这种思路值得采用。

2）socket连接在可能的情况下必须close，只要可以，就务必关掉不再使用的socket。因为socket是基于稳定的TCP/IP，我们在异步中，write或者read完报文之后，可以立即关闭它，在使用socket之前务必紧紧记住一点：socket是耗资源的

3）不得不使用多线程或者线程池的话，必须注意多线程的并发调用，当很多个线程可能在等候某一事件发生的时候，记得采用sleep或者suspend，使得别的线程能够争取到CPU继续执行（汗，可以看出多线程性能多低劣！）

4）同一个JVM用两个以上线程池的话，你的程序要小心了。

5）thread.close()不会立即关闭，需要等一段事件。

6）只要可能，务必使得线程执行时间最短。