因为前段时间的项目需要写一些高性能服务器，结果写出来的结果是五花八门，我们要求使用NIO编写异步服务器，但是竟然有人把NIO硬生生地写成同步的，还写成了一个单道批处理，线程调度、通信、同步操作，尤如天马行空，看不出一点架构，典型的面条代码，极度晕倒，不得不下定决心，将IO部分与线程调度部分隔离出来。
为此，狠下心来，仔细研究了一下nio机制和dl的util.concurrent包。
一、NIO的出现
NIO是JDK1.4里面才出现的东东，他给大家带来的最大好处是异步socket。其它file,pipe暂时就不多谈了。
在JDK1.4出现之前，如果你需要编写一个Java服务器，为了实现异步操作，你必须为每个连接请求生成一个Java线程，当连接请求很多时，线程的调度，上下文切换，所付出的代价是非常昂贵，而且由于Java是跨平台的，各个平台对线程的支持并不相同，性能也不相同，因此传统的Java服务器编程架构是低效的且代价贵，dl大侠写了个util.concurrent包后，总算是减轻了线程调度给java程序员带来的痛苦，但是相比之与C、C＋＋写出来的服务器，java服务器在性能要求很高的情况下，基本上没有什么竞争力，甚至是入围的权利的都没有。
二、异步socket的实现
NIO出现后，好像让java的程序员有了杨眉吐气的机会，怎么个吐气法，当时大家是个什么感受，俺是不知道，因为当时俺不搞java，对java的认识有限。
NIO是一个基于事件的IO架构，最基本的思想就是：有事件我通知你，你再去做你的事情，没事件时你大可以节约大把时间去做其它任何事情。而且NIO的主线程only one，不像传统的模型，需要N个线程去，也减轻了JVM的工作量，使得JVM处理任务时显得更加高效。
刚开始接触NIO时，被N层的Channel架构、网上铺天盖地的好评给镇住了，想想也应当是个很成熟的产品了，网上资料这么多，抄一抄Jetty、Tomcat以及其它一些牛B的源代码，基本上就能搞定了，此时没有想到大家受同步的影响这么深，也没有想到连最基本的异步概念都没有搞清楚就去写代码，搞出一堆的问题来（这是后话，后面再说）。
现在研究了NIO以后，发现NIO实际上在Java中做的工作是很简单，就是将事件进行收集和分发，我们结合一个经典的调用例子来说明这个问题，我就不从NIO的基本使用说起了，大家可以查其它的资料，网上一大把。
当Channel注册至Selector以后，我们的最经典的调用方法，是这样子的。
1
while(somecondition)
2
{
3
int n = selector.select(TIMEOUT);
4 if(n == 0) continue;
5 for (Iterator iter = selector.selectedKeys().iterator(); iter.hasNext();)
6
{
7 if (key.isAcceptable())
8 doAcceptable(key);
9 if (key.isConnectable())
10 doConnectable(key);
11 if (key.isValid() && key.isReadable())
12 doReadable(key);
13 if (key.isValid() && key.isWritable())
14 doWritable(key);
15 iter.remove();
16
}
17
} 这只是个小例子啊，什么异常我就懒得抓了。
nio中取得事件通知，就是在selector的select事件中完成的，在selector事件时有一个线程，这个线程具体的处理简单点说就是：向操作系统询问，selector中注册的Channel&&SelectionKey的偶对各种事件是否有发生，如果有则添加到selector的selectedKeys属性Set中去，并返回本次有多少个感兴趣的事情发生。程序员发现这个值>0，表示有事件发生，马上迭代selectedKeys中的SelectionKey，根据Key中的表示的事件，来做相应的处理。
实际上，这段说明表明了异步socket的核心，即异步socket不过是将多个socket的调度（或者还有他们的线程调度）全部交给操作系统自己去完成，异步的核心Selector，不过是将这些调度收集、分发而已。因为操作系统的socket、线程调度再咋D也比你JVM中要强，效率也高。
而且就算jvm做的和操作系统一样好，性能一样高（当然这是不现实的），使用异步socket你至少也节约了一半的系统消耗，想想假定操作系统本身也是使用线程来维护N个socket连接，在传统的java编程中，你还必须为这些socket还多起一个java线程，那至少是2N个线程，现在只需要N+1。在高并发的情况下，你自己去想吧。
懂了这个道理，异步socket也就好写了，也不会搞得思路混乱了。
三、 异步Socket中应当注意的事情
3.1 读
异步socket最基本的理念就是事件通知，前面也说了，有事件通知你了，你才该做你应当做的事情。在异步socket中当注册了一个OP_READ事件后，你就等着Selector通知你吧，如果没有通知你，你在家睡大觉都行。
在这里，我们有人出现的错误就是受同步的影响，自己去主动读，而且还搞出了多线程，如果仔细考虑一下，就不会出现这个问题了。同步socket中，调用read方法读取IO中的数据时，通常情况下如果没有数据read方法会阻塞，且是同步的，所以当多个线程同时访问时，read方法是线程安全的。
而在异步下就不同，异步是不会阻塞的，有什么就返回什么，你主动去读，只要有数据，你就可以拿走，在多线程的情况下，也许你是想让第一个线程读取，but此时来数据时正好是线程2读到了，那线程2就高高兴兴的拿去，而线程1还在苦苦等待，这样导致数据混乱不说，如果后面再也不来数据了，线程1就是死循环啦。
2. 写
在异步socket中，写是唯一一个主动点的操作，但是也不能直接去写Channel，而是应当先把自身注册为OP_WRITABLE，这时Selector就会发现你的存在，并把给发一个write事件，你这时后就可以写了，不过这时候有个小小的技巧，就是你执行写操作之前，请取消掉你的写注册，否则你的cpu肯定是100%。
3. 等待
在传统的服务器编程中，由于对于每个请求都是产生的一个线程，因此你在你每个请求线程中wait也好,sleep也好，不会影响别人。但是异步不同，他的主线程只有一个，基本上每个处理都是线性的，也就是说处理完第一个，然后才能处理第二个，因此nio是一个极好的处理短连接的架构。
我们现在出现的问题是，有人受同步的影响，没有搞清异步是如何处理，竟然在方法处理中用上sleep，而且一等还是3秒，这意味着什么，3秒才能处理一个请求，My god，我要一个3秒才能处理一个请求的服务器干嘛啊，还是60年代啊：（
如果出现这样的需要等待的情况，应当另起一个线程（推荐使用线程池）去完成这个“长”时间的任务，或者将其它交给一个消息队列，通过发消息的方式将给别人去完成也行，客户端能等，你服务器怎么也能等呢？写出这样的代码，基本上一个服务器也就废了。
这blog我发在个人的心情随笔中，发点牢骚，实在是觉得对于有些人的思路觉得有些不可思议，不吐不快。