Java多线程：Linux多路复用，Java NIO与Netty简述

JVM的多路复用器实现原理

• Linux 2.5之前：select/poll
• Linux 2.6之后: epoll
• Windows: Winsock的select模型（感谢评论指正，仅Java NIO.2使用了Windows IOCP，因为Netty没有采用NIO.2此处不展开）
• Free BSD, OS X: kqueue

下面仅讲解Linux的多路复用。

Linux中的IO

Linux的IO将全部外部设备都看做文件来操做，与外部设备的操做均可以看作文件操做，其读写都使用内核提供的系统调用，内核会返回一个文件描述符（fd, file descriptor），例如socket读写使用socketfd。描述符是一个索引，指向内核中一个结构体，应用程序对文件的读写经过描述符完成。

一个基本的IO，涉及两个系统对象：调用这个IO进程的对象，系统内核，read操做发生时流程以下：

1. 经过read系统调用向内核发起读请求。
2. 内核向硬件发送读指令，并等待读就绪。
3. 内核把将要读取的数据复制到描述符所指向的内核缓存区中。
4. 将数据从内核缓存区拷贝到用户进程空间中。

Linux I/O模型简介

1. 阻塞I/O模型：最经常使用，全部文件操做都是阻塞的。
2. 非阻塞I/O模型：缓冲区无数据则返回，通常采用轮询的方式作状态检查。
3. I/O复用模型：详细见下
4. 信号驱动I/O：使用信号回调应用，内核通知用户什么时候开启一个I/O操做。
5. 异步I/O：内核操做完成后进行通知，内核通知用户什么时候完成一个I/O操做。

Linux IO 多路复用

使用场景

• 客户处理多个描述符（交互输入，网络套接口）
• 客户处理多个套接口（少见）
• TCP服务器既要处理监听套接口，又要处理已链接套接口。
• 一个服务器既要处理TCP，又要处理UDP
• 一个服务器处理多个服务/多个协议

与多进程/多线程对比

I/O多路复用系统开销小，系统没必要建立进程/线程，也不须要维护这些进程/线程。

系统调用

目前支持I/O多路复用的系统调用包括select,pselect,poll,epoll，I/O多路复用即经过一种机制，一个进程能够监视多个描述符，一旦某个描述符准备就绪，就可以通知程序进行相应的读写操做。

select/poll

select目前在全部平台支持，select函数监视文件操做符（将fd加入fdset），循环遍历fdset内的fd获取是否有资源的信息，若遍历完全部fdset内的fd后无资源可用，则select让该进程睡眠，直到有资源可用或超时则唤醒select进程，以后select继续循环遍历，找到就绪的fd后返回。select单个进程打开的fd有必定限制，由FD_SETSIZE设置，默认为1024（32位）和2048（64位）。

poll与select的主要区别是不使用fdset，而是使用pollfd结构（本质链表结构），于是没有fd数目限制。

poll和select共有的问题：

• 每次select/poll找到就绪的fd，都须要把fdset/pollfd进行内存复制。
• select/poll，都要在内核中遍历全部传递来的fd来寻找就绪的fd，随着监视的fd数量增长，效率也会降低。

epoll

Linux 2.6内核中提出了epoll，epoll包括epoll_create,epoll_etl,epoll_wait三个函数分别负责建立epoll，注册监听的事件和等待事件产生。

• epoll每次注册新的事件到epoll中时，都会把全部fd拷贝进内核，而不是在epoll_wait时重复拷贝，保证每一个fd在整个过程当中仅拷贝一次。此外，epoll将内核与用户进程空间mmap到同一块内存，将fd消息存于该内存避免了没必要要的拷贝。
• epoll使用事件的就绪通知方式，经过epoll_ctl注册fd，一旦该fd就绪，内核就经过回调函数把就绪的fd加入一个就绪链表，唤醒epoll_wait进入睡眠的进程，epoll_wait通知消息给应用程序后再次睡眠。所以epoll不随着fd数目增长效率降低，只有活跃fd才会调用回调函数，效率与链接总数无关。
• epoll没有最大并发链接的限制，1G内存约能监听10万个端口。

epoll有LT模式和ET模式：

• LT模式：epoll_wait检测到fd并通知后，应用程序能够不马上处理，下次调用epoll_wait，会再次通知；
• ET模式：应用程序必须马上处理，下次调用，不会再通知此事件。ET模式效率更高，epoll工做在ET模式下必须使用非阻塞套接字。

性能对比

• 若是有大量的idle-connection或dead-connection，epoll效率比select/poll高不少。
• 链接少链接十分活跃的状况下，select/poll的性能可能比epoll好。

Java的IO模式

1. BIO：即传统Socket编程，线程数：客户端访问数为1：1，因为线程数膨胀后系统性能会急剧降低，致使了BIO的低效。
2. 伪异步I/O：为了解决一个链路一个线程的问题，引入线程池处理多个客户端接入请求，能够灵活调配线程资源，能够限制线程数量防止膨胀，但底层还是阻塞模型，高客户端访问时，会有通讯阻塞的问题。
3. NIO：Java NIO的核心为Channels, Buffers, Selectors。Channel有点像流，数据能够从Channel读到Buffer中，也能够从Buffer写到Channel内。而Selector则被用于多路复用，Java NIO能够把Channel注册到Selector上，以后，Selector会获取进入就绪状态的Channel（Selector进行循环的select/poll/epoll/IOCP操做），并进行后续操做。Selector是NIO实现的关键。Java NIO编程较为复杂。
4. AIO：NIO.2引入的异步通道概念，不须要多路复用器对注册的通道轮询便可异步读写，简化了NIO的编程。（可是Netty做者称AIO的性能并不比NIO和epoll好）

Netty

使用Netty而非直接使用Java NIO出于如下缘由：

1. Java NIO的API过于繁杂。
2. Java NIO开发须要了解Reactor模型，Java多线程等。
3. Java NIO低可靠性。
4. Java NIO有不少臭名昭著的BUG，如NIO的epoll空轮询bug

下面简单介绍下Netty的部分功能。

ByteBuf

Netty的ByteBuf依然是Byte数组缓冲区，提供对基础类型，byte[]数组，ByteBuffer，ByteBuf的读写，缓冲区自身的copy和slice，操做指针，字节序，构造实例等功能。相对于ByteBuffer，ByteBuf的读写采用两个指针而非flip方案，增长了可靠性，并提供了自动扩展方案。

ByteBuf的内存池实现比较复杂，可是否使用内存池，有较大的性能差别。随着JVM和JIT的发展，对象的分配和回收是个轻量级的工做，可是对于缓冲区Buffer，特别是堆外直接内存的分配和回收则仍很耗时。Netty提供了基于内存池的缓冲区重用机制，带来了性能提升。UnpooledByteBufAllocator在Netty4仍然是默认的allocator，但在大多状况下，PooledByteBufAllocator将带来更高性能。更改默认方式仅需在初始化时加以设置：

客户端

b.group(group)
.channel(NioSocketChannel.class)
 .option(ChannelOption.TCP_NODELAY, true)
 .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)

服务端

.childHandler(new ChannelInitializer<SocketChannel>() {
  @Override
  public void initChannel(SocketChannel ch) throws Exception {
  ch.config().setAllocator(PooledByteBufAllocator.DEFAULT);

Channel和Unsafe

Netty的Channel和NIO的Channel相似，但有本身的子类和实现。Unsafe则封装了Netty不但愿用户调用的API，做为Channel的辅助类。

Channel包括而不限于网络的读，写，客户端发起链接，主动关闭链接，链路关闭，获取双方通讯地址等功能。Channel也包括了Netty框架的相关功能，如获取该Channel的EventLoop，获取缓冲区分配器ByteBufAllocator和Pipeline等。Channel封装了Java NIO不统一的SocketChannel和ServerSockerChannel，其接口定义大而全。

Unsafe是Channel的辅助接口，实际的I/O读写操做都是由Unsafe完成的。包括register,bind,disconnect,close,write,flush几个接口，能够看到它更接近于本来的Java NIO Channel。

ChannelPipeline和ChannelHandler

Netty的pipeline和handler机制相似于Servlet和Filter，为了方便拦截和业务逻辑定制。Netty将Channel的管道抽象为ChannelPipeline，让消息在其中流动，ChannelPipeline持有消息拦截器ChannelHandler列表，能够经过增长和删除handler来改变业务逻辑，而不是对已有的handler进行修改。

ChannelHandler的种类繁多，且用户能够自定义，自定义时，一般只须要继承ChannelHandlerAdapter并重写为了实现业务逻辑的必要方法便可。

此外，ChannelPipeline支持运行时动态添加或删除ChannelHandler，某些场景下这个特性很实用。

ChannelPipeline是线程安全的，但ChannelHandler不是线程安全的，须要用户本身进行保障。

EventLoop和EventLoopGroup

Netty的线程模型得以无锁化依赖于其NioEventLoop。所以，此处详细展开。

Netty的线程模型

• Reactor模型：全部I/O都在NIO线程完成，NIO线程做为服务端，接收全部客户端TCP链接，并处理链路。
• Reactor多线程模型：由专门的一个Acceptor线程监听服务端，接收客户端的TCP请求，并调度一个subReactor线程池，该线程池维护多个处理线程，一个NIO线程能够处理N条链路。
• 主从Reactor多线程模型：在上述Reactor多线程模型基础上，服务端接收客户端TCP请求的再也不是一个NIO线程，而是一个独立的NIO线程池，Acceptor线程池仅用于客户端的登陆和认证，链路创建成功就交给subReactor线程池作后续操做。

Netty线程池：服务端启动时，建立bossGroup, workerGroup两个NioEventLoopGroup，其实是两个Reactor线程池，一个用于接收客户端TCP请求，一个用于处理I/O读写或执行业务。

• 接收线程池（bossGroup）职责：接收客户端TCP链接，初始化Channel参数，将链路状态变动通知给ChannelPipeline。
• I/O处理线程池（workerGroup）职责：异步读取通讯对端数据，发送读事件给ChannelPipeline；异步发送消息到通讯对端，调用ChannelPipeline的消息发送接口；执行业务或系统调用/定时任务等工做。

经过调整bossGroup和workerGroup的线程个数，group()函数参数数量，是否共享线程池等，Netty的Reactor模型能够在单线程，多线程，主从多线程等模式中切换。

NioEventLoop

Netty的NioEventLoop读取到消息以后，直接调用ChannelPipeline的fireChannelRead方法，只要用户不切换线程，一直都由NioEventLoop调用用户的Handler，期间不切换线程，而是串行化运行handler，避免了多线程操做的锁的竞争，达到性能最优。

NioEventLoop不纯粹是一个IO线程，它既能够处理系统Task又能够处理定时任务。

Future和Promise

Future起源于JDK的Future，Netty的Future命名为ChannelFuture，与Channel操做有关。Netty中全部操做都是异步的，所以，获取异步操做结果，就要交给ChannelFuture。ChannelFuture有completed何uncompleted两种状态，建立后处于uncompleted状态，一旦I/O操做完成，则被设置成completed状态，此时可能操做失败，操做成功或操做被取消。和JDK的Future相似，ChannelFuture有不少方便的API，包括获取操做结果，添加事件监听器，取消I/O操做，同步等待等。

Promise是可写的Future，用于设置I/O额结果。Netty发起I/O操做时，会建立一个新的Promise对象。

参考文献

聊聊IO多路复用之select、poll、epoll详解
关于同步，异步，阻塞，非阻塞，IOCP/epoll,select/poll,AIO ,NIO ,BIO的总结
【Java】从BIO、NIO到Linux下的IO多路复用
OSX/iOS中多路I/O复用总结
java nio及操做系统底层原理
Select函数实现原理分析
Netty4底层用对象池和不用对象池实践优化
设置Netty接收Buff为堆内存模式
关于java nio在windows下实现

相关阅读：NIO.2

NIO.2 uses IOCP
在 Java 7 中体会 NIO.2 异步执行的快乐
Java IO & NIO & NIO2
5种调优Java NIO和NIO.2的方式