Java中的NIO非阻塞模式和传统的IO的阻塞模式在线程中的资源消耗

       java中的NIO对于需要IO操作的程序来说，大大的提高了效率，但从NIO的实现模式来看（底层select的遍历），因为其非阻塞的特性，牺牲了更多的系统资源，充分利用了硬件资源。
      在java的网络编程中，少不了线程操作。那么这两种模式对系统的消耗情况是什么样子呢？下面来分享一个自己的一次优化经验
 
     我们的程序是SOCKET网络访问，每秒的交互数量不小于500，除了网络状况的要求外，程序的优化非常关键。
     我们的程序中有3条NIO的线程，有20多条传统模式的IO线程。我们再while循环里面都没有休眠时间来看系统消耗。
     在有3条NIO（也包括了非常多的其他业务的处理线程），while中没有休眠时间，CPU100%运行（CPU 2.26G  8线程），这个时候NIO是工作在非阻塞模式，也就是说如果没有休眠时间，该线程是不会释放CPU时间的。在while中加入了休眠1ms，CPU立马降到 70%，基本上一个NIO无休眠线程消耗10%的CPU，也就是对于 单核的CPU来说80%的消耗。
    还有20条的阻塞模式的线程（线程在应用级别异步接收提交的结果），while循环中没有休眠时间，因为其非阻塞模式，在IO被占用的时候，后来进来的IO操作等待，这个过程对CPU时间进行了释放，这样也就是说while循环中虽然没有休眠时间，但是实际上是休眠了阻塞的时间。当在同样的硬件环境和操作系统下，启动这20个线程的时候，CPU消耗18%左右
 
    由上面的实际的例子可以看出，在进行NIO的编程的时候，一定要注意考虑到他的非阻塞模式，给系统的资源消耗带来的影响。无论多快的应用需求，一定给NIO的线程休眠时间，如果不休眠是真正的“死循环”，会导致系统资源的大量消耗。
   从实际我们的平台运行的情况看，如果需要大量的基于SOCKET的网络交互，因为阻塞模式的局限，NIO是很有必要的。JAVA中的线程休眠时间只能是ms级别的，也就是说NIO的操作，如果想要低的系统资源消耗，那么就只能每秒1000次得处理。目前还没有找到好的方法让休眠时间更多，只要给线程休眠时间，CPU就不会100%运行！