Mina和Netty开始。因为这两个NIO框架的创作者是同一个人Trustin Lee （韩国人）。GitHub主页地址 ：https://github.com/trustin。尽管创作者现在已经不专注与开发了。但是框架的后续开发和继承，可以说都是符合最开始的设定的。两个框架的架构设计思路基本一致。
Netty从某种程度上讲是Mina的延伸和扩展。解决了一些Mina上的设计缺陷，也优化了一下Mina上面的设计理念。
xSocket：是一个轻量级的基于nio的服务器框架用于开发高性能、可扩展、多线程的服务器。该框架封装了线程处理、异步读/写等方面。（只是对Java的NIO做了最简单的封装，以便于开发使用。）
Grizzly ： 是一种应用程序框架，专门解决编写成千上万用户访问服务器时候产生的各种问题。使用JAVA NIO作为基础，并隐藏其编程的复杂性。容易使用的高性能的API。带来非阻塞socketd到协议处理层。利用高性能的缓冲和缓冲管理使用高性能的线程池。
The NIO Framework sits on top of the Java NIO library and hides most of the complexity of plain NIO. With the NIO Framework one can easily implement secure, high-performance Java network applications.
NIO Framework 是对 Java NIO 库的封装，将NIO的复杂度隐藏起来。有了它，人们可以方便地实现安全，高性能的Java网络应用程序。
传统RPC调用性能差的三宗罪
网络传输方式问题：传统的RPC框架或者基于RMI等方式的远程服务（过程）调用采用了同步阻塞IO，当客户端的并发压力或者网络时延增大之后，同步阻塞IO会由于频繁的wait导致IO线程经常性的阻塞，由于线程无法高效的工作，IO处理能力自然下降。
序列化方式问题：Java序列化存在如下几个典型问题：
1) Java序列化机制是Java内部的一种对象编解码技术，无法跨语言使用；例如对于异构系统之间的对接，Java序列化后的码流需要能够通过其它语言反序列化成原始对象（副本），目前很难支持；
2) 相比于其它开源的序列化框架，Java序列化后的码流太大，无论是网络传输还是持久化到磁盘，都会导致额外的资源占用；
3) 序列化性能差（CPU资源占用高）。
线程模型问题：由于采用同步阻塞IO，这会导致每个TCP连接都占用1个线程，由于线程资源是JVM虚拟机非常宝贵的资源，当IO读写阻塞导致线程无法及时释放时，会导致系统性能急剧下降，严重的甚至会导致虚拟机无法创建新的线程。
高性能的三个主题
1) 传输：用什么样的通道将数据发送给对方，BIO、NIO或者AIO，IO模型在很大程度上决定了框架的性能。
2) 协议：采用什么样的通信协议，HTTP或者内部私有协议。协议的选择不同，性能模型也不同。相比于公有协议，内部私有协议的性能通常可以被设计的更优。
3) 线程：数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的消息如何派发，Reactor线程模型的不同，对性能的影响也非常大。