Undertow Netty JDK的技术区别

Undertow

Undertow是一个NIO思想为基础的IO框架，X是指这个框架可以有多种实现，我们可以从代码库 https://github.com/xnio 中发现一个项目xnio-native，里面有用C实现的nio层，就能体会到这个X的含义，可以直接基于操作系统C库。目前在Xnio中默认的实现是nio-impl，也就是JDK的NIO。

可以认为xnio是在JDK的NIO之上，进行了扩展，融入了一些JBoss开发人员对于并发访问异步通信的理解和思考，总结出一套API，并用基于JDK NIO进行实现。

要学习XNIO，必须得有JDK NIO的基础知识，本文假设读者已经学习过NIO，如果还没有可以阅读参考书籍[1]，[2]。另外对Netty有所了解的话，就会融会贯通，比较容易的理解XNIO的基本原理，因为两个项目有很多相似之处。

XNIO有两个重要的概念

1. Channel，是传输管道的抽象概念，在NIO的Channel上进行的扩展加强，使用ChannelListener API进行事件通知。在创建Channel时，就赋予IO线程，用于执行所有的ChannelListener回调方法。
2. 区分IO线程和工作线程，创建一个工作线程池可以用来执行阻塞任务。一般情况下，非阻塞的Handler由IO线程执行，而阻塞任务比如Servlet则被调度到工作线程池执行。这样就很好的区分了阻塞和非阻塞的两种情形。

我们知道NIO的基本要求是不阻塞当前线程的执行，对于非阻塞请求的结果，可以用两种方式获得：一种是对于请求很快返回一个引用（如JDK中Future，XNIO中称为IoFuture，其中很多方法是类似的），过一段时间再查询结果；还有一种是当结果就绪时，调用事先注册的回调方法来通知（如NIO2的CompletionHandler，XNIO的ChannelListener）。显而易见后者效率更高一些，避免了数据未就绪情景下的无用处理过程。但JDK7之前无法将函数作为方法参数，所以只能用Java的匿名内部类来模拟函数式方法，造成代码嵌套层次过多，难以理解和维护，所以Netty和XNIO这样的框架通过调度方法调用过程，简化了编程工作。

XNIO和Netty的最主要的一个区别

XNIO继承重用了JDK NIO的ByteBuffer类，而不像Netty另起炉灶，完全重建自己的ByteBuf体系。我们知道NIO的ByteBuffer使用时有个状态切换的过程，读和写要显式的通过调用slice, reset等方法切换，就和unix使用vi编辑器编辑和处理文本需要用'i'和Esc切换状态类似。Netty通过读写指针索引值移除了这个“不便操作”，但XNIO保留了和JDK NIO一致的做法。

无论NIO还是Netty，都有heap buffer和direct buffer的概念，前者可以认为是byte数组的封装，缓冲区存放在堆上，后者可以直接通过调用操作系统的系统调用在内存上分配缓冲，这样在一些IO操作时，比如从网卡上读出大量数据，再写到硬盘文件中，就不必拷贝数据