Tomcat NIO 模型的实现

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Tomcat 对 BIO 和 NIO 两种模型都进行了实现，其中 BIO 的实现理解起来比较简单，而 NIO 的实现就比较复杂了，并且它跟常用的 Reactor 模型也略有不同，具体设计如下：

可以看出多了一个 BlockPoller 的设计，这是因为在 Servlet 规范中 ServletInputStream 和 ServletOutputStream 是阻塞的，所以请求体和响应体的读取和发送需要阻塞处理。请求行读取和 SSL 握手使用非阻塞的 Poller 处理。一次连接基本的处理流程是：

Acceptor 接收 TCP 连接，并将其注册到 Poller 上
Poller 发现通道有就绪的 I/O 事件，将事件分配给线程池中的线程处理
线程池线程首先在 Poller 上非阻塞完成请求行和 SSL 握手的处理，然后通过容器调用 Servlet，生成响应，最后如果需要读取请求体或者发送响应，那就会将通道注册到 BlockPoller 上模拟阻塞完成

接下来分析核心代码的实现，源码来自 Tomcat 6.0.53 版本，之所以使用这个版本是因为看起来简单直观没有太多的抽象，也不影响来理解核心的处理逻辑。首先看下连接处理的方法调用情况，可右键直接打开图片查看大图：

1. Acceptor 注册通道到 Poller 上

Acceptor 和 Poller 分属两个不同的线程，通常情况下 Poller 阻塞在 select() 方法的调用上，此方法会锁住内部的 publicKeys 集合，所以 Acceptor 接收到通道连接不能直接注册到 Poller 上，否则会造成死锁。Tomcat 使用生产者-消费者模式来进行并发协作，缓冲区使用的是 ConcurrentLinkedQueue 无界队列。

Acceptor 接收到连接的 SocketChannel 后，将其配置成非阻塞模式，封装成 NioChannel，最后调用 getPoller0().register(NioChannel) 加入到某个 Poller 的事件队列中。

public void register(final NioChannel socket) { socket.setPoller(this); // 关联此 Poller KeyAttachment key = keyCache.poll(); final KeyAttachment ka = key!=null?key:new KeyAttachment(); // 重置或者初始化 KeyAttachment 对象 ka.reset(this,socket,getSocketProperties().getSoTimeout()); PollerEvent r = eventCache.poll(); // 声明此通道关注的事件 ka.interestOps(SelectionKey.OP_READ);//this is what OP_REGISTER turns into. // 将此通道和 SelectionKey 附件对象封装成 PollerEvent 对象 if ( r==null) r = new PollerEvent(socket,ka,OP_REGISTER); else r.reset(socket,ka,OP_REGISTER); // 加入到 Poller 的 events 队列中 addEvent(r); } public void addEvent(Runnable event) { events.offer(event); // 插入队列 if ( wakeupCounter.incrementAndGet() == 0 ) selector.wakeup(); // 唤醒 Selector }

Poler 有个 events() 方法，用于遍历事件队列进行处理，events() 会在 select 调用超时或者被唤醒且没有通道发生 I/O 事件时被调用，代码如下：

public boolean events() { boolean result = false; Runnable r = null; // 遍历事件队列 while ( (r = events.poll()) != null ) { result = true;// 有事件待处理 try { r.run(); // 本质调用的是 PollerEvent.run() if ( r instanceof PollerEvent ) { // 重置并缓存 PollerEvent 对象 ((PollerEvent)r).reset(); eventCache.offer((PollerEvent)r); } } catch ( Throwable x ) { log.error("",x); } } return result; }

可以看出这里有个关键对象 PollerEvent，它内部有个 interestOps 属性，表示要处理的事件类型，它有三个可能的值分别是：

NioEndpoint.OP_REGISTER: 通道注册事件
SelectionKey.OP_READ: 通道重新声明在 Poller 上关注读事件
SelectionKey.OP_WRITE: 通道重新声明在 Poller 上关注写事件

OP_REGISTER 的处理就是将通道注册到 Selector 上的最终实现，代码如下：

if ( interestOps == OP_REGISTER ) { try { // 将 SocketChannel 注册到 Poller 的 Selector 上并指定关注的事件和附加对象 socket.getIOChannel().register(socket.getPoller().getSelector(), SelectionKey.OP_READ, key); } catch (Exception x) { log.error("", x); } }

至此已完成了通道注册，接下来看一下 PollerEvent 为什么还要处理 OP_READ 和 OP_WRITE 事件。

2. PollerEvent 对 OP_READ 和 OP_WRITE 的处理

PollerEvent（又或者说 Poller）要处理读写事件，就是因为程序需要一次非阻塞的读或写操作。一开始通道是在 Poller 上声明关注的事件，但是在发生 I/O 事件后，Poller 就会把此通道就绪的事件从它关注的事件中移除（原因见下文），所以如果需要非阻塞的读或写，只能再次在这个 Poller 上重新声明。

解析请求行是非阻塞的，解析过程中，由于 TCP 存在粘包/拆包的问题，可能导致数据读取不完整，需要再次从通道读取，此时就要在关联的 Poller 上重新关注读事件，核心代码：

// 拿到通道在 Poller 上对应的 SelectionKey final SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector()); try { boolean cancel = false; if (key != null) { ... // 将 interestOps 合并到 key 现有关注的事件集合中 int ops = key.interestOps() | interestOps; // 更新 key 和附加对象关注的操作 att.interestOps(ops); key.interestOps(ops); att.setCometOps(ops); } else { cancel = true; } }catch (CancelledKeyException ckx) {}

3. Poller 对 I/O 事件的处理

Poller 就是 Reactor，主要功能是将就绪的 SelectionKey 分配给处理器处理，此外它还检查通道是否超时。它在调用 select 方法时会根据条件确定是阻塞还是非阻塞，代码如下：

if ( !close ) { if (wakeupCounter.getAndSet(-1) > 0) { // wakeupCounter 大于0，意味着 Acceptor 接收了大量连接，产生大量 PollerEvent 急 // 需 Poller 消费处理，此时进行一次非阻塞调用 keyCount = selector.selectNow();// 非阻塞直接返回 } else { // wakeupCounter 等于0，阻塞等待 IO 事件发生或被唤醒 keyCount = selector.select(selectorTimeout); } wakeupCounter.set(0); }

当有通道 I/O 事件就绪时，Poller 将会创建一个 SocketProcessor 提交线程池处理，具体代码不再贴出。在这个过程中有一个将当前就绪的事件从 SelectionKey 中移除的操作，这是为了后续能够在 BlockPoller 上阻塞读写时，防止多个线程的干扰，具体代码如下：

protected void unreg(SelectionKey sk, KeyAttachment attachment, int readyOps) { // 取反再与 - 表示从 sk.interestOps() 中清除 readyOps 所在的位 reg(sk,attachment,sk.interestOps()& (~readyOps)); } protected void reg(SelectionKey sk, KeyAttachment attachment, int intops) { sk.interestOps(intops); attachment.interestOps(intops); //attachment.setCometOps(intops); }

检查超时的方法是 Poller.timedout(keyCount, hasEvents)，它在 Poller 的每次循环上都被调用，但不是每次都处理超时，因为这会产生过多的负载，而超时可等待几秒钟再超时也没事。Poler 有一个名为 nextExpiration 的成员变量，它表示检查超时的最短时间间隔，在这个时间内，如果只是 select() 调用超时（表示负载不大）会执行处理超时。

4. SocketProcessor 的处理

SocketProcessor 处理 SSL 握手和调用 Handler 进行实际的 I/O 操作。Handler 的子类 Http11ConnectionHandler 会创建一个 Http11NioProcessor 对象最终处理 Socket，这里不分析具体的协议处理，来看看几种处理结果：

public SocketState process(NioChannel socket) { Http11NioProcessor processor = null; try { processor = connections.remove(socket); ... SocketState state = processor.process(socket); if (state == SocketState.LONG) { // 在处理request和生成response之间，保持socket和此processor的关联 connections.put(socket, processor); // 通常是收到了不完整的请求行，再次以 OP_READ 注册到 Poller 上 socket.getPoller().add(socket); } else if (state == SocketState.OPEN) { // 长连接，Http 保活，回收 processor release(socket, processor); // 此时已处理一个完整的请求并响应，再次注册到 Poller 上，等待处理下个请求 socket.getPoller().add(socket); } else if (state == SocketState.SENDFILE) { // 处理文件 connections.put(socket, processor); } else { // 连接关闭，回收 processor release(socket, processor); } return state; } catch (...) {...} release(socket, processor); return SocketState.CLOSED; }

5. 模拟阻塞的实现

模拟阻塞是通过 NioBlockingSelector 和 BlockPoller，以及 KeyAttachment 中的两个 CountDownLatch 读写闭锁合作完成。这里分析阻塞读，阻塞写的实现类似。一般的，在读取 POST 请求参数时会使用模拟阻塞完成，来看下 NioBlockingSelector.read() 方法的具体实现：

public int read(ByteBuffer buf, NioChannel socket, long readTimeout) throws IOException { // 拿到通道在 Poller 上注册的 key SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector()); if ( key == null ) throw new IOException("Key no longer registered"); KeyReference reference = new KeyReference(); // key 的附加对象 KeyAttachment att = (KeyAttachment) key.attachment(); int read = 0; // 读取的字节数 boolean timedout = false; // 是否超时 int keycount = 1; //assume we can write 假设通道可读 long time = System.currentTimeMillis(); //start the timeout timer try { while ( (!timedout) && read == 0) { if (keycount > 0) { //only read if we were registered for a read // 尝试读取一次，如果通道无数据可读则返回 0，若连接断开则返回 -1 int cnt = socket.read(buf); if (cnt == -1) throw new EOFException(); read += cnt; if (cnt > 0) break; } try { // 初始化读闭锁 if ( att.getReadLatch()==null || att.getReadLatch().getCount()==0) att.startReadLatch(1); // 将此通道注册到 BlockPoller，关注读取事件 poller.add(att,SelectionKey.OP_READ, reference); // 阻塞等待通道可读 att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS); }catch (InterruptedException ignore) { Thread.interrupted(); } if ( att.getReadLatch()!=null && att.getReadLatch().getCount()> 0) { // 被打断了，但是没有接收到 blockPoller 的提醒 keycount = 0; // 继续循环等待可读 }else { //通道可读，重置读闭锁 keycount = 1; att.resetReadLatch(); } if (readTimeout > 0 && (keycount == 0)) // 如果超时了，则不再读取，抛异常 timedout = (System.currentTimeMillis() - time) >= readTimeout; } //while if (timedout) throw new SocketTimeoutException(); } finally { poller.remove(att,SelectionKey.OP_READ); // 移除注册 if (timedout && reference.key!=null) { poller.cancelKey(reference.key); // 超时取消 } reference.key = null; } return read; }

BlockPoller 实现逻辑与 Poller 大致相同，不同的地方在于对就绪 key 的处理，核心代码如下：

Iterator<SelectionKey> iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null; while (run && iterator != null && iterator.hasNext()) { SelectionKey sk = iterator.next(); KeyAttachment attachment = (KeyAttachment)sk.attachment(); try { attachment.access(); iterator.remove(); // 移除已就绪的事件 sk.interestOps(sk.interestOps() & (~sk.readyOps())); // 可读或可写时减少对应闭锁的值，此时阻塞在 NioBlockingSelector.read() 上的线程继续执行读取 if ( sk.isReadable() ) { countDown(attachment.getReadLatch()); } if (sk.isWritable()) { countDown(attachment.getWriteLatch()); } }catch (CancelledKeyException ckx) { if (sk!=null) sk.cancel(); countDown(attachment.getReadLatch()); countDown(attachment.getWriteLatch()); } }//while

6. 小结

至此，本文对连接的接收、分发以及模拟阻塞的核心代码实现进行了分析，为了更好的理解内部流程，尽可能的使用简洁的代码仿写了这部分功能。

源码地址：https://github.com/tonwu/rxtomcat 位于 rxtomcat-net 模块

7. Tomcat 8.5 版本变化

7.1 替换缓存数据结构

Tomcat 对 PollerEvent、NioChannel 和 Processor 对象进行了缓存，目的是减少 GC 提高系统性能，这是一种用空间换时间，被称为对象池的优化手段。从版本 8.* 开始，缓存数据结构从 ConcurrentLinkedQueue 换成了自定义的同步栈 SynchronizedStack。SynchronizedStack 的 javadoc 明确说明：

当需要创建一个无需缩小的可重用对象池时，这是 ConcurrentLinkedQueue 无 GC 的主要替代方案。目的是尽可能快地以最少的垃圾提供最少的所需功能。

在这个特殊的情况下，ConcurrentLinkedQueue 有很多功能是不需要的，所以就实现了一个有重点的类，可以专注完成一件事，来提升性能。但它不是 ConcurrentLinkedQueue 的替代品。

7.2 LimitLatch

Acceptor 在接收连接前添加了一个 LimitLatch（类似信号量）来控制总连接数。分析下如果不加有什么现象，在极端情况下，线程池没有空闲线程并且它内部的队列已满，当有通道发生可读或可写事件时，Poller 会关闭此通道，此时系统负载已达到最高，如果 Acceptor 还在继续接收连接并请求注册，而不加限制，那么就会一直重复 PollerEvent 入队出队和 Poller 单纯关闭通道的操作，浪费系统资源。