最近再次翻netty和disruptor的源码, 发现一些地方使用AtomicXXX.lazySet()/unsafe.putOrderedXXX系列, 以前一直没有注意lazySet这个方法, 仔细研究一下发现很有意思
2 | 3 |我们拿AtomicReferenceFieldUpdater的set()和lazySet()作比较, 其他AtomicXXX类似
4 | 5 |public void set(T obj, V newValue) {
6 | // ...
7 | unsafe.putObjectVolatile(obj, offset, newValue);
8 | }
9 |
10 | public void lazySet(T obj, V newValue) {
11 | // ...
12 | unsafe.putOrderedObject(obj, offset, newValue);
13 | }
14 |
15 | 1.首先set()是对volatile变量的一个写操作, 我们知道volatile的write为了保证对其他线程的可见性会追加以下两个Fence(内存屏障)
16 | 1)StoreStore // 在intel cpu中, 不存在[写写]重排序, 这个可以直接省略了
17 | 2)StoreLoad // 这个是所有内存屏障里最耗性能的
18 | 注: 内存屏障相关参考Doug Lea大大的cookbook (http://g.oswego.edu/dl/jmm/cookbook.html)
19 |
20 | 2.Doug Lea大大又说了, lazySet()省去了StoreLoad屏障, 只留下StoreStore
21 | 在这里 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6275329
22 | 把最耗性能的StoreLoad拿掉, 性能必然会提高不少(虽然不能禁止写读的重排序了保证不了可见性, 但给其他应用场景提供了更好的选择, 比如上边连接中Doug Lea举例的场景)但是但是, 在好奇心驱使下我翻了下JDK的源码(unsafe.cpp):
25 | 26 |// 这是unsafe.putObjectVolatile()
27 | UNSAFE_ENTRY(void, Unsafe_SetObjectVolatile(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jobject x_h))
28 | UnsafeWrapper("Unsafe_SetObjectVolatile");
29 | oop x = JNIHandles::resolve(x_h);
30 | oop p = JNIHandles::resolve(obj);
31 | void* addr = index_oop_from_field_offset_long(p, offset);
32 | OrderAccess::release();
33 | if (UseCompressedOops) {
34 | oop_store((narrowOop*)addr, x);
35 | } else {
36 | oop_store((oop*)addr, x);
37 | }
38 | OrderAccess::fence();
39 | UNSAFE_END
40 |
41 | // 这是unsafe.putOrderedObject()
42 | UNSAFE_ENTRY(void, Unsafe_SetOrderedObject(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jobject x_h))
43 | UnsafeWrapper("Unsafe_SetOrderedObject");
44 | oop x = JNIHandles::resolve(x_h);
45 | oop p = JNIHandles::resolve(obj);
46 | void* addr = index_oop_from_field_offset_long(p, offset);
47 | OrderAccess::release();
48 | if (UseCompressedOops) {
49 | oop_store((narrowOop*)addr, x);
50 | } else {
51 | oop_store((oop*)addr, x);
52 | }
53 | OrderAccess::fence();
54 | UNSAFE_END仔细看代码是不是有种被骗的感觉, 他喵的一毛一样啊. 难道是JIT做了手脚?生成汇编看看
57 | 58 |生成assembly code需要hsdis插件
59 | 60 |mac平台从这里下载 61 | https://kenai.com/projects/base-hsdis/downloads/directory/gnu-versions
62 | 63 |linux和windows可以从R大的[高级语言虚拟机圈子]下载 http://hllvm.group.iteye.com/
64 | 65 |为了测试代码简单, 使用AtomicLong来测:
66 | 67 |// set()
68 | public class LazySetTest {
69 | private static final AtomicLong a = new AtomicLong();
70 |
71 | public static void main(String[] args) {
72 | for (int i = 0; i < 100000000; i++) {
73 | a.set(i);
74 | }
75 | }
76 | }
77 |
78 | // lazySet()
79 | public class LazySetTest {
80 | private static final AtomicLong a = new AtomicLong();
81 |
82 | public static void main(String[] args) {
83 | for (int i = 0; i < 100000000; i++) {
84 | a.lazySet(i);
85 | }
86 | }
87 | }分别执行以下命令:
90 | 91 |110 | 111 |1.export LD_LIBRARY_PATH=~/hsdis插件路径/ 92 | 2.javac LazySetTest.java && java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly LazySetTest93 | 94 |95 | // ------------------------------------------------------ 96 | // set()的assembly code片段: 97 | 0x000000010ccbfeb3: mov %r10,0x10(%r9) 98 | 0x000000010ccbfeb7: lock addl $0x0,(%rsp) ;*putfield value 99 | ; - java.util.concurrent.atomic.AtomicLong::set@2 (line 112) 100 | ; - LazySetTest::main@13 (line 13) 101 | 0x000000010ccbfebc: inc %ebp ;*iinc 102 | ; - LazySetTest::main@16 (line 12) 103 | // ------------------------------------------------------ 104 | // lazySet()的assembly code片段: 105 | 0x0000000108766faf: mov %r10,0x10(%rcx) ;*invokevirtual putOrderedLong 106 | ; - java.util.concurrent.atomic.AtomicLong::lazySet@8 (line 122) 107 | ; - LazySetTest::main@13 (line 13) 108 | 0x0000000108766fb3: inc %ebp ;*iinc 109 | ; - LazySetTest::main@16 (line 12)
好吧, set()生成的assembly code多了一个lock前缀的指令
112 | 113 |查询IA32手册可知道, lock addl $0x0,(%rsp)其实就是StoreLoad屏障了, 而lazySet()确实没生成StoreLoad屏障
114 | 115 |我想知道JIT除了将方法内联, 相同代码生成不同指令是怎么做到的
116 | 117 | ----------------------------------------------------------------------------------------------------------------- 118 | http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/6e9aa487055f/src/share/vm/classfile/vmSymbols.hpp 119 |  120 | 121 |  122 | 123 | putObjectVolatile与putOrderedObject都在vmSymbols.hpp的宏定义中,jvm会根据instrinsics id生成特定的指令集 124 | putObjectVolatile与putOrderedObject生成的汇编指令不同估计是源于这里了, 继续往下看 125 | hotspot/src/share/vm/opto/libaray_call.cpp这个类: 126 | 127 | 首先看如下两行代码: 128 |case vmIntrinsics::_putObjectVolatile: return inline_unsafe_access(!is_native_ptr, is_store, T_OBJECT, is_volatile);
129 | case vmIntrinsics::_putOrderedObject: return inline_unsafe_ordered_store(T_OBJECT);bool LibraryCallKit::inline_unsafe_ordered_store(BasicType type) {
134 | // This is another variant of inline_unsafe_access, differing in
135 | // that it always issues store-store ("release") barrier and ensures
136 | // store-atomicity (which only matters for "long").
137 |
138 | // ...
139 | if (type == T_OBJECT) // reference stores need a store barrier.
140 | store = store_oop_to_unknown(control(), base, adr, adr_type, val, type);
141 | else {
142 | store = store_to_memory(control(), adr, val, type, adr_type, require_atomic_access);
143 | }
144 | insert_mem_bar(Op_MemBarCPUOrder);
145 | return true;
146 | }
147 |
148 | ---------------------------------------------------------------------------------------------------------
149 |
150 | bool LibraryCallKit::inline_unsafe_access(bool is_native_ptr, bool is_store, BasicType type, bool is_volatile) {
151 | // ....
152 |
153 | if (is_volatile) {
154 | if (!is_store)
155 | insert_mem_bar(Op_MemBarAcquire);
156 | else
157 | insert_mem_bar(Op_MemBarVolatile);
158 | }
159 |
160 | if (need_mem_bar) insert_mem_bar(Op_MemBarCPUOrder);
161 |
162 | return true;
163 | }instruct membar_volatile(rFlagsReg cr) %{
169 | match(MemBarVolatile);
170 | effect(KILL cr);
171 | ins_cost(400);
172 |
173 | format %{
174 | $$template
175 | if (os::is_MP()) {
176 | $$emit$$"lock addl [rsp + #0], 0\t! membar_volatile"
177 | } else {
178 | $$emit$$"MEMBAR-volatile ! (empty encoding)"
179 | }
180 | %}
181 | ins_encode %{
182 | __ membar(Assembler::StoreLoad);
183 | %}
184 | ins_pipe(pipe_slow);
185 | %}前言
2 | 3 |本菜鸟有过几年的网络IO相关经验, java层面netty也一直关注, 最近想对自己所了解的netty做一个系列的笔记, 不光技术水平有限, 写作水平更有限, 难免有错误之处欢迎指正, 共同学习.
4 | 5 |上一篇讲了bind, 这篇分析一下accept的细节, 我觉得网络IO相关开发很多时候不能仅仅局限于java层, 尤其从accept开始一个连接诞生了, 什么拥塞控制啊, 滑动窗口啊等等一系列底层的问题可能就开始会渐渐困扰到你了, 这一章尝试先从linux内核的tcp实现开始分析accept
6 | 7 |源码来自linux-2.6.11.12, 还参考了[TCP_IP.Architecture,.Design.and.Implementation.in.Linux]一书
8 | 9 |linux的代码就不往这里贴了, 一个是太多, 篇幅控制不了(主要代码都在tcp_ipv4.c以及tcp_input.c中), 再一个是本屌丝只会java, os层我解释越多错误就会越多,最终会误导读者.
10 | 11 |accept概述
12 | 13 |accept属于tcp被动打开环节(被动打开请参考tcp状态变迁图), 被动打开的前提是你这一端listen, listen时创建了一个监听套接字, 专门负责监听, 不负责传输数据. 14 | 当一个SYN到达服务器时, linux内核并不会创建sock结构体, 只是创建一个轻量级的request_sock结构体,里面能唯一确定是哪一个客户端发来的SYN的信息. 15 | 接着服务端发送SYN + ACK给客户端, 总结下来是两个步骤: 16 | 1.建立request_sock 17 | 2.回复SYN + ACK 18 | 接着客户端需要回复ACK, 此时服务端从ACK这个包中取出相应信息去查找之前相同客户端发过来的SYN时候创建的request_sock结构体, 到这里内核才会为这条连接创建真正的重量级sock结构体. 19 | 但是sock还只是socket的子集(socket结构体中有一个指针sock * sk), 此时一条连接至少还需要绑定一个fd(文件描述符)才能传输数据, accept系统调用后将绑定一个fd.20 | 21 |
accept流程图:
22 |
1.tcp_v4_rcv()是传输层报文处理入口, 主要做一下事情: 25 | a)从报文中获取TCP头部数据, 验证TCP首部检验和 26 | b)根据TCP首部中的信息来设置TCP控制块中的值，这里要进行字节序的转换 27 | c)接着会调用__tcp_v4_lookup() 28 | 29 | 2.__tcp_v4_lookup()用来查找传输控制块sk, 如果未找到则直接给对端发RST(我们java层常看到的connection reset by peer就是RST导致, 很多情况下会给对端发送RST,找不到sk只是RST众多导火索中的一个). 30 | 31 | 3.接着检查第二步中找到的传输控制块sk, 如果进程没有访问sk, 会接着调用tcp_v4_do_rcv()来正常接收, tcp_v4_do_rcv()是传输层处理TCP段的主入口 32 | 33 | 4.如果sk->sk_state == TCP_LISTEN, 代表是监听套接字, 则应该处理被动连接(注意下accept的连接就是被动连接) 34 | 35 | 5.sock *nsk = tcp_v4_hnd_req(sk, skb); 36 | tcp_v4_hnd_req()处理半连接状态的ACK消息, 这里分两种情况: 37 | 1)tcp_v4_hnd_req()直接返回了nsk并且nsk == sk(这代表现在是第一次握手), 此时沿着上图左边虚线框里的路径继续往下执行. 38 | 2)tcp_v4_hnd_req()里面调用tcp_v4_search_req()根据TCP四元组(源端口、源地址、目的地址)在父传输控制块的散列表中查找相应的连接请求块, 那说明两次握手已完成, 直接调用tcp_check_req()进行三次握手确认. 39 | 此时沿着右边虚线框执行. 40 | 41 | **一.先分析左边第一条链路, 也就是处理SYN** 42 | a)首先是tcp_rcv_state_process(), 除了ESTABLISHED和TIME_WAIT状态外，其他状态下的TCP段处理都由这个函数实现. 如果是处理SYN, 它会调用tcp_v4_conn_request()来处理. 43 | b)tcp_v4_conn_request()函数里会做如下检查: 44 | 1)SYN queue是不是满了? 如果满了并且没有启用syncookie功能, 则直接丢弃连接 45 | 2)accept queue是不是满了?如果满了并且SYN请求队列中至少有一个握手过程中没有重传，则丢弃 46 | c)通过了b)中的检查, 说明可以接收并处理请求, 调用tcp_openreq_alloc()先分配一个请求块. 47 | d)接着调用tcp_parse_options()解析TCP段中的选项 48 | e)然后初始化好连接请求块后就可以调用tcp_v4_send_synack()像客户端发送SYN + ACK了 49 | f)最后调用tcp_v4_synq_add()将这个sk加入SYN queue中. 50 | 最后注意下其实sk只是一个轻量级的request_sock, 毕竟sock结构体比request_sock大的多, 犯不着三次握手都没建立起来我就建立一个大的结构体. 51 | 现在一个sock已经进入SYN queue, 目前的阶段是握手的第二步, 收到SYN并且回复对端SYN + ACK(希望你记得上一章我们讲backlog时提到过的两个队列, SYN queue就是其中一个) 52 | 53 | **二.接下来第二条链路, 右边的虚线框** 54 | a) tcp_v4_search_req()通过TCP四元组查到了对应的请求块, 说明两次握手已经完成, 进行第三次握手确认, 也就是处理ACK. 55 | b)如果检查第三次握手的ACK段是有效的, 则调用tcp_v4_syn_recv_sock()创建子传输控制块. 56 | c)tcp_v4_syn_recv_sock()方法里有很多初始化操作 57 | 1)创建子传输控制块，并进行初始化(这里是真正的重量级sock了) 58 | 2)设置路由缓存，确定输出网络接口的特性 59 | 3)根据路由中的路径MTU信息，设置控制块MSS 60 | 4)与本地端口进行绑定 61 | 最后会返回一个真正的重量级sock(注意区别前边提到的sk == request_sock) 62 | d)接着调用tcp_synq_unlink()将sk从SYN queue中移除, 告别半连接身份 63 | e)现在通过tcp_acceptq_queue()把这个重量级的sock加入的accept queue, 到此这个TCP连接已经可以被我们的应用层netty拿去玩了.64 | 65 |
好吧, 我知道上面的文字中很多东西没有详细展开, 只关注java层的同学可能看着稍微吃力, 下面贴上两个图, 一个tcp三路握手, 一个tcp状态变迁图
66 | 67 |
第一个图来自耗子叔的TCP那些事, 三次握手过程
71 | 72 |第二个图在网上随便搜的, 来源不清楚了, 不过最终的源头肯定是[TCP/IP详解]一书了, 这是一个TCP状态变迁图, 我们上面分析的accept过程属于被动打开
, 可以仔细对照图看一下.图中所有的TCP状态这里不解释了, 篇幅控制不住了, 大家参照[TCP/IP详解]一书.
现在铺垫完了, 开始分析netty的accept过程. 75 | 又要拿出第一章(EventLoop)的代码了, 多路复用IO的dispatch:
76 | 77 |233 | 234 |private static void processSelectedKey(SelectionKey k, AbstractNioChannel ch) { 78 | final AbstractNioChannel.NioUnsafe unsafe = ch.unsafe(); 79 | // ...... 80 | try { 81 | int readyOps = k.readyOps(); 82 | // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead 83 | // to a spin loop 84 | if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) { 85 | unsafe.read(); 86 | if (!ch.isOpen()) { 87 | // Connection already closed - no need to handle write. 88 | return; 89 | } 90 | } 91 | if ((readyOps & SelectionKey.OP_WRITE) != 0) { 92 | // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to write 93 | ch.unsafe().forceFlush(); 94 | } 95 | if ((readyOps & SelectionKey.OP_CONNECT) != 0) { 96 | // remove OP_CONNECT as otherwise Selector.select(..) will always return without blocking 97 | // See https://github.com/netty/netty/issues/924 98 | int ops = k.interestOps(); 99 | ops &= ~SelectionKey.OP_CONNECT; 100 | k.interestOps(ops); 101 | 102 | unsafe.finishConnect(); 103 | } 104 | } catch (CancelledKeyException ignored) { 105 | unsafe.close(unsafe.voidPromise()); 106 | } 107 | }108 | 109 | 以后分析read, write等逻辑是都要从这个代码开始, 现在我们只关心OP_ACCEPT, 由前两章的分析我们知道, 这里调用的是NioMessageUnsafe#read() 110 | 111 |112 | public void read() { 113 | // ...... 114 | final int maxMessagesPerRead = config.getMaxMessagesPerRead(); 115 | final ChannelPipeline pipeline = pipeline(); 116 | boolean closed = false; 117 | Throwable exception = null; 118 | try { 119 | try { 120 | for (;;) { 121 | int localRead = doReadMessages(readBuf); 122 | if (localRead == 0) { 123 | break; 124 | } 125 | if (localRead < 0) { 126 | closed = true; 127 | break; 128 | } 129 | 130 | // stop reading and remove op 131 | if (!config.isAutoRead()) { 132 | break; 133 | } 134 | 135 | if (readBuf.size() >= maxMessagesPerRead) { 136 | break; 137 | } 138 | } 139 | } catch (Throwable t) { 140 | exception = t; 141 | } 142 | setReadPending(false); 143 | int size = readBuf.size(); 144 | for (int i = 0; i < size; i ++) { 145 | pipeline.fireChannelRead(readBuf.get(i)); 146 | } 147 | 148 | readBuf.clear(); 149 | pipeline.fireChannelReadComplete(); 150 | 151 | if (exception != null) { 152 | if (exception instanceof IOException && !(exception instanceof PortUnreachableException)) { 153 | closed = !(AbstractNioMessageChannel.this instanceof ServerChannel); 154 | } 155 | pipeline.fireExceptionCaught(exception); 156 | } 157 | if (closed) { 158 | if (isOpen()) { 159 | close(voidPromise()); 160 | } 161 | } 162 | } finally { 163 | if (!config.isAutoRead() && !isReadPending()) { 164 | removeReadOp(); 165 | } 166 | } 167 | } 168 | }169 | 170 | 1. maxMessagesPerRead的默认值在NioMessageUnsafe中为16, 尽可能的一次多accept些连接, 在os层我们提到了accept queue会满, 所以应用层越早拿走accept queue中的连接越好. 171 | 172 | 2. 接下来重头戏是doReadMessages 173 | 174 |protected int doReadMessages(List<Object> buf) throws Exception { 175 | SocketChannel ch = javaChannel().accept(); 176 | try { 177 | if (ch != null) { 178 | buf.add(new NioSocketChannel(this, ch)); 179 | return 1; 180 | } 181 | } catch (Throwable ignored) {} 182 | return 0; 183 | }184 | a)javaChannel().accept()会通过accept系统调用从os的accept queue中拿出一个连接并包装成SocketChannel 185 | 186 | b)接着又包装一层netty的NioSocketChannel之后放进buf中. 187 | 188 | c)NioSocketChannel构造方法将SocketChannel感兴趣的事件设置成OP_READ, 并设置成非阻塞模式. 189 | 190 | 191 | 3. 我们回到unsafe#read()方法, 如果每次调用doReadMessages都能拿到一个channel, 那么一直拿到16个以上的channel再跳出循环, 原因在第一点中已经说了. 192 | 如果localRead == 0, 表示此时os 的 accept queue中可能已经没有就绪连接了, 所以也跳出循环. 193 | 194 | 4. 接下来触发channelRead event: 195 | pipeline.fireChannelRead(readBuf.get(i)); 196 | channelRead是inbound event, 回想之前pipeline中的顺序(head--> ServerBootstrapAcceptor-->tail), 会调用ServerBootstrapAcceptor的channelRead() 197 | 198 |public void channelRead(ChannelHandlerContext ctx, Object msg) { 199 | final Channel child = (Channel) msg; 200 | 201 | child.pipeline().addLast(childHandler); 202 | 203 | // 设置child options, attrs 204 | 205 | try { 206 | childGroup.register(child).addListener(new ChannelFutureListener() { 207 | @Override 208 | public void operationComplete(ChannelFuture future) throws Exception { 209 | if (!future.isSuccess()) { 210 | forceClose(child, future.cause()); 211 | } 212 | } 213 | }); 214 | } catch (Throwable t) { 215 | forceClose(child, t); 216 | } 217 | }218 | 219 | 前两篇开篇实例有如下代码: 220 |b.childHandler(new ChannelInitializer<SocketChannel>() { 221 | @Override 222 | public void initChannel(SocketChannel ch) throws Exception { 223 | ChannelPipeline p = ch.pipeline(); 224 | p.addLast(new EchoServerHandler()); 225 | } 226 | });227 | 228 | 1.child.pipeline().addLast(childHandler)就是将这里我们自己用户逻辑相关的handler加入到 channel 的pipeline里面(注意这是worker的pipeline, 前面提到的都是boss 的 pipeline) 229 | 230 | 2.设置child options, attrs 231 | 232 | 3.接下里从workerGroup中拿出一个workerEventLoop并将channel注册到其中, register()的逻辑和第二篇讲bind时bossEventLoop的注册基本是一样的, 这里我们不再重复讲了.
到这里, 一次accept流程, 就完成了, 现在这个channel就有workerEventLoop来处理读写等事件了.
235 | -------------------------------------------------------------------------------- /netty/Netty源码细节2--bind.md: -------------------------------------------------------------------------------- 1 |前言
2 | 3 |本菜鸟有过几年的网络IO相关经验, java层面netty也一直关注, 最近想对自己所了解的netty做一个系列的笔记, 不光技术水平有限, 写作水平更有限, 难免有错误之处欢迎指正, 共同学习.
4 | 5 |源码来自Netty5.x版本, 本系列文章不打算从架构的角度去讨论netty, 只想从源码细节展开, 又不想通篇的贴代码, 如果没有太大的必要, 我会尽量避免贴代码或是去掉不影响主流程逻辑的代码, 尽量多用语言描述. 这个过程中我会把我看到的netty对代码进行优化的一些细节提出来探讨, 大家共同学习, 更希望能抛砖引玉.
6 | 7 |上一篇讲了EventLoop, 这一篇看一下server端如何bind的, 继续从上一篇开篇代码示例开始
8 | 9 |服务端启动代码示例
10 | 11 |
// Configure the server.
12 | EventLoopGroup bossGroup = new NioEventLoopGroup(1);
13 | EventLoopGroup workerGroup = new NioEventLoopGroup();
14 | try {
15 | ServerBootstrap b = new ServerBootstrap();
16 | b.group(bossGroup, workerGroup)
17 | .channel(NioServerSocketChannel.class)
18 | .option(ChannelOption.SO_BACKLOG, 100)
19 | .handler(new LoggingHandler(LogLevel.INFO))
20 | .childHandler(new ChannelInitializer<SocketChannel>() {
21 | @Override
22 | public void initChannel(SocketChannel ch) throws Exception {
23 | ChannelPipeline p = ch.pipeline();
24 | p.addLast(new EchoServerHandler());
25 | }
26 | });
27 | // Start the server.
28 | ChannelFuture f = b.bind(PORT).sync();
29 | // Wait until the server socket is closed.
30 | f.channel().closeFuture().sync();
31 | } finally {
32 | // Shut down all event loops to terminate all threads.
33 | bossGroup.shutdownGracefully();
34 | workerGroup.shutdownGracefully();
35 | }服务端启动第一步是ChannelFuture f = b.bind(PORT), 接下来分析其详细过程, 先直接进入AbstractBootstrap#doBind()方法
private ChannelFuture doBind(final SocketAddress localAddress) {
40 | final ChannelFuture regFuture = initAndRegister();
41 | final Channel channel = regFuture.channel();
42 | if (regFuture.cause() != null) {
43 | return regFuture;
44 | }
45 |
46 | if (regFuture.isDone()) {
47 | ChannelPromise promise = channel.newPromise();
48 | doBind0(regFuture, channel, localAddress, promise);
49 | return promise;
50 | } else {
51 | final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
52 | regFuture.addListener(new ChannelFutureListener() {
53 | @Override
54 | public void operationComplete(ChannelFuture future) throws Exception {
55 | Throwable cause = future.cause();
56 | if (cause != null) {
57 | promise.setFailure(cause);
58 | } else {
59 | promise.executor = channel.eventLoop();
60 | }
61 | doBind0(regFuture, channel, localAddress, promise);
62 | }
63 | });
64 | return promise;
65 | }
66 | }
67 | 这个方法调用栈太深, 具体执行流程就不像上一章那样在这里一一列出了, 跟着代码调用链走好了
68 | 首先第一步我们最关心的肯定是, NIO服务端嘛, 总要有个监听套接字ServerSocketChannel吧?这个动作是由initAndRegister()完成的先重点看一下initAndRegister()方法:
71 |109 |final ChannelFuture initAndRegister() { 72 | final Channel channel = channelFactory().newChannel(); 73 | try { 74 | init(channel); 75 | } catch (Throwable t) { 76 | // ...... 77 | } 78 | ChannelFuture regFuture = group().register(channel); 79 | if (regFuture.cause() != null) { 80 | if (channel.isRegistered()) { 81 | channel.close(); 82 | } else { 83 | channel.unsafe().closeForcibly(); 84 | } 85 | } 86 | return regFuture; 87 | }88 | 1.首先channelFactory在开篇示例代码b.channel(NioServerSocketChannel.class)中被设置成了new ReflectiveChannelFactory<C>(NioServerSocketChannel.class)89 | 再看一下ReflectiveChannelFactory代码, 实际上是factory通过反射创建一个NioServerSocketChannel对象 90 |91 | public class ReflectiveChannelFactory<T extends Channel> implements ChannelFactory<T> { 92 | private final Class<? extends T> clazz; 93 | public ReflectiveChannelFactory(Class<? extends T> clazz) { 94 | if (clazz == null) { 95 | throw new NullPointerException("clazz"); 96 | } 97 | this.clazz = clazz; 98 | } 99 | 100 | @Override 101 | public T newChannel() { 102 | try { 103 | return clazz.newInstance(); 104 | } catch (Throwable t) { 105 | throw new ChannelException("Unable to create Channel from class " + clazz, t); 106 | } 107 | } 108 | }
现在清楚了b.channel(NioServerSocketChannel.class)都做了什么,但是构造NioServerSocketChannel还是做了很多工作的,
110 | clazz.newInstance()调用的是默认无参构造方法, 来看一下 NioServerSocketChannel的无参构造方法:
165 | 166 |public NioServerSocketChannel() { 113 | this(newSocket(DEFAULT_SELECTOR_PROVIDER)); 114 | } 115 | private static ServerSocketChannel newSocket(SelectorProvider provider) { 116 | try { 117 | return provider.openServerSocketChannel(); 118 | } catch (IOException e) { 119 | throw new ChannelException("Failed to open a server socket.", e); 120 | } 121 | }122 | 1.到这里终于找到了,在newSocket()中创建了开篇提到的监听套接字ServerSocketChannel 123 |124 | public NioServerSocketChannel(ServerSocketChannel channel) { 125 | super(null, channel, SelectionKey.OP_ACCEPT); 126 | config = new NioServerSocketChannelConfig(this, javaChannel().socket()); 127 | }128 | 2.这里可以看到SelectionKey.OP_ACCEPT标志就是监听套接字所感兴趣的事件了(但是还没注册进去,别着急, 自己挖的坑会含泪填完) 129 |130 | protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) { 131 | super(parent); 132 | this.ch = ch; 133 | this.readInterestOp = readInterestOp; 134 | try { 135 | ch.configureBlocking(false); 136 | } catch (IOException e) { 137 | // ...... 138 | } 139 | }140 | 3.在父类构造函数我们看到了configureBlocking为false,终于将ServerSocketChannel设置为非阻塞模式, NIO之旅可以顺利开始了 141 |142 | protected AbstractChannel(Channel parent) { 143 | this.parent = parent; 144 | id = DefaultChannelId.newInstance(); 145 | unsafe = newUnsafe(); 146 | pipeline = new DefaultChannelPipeline(this); 147 | }148 | 4.继续父类构造方法,这里干了如下几件重要的事情: 149 | 1)构造一个unsafe绑定在serverChanel上,newUnsafe()由子类AbstractNioMessageChannel实现, unsafe的类型为NioMessageUnsafe, 150 | NioMessageUnsafe类型专为serverChanel服务, 专门处理accept连接 151 | 2)创建用于NioServerSocketChannel的管道 boss pipeline 152 |153 | DefaultChannelPipeline(AbstractChannel channel) { 154 | // ...... 155 | this.channel = channel; 156 | 157 | tail = new TailContext(this); 158 | head = new HeadContext(this); 159 | 160 | head.next = tail; 161 | tail.prev = head; 162 | }163 | 5.head和tail是pipeline的两头, head是outbound event的末尾, tail是inbound event的末尾. 164 | 按照上行事件(inbound)顺序来看, 现在pipeline中的顺序是head-->tail
再回到initAndRegister()方法, 继续看下面这段代码:
167 |187 | 188 |init(channel);168 | 由于现在讲的是server的bind, 所以去看ServerBootstrap的init()实现: 169 |170 | void init(Channel channel) throws Exception { 171 | // ...... 172 | p.addLast(new ChannelInitializer<Channel>() { 173 | @Override 174 | public void initChannel(Channel ch) throws Exception { 175 | ch.pipeline().addLast(new ServerBootstrapAcceptor( 176 | currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs)); 177 | } 178 | }); 179 | }180 | 1.init方法的代码比较多, 但是不难理解, 最上面我省略的部分做了这些事情: 181 | 1)设置NioServerSocketChannel的options和attrs. 182 | 2)预先复制好将来要设置给NioSocketChannel的options和attrs. 183 | 这里强调一下, 通常channel可分为两类XXXServerSocketChannel和XXXSocketChannel, 前者可以先简单理解为accept用的, 后者用来read和write等, 后面流程梳理通畅了这个问题也就迎刃而解了. 184 | 185 | 2.init做的第二件事就是在boss pipeline添加一个ChannelInitializer, 186 | 那么现在pipeline中的顺序变成了head-->ChannelInitializer-->tail(注意head和tail永远在两头, addLast方法对他俩不起作用)
ChannelInitializer这个类很有意思, 来看下它的代码吧
189 | 190 |216 | 217 | 218 |public abstract class ChannelInitializer<C extends Channel> extends ChannelHandlerAdapter { 191 | protected abstract void initChannel(C ch) throws Exception; 192 | 193 | @Override 194 | public final void channelRegistered(ChannelHandlerContext ctx) throws Exception { 195 | ChannelPipeline pipeline = ctx.pipeline(); 196 | boolean success = false; 197 | try { 198 | initChannel((C) ctx.channel()); 199 | pipeline.remove(this); 200 | ctx.fireChannelRegistered(); 201 | success = true; 202 | } catch (Throwable t) { 203 | // ...... 204 | } finally { 205 | // ...... 206 | } 207 | } 208 | }209 | 1.首先当有regist事件发生时, 最终会调用到channelRegistered(), 在这个方法里 210 | 先调用了抽象方法initChannel, 回看init()的代码,此时ServerBootstrapAcceptor会被加入到pipeline 211 | 现在的顺序是head--> ServerBootstrapAcceptor-->tail 212 | 213 | 2.然后从pipeline中移除自己, 因为它的工作已进入收尾阶段, 接下来只要将channelRegistered继续往pipeline中后续handler流转它就可以退出历史舞台了. 214 | 215 | 3.至于ServerBootstrapAcceptor是干什么的?先简单介绍一下,它是在一个accept的channel从boss移交给worker过程中的一个重要环节, 等以后的流程涉及到了它再详细分析(此坑下一篇填)
init() 的主要流程至此已分析的差不多了, init之后就是group().register(channel)了
219 | 220 | 221 |251 | 252 |ChannelFuture regFuture = group().register(channel);222 | 1.这里group()返回的自然是开篇示例代码中的bossGroup了 223 | 224 | 2.register调用的是MultithreadEventLoopGroup的实现: 225 |public ChannelFuture register(Channel channel) { 226 | return next().register(channel); 227 | }228 | 看见next()不知是否想起了前一篇分析EventLoop时提到的 "用取模的方式从group中拿出一个EventLoop"?对的就是这么干的, 调用栈是这样的: 229 |public EventExecutor next() { 230 | return chooser.next(); 231 | }232 | 然后调用: 233 |private final class GenericEventExecutorChooser implements EventExecutorChooser { 234 | @Override 235 | public EventExecutor next() { 236 | return children[Math.abs(childIndex.getAndIncrement() % children.length)]; 237 | } 238 | }239 | 或是调用(这个类是在个数为2的N次方时的优化chooser版本): 240 |private final class PowerOfTwoEventExecutorChooser implements EventExecutorChooser { 241 | @Override 242 | public EventExecutor next() { 243 | return children[childIndex.getAndIncrement() & children.length - 1]; 244 | } 245 | }246 | 但是由于bossEventLoop我们在开篇示例中设置只有1个, 通常情况下1个也够用了,除非你要绑定多个端口,所以这里next()其实总会返回同一个 247 | 248 | 3.接着register()调用路径往下 249 | SingleThreadEventLoop#register()中调用了channel.unsafe().register(this, promise); 250 | 到此类似闯关游戏最后一关大怪基本要现身了, unsafe#register()代码在AbstractChannel$AbstractUnsafe中
重点看一下AbstractUnsafe#register()
253 |292 | 293 |public final void register(EventLoop eventLoop, final ChannelPromise promise) { 254 | // ...... 255 | // It's necessary to reuse the wrapped eventloop object. Otherwise the user will end up with multiple 256 | // objects that do not share a common state. 257 | if (AbstractChannel.this.eventLoop == null) { 258 | AbstractChannel.this.eventLoop = new PausableChannelEventLoop(eventLoop); 259 | } else { 260 | AbstractChannel.this.eventLoop.unwrapped = eventLoop; 261 | } 262 | 263 | if (eventLoop.inEventLoop()) { 264 | register0(promise); 265 | } else { 266 | try { 267 | eventLoop.execute(new OneTimeTask() { 268 | @Override 269 | public void run() { 270 | register0(promise); 271 | } 272 | }); 273 | } catch (Throwable t) { 274 | // ...... 275 | } 276 | } 277 | }278 | eventLoop.inEventLoop()是判断当前线程是否为EventLoop线程, 此时当前线程还是我们的main线程, bossEventLoop线程还没有启动, 279 | 所以会走到else分支调用eventLoop.execute(),在SingleThreadEventExecutor的execute方法中会判断当前线程是否为eventLoop如果不是, 则启动当前eventLoop线程 280 |public void execute(Runnable task) { 281 | // ...... 282 | boolean inEventLoop = inEventLoop(); 283 | if (inEventLoop) { 284 | addTask(task); 285 | } else { 286 | startExecution(); 287 | // ...... 288 | } 289 | // ...... 290 | }291 | 到现在为止, bossEventLoop终于开门红, 接了第一笔单子, 即register0()任务, 丢到了MPSC队列里.
接下来分析register0()
294 |private void register0(ChannelPromise promise) {
295 | try {
296 | // ......
297 | doRegister();
298 | // ......
299 | safeSetSuccess(promise); // 注意这行代码我不会平白无故不删它的, 下面会提到它
300 | pipeline.fireChannelRegistered();
301 | // Only fire a channelActive if the channel has never been registered. This prevents firing
302 | // multiple channel actives if the channel is deregistered and re-registered.
303 | if (firstRegistration && isActive()) {
304 | pipeline.fireChannelActive();
305 | }
306 | } catch (Throwable t) {
307 | // ......
308 | }
309 | }
310 | 1.到这里我已经要哭了, register0()还不是最终大怪, 还有一个doRegister()
311 |
312 | 2.不过在doRegister()之后还调用了pipeline.fireChannelRegistered(), 是的就是它, 还能想起上文中提到的ChannelInitializer吗? ChannelInitializer#channelRegistered()方法就是在这里被触发的.
313 |
314 | 3.剩下的代码fireChannelActive()注释上已经写的很明白了, 不多做解释了(这里一般不会调用, 因为此时isActive()很难是true).继续转战doRegister()
317 |protected void doRegister() throws Exception {
318 | boolean selected = false;
319 | for (;;) {
320 | try {
321 | selectionKey = javaChannel().register(((NioEventLoop) eventLoop().unwrap()).selector, 0, this);
322 | return;
323 | } catch (CancelledKeyException e) {
324 | // ......
325 | }
326 | }
327 | }
328 | javaChannel().register(), 终于看到最关键的这行代码, 实际调用的实现是:
329 | java.nio.channels.spi.AbstractSelectableChannel#register(Selector sel, int ops, Object att)
330 | 至此NIO固有的套路出现了,这里先把interestOps注册为0, OP_ACCEPT相信接下来会出现的, 继续看代码在返回doBind()接着看doBind0()之前, 先留意一下register0()中我刻意留着没有删除的代码safeSetSuccess(promise)
333 |上面那句代码会将promise的success设置为true并触发回调在doBind()中添加的listener
334 | 335 |regFuture.addListener(new ChannelFutureListener() {
336 | @Override
337 | public void operationComplete(ChannelFuture future) throws Exception {
338 | // ......
339 | doBind0(regFuture, channel, localAddress, promise);
340 | }
341 | });
342 |
343 | private static void doBind0(
344 | final ChannelFuture regFuture, final Channel channel,
345 | final SocketAddress localAddress, final ChannelPromise promise) {
346 |
347 | // This method is invoked before channelRegistered() is triggered. Give user handlers a chance to set up
348 | // the pipeline in its channelRegistered() implementation.
349 | channel.eventLoop().execute(new Runnable() {
350 | @Override
351 | public void run() {
352 | if (regFuture.isSuccess()) {
353 | channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
354 | } else {
355 | promise.setFailure(regFuture.cause());
356 | }
357 | }
358 | });
359 | }
360 |
361 | 到这里,bossEventLoop已经接到第二个任务了(bind), 第一个还记得吧(register0)接下来继续bind的细节吧
364 | 365 |AbstractChannel#bind()代码: 366 |527 | -------------------------------------------------------------------------------- /netty/Netty源码细节1--IO线程(EventLoop).md: -------------------------------------------------------------------------------- 1 |367 | public ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) { 368 | return pipeline.bind(localAddress, promise); 369 | }370 | 371 | ChannelPipeline目前只有一个默认实现即DefaultChannelPipeline 372 |public ChannelFuture bind(SocketAddress localAddress) { 373 | return tail.bind(localAddress); 374 | }375 | 376 | 接着调用AbstractChannelHandlerContext的bind 377 |public ChannelFuture bind(final SocketAddress localAddress, final ChannelPromise promise) { 378 | AbstractChannelHandlerContext next = findContextOutbound(); 379 | next.invoker().invokeBind(next, localAddress, promise); 380 | return promise; 381 | }382 | 1.第一行代码中findContextOutbound(), 看字面意思就知道是找出下一个outbound handler 的 ctx, 这里是找到第一个outbound 的 ctx.(注意bind是outbound event) 383 | 384 | 2.invoker()也是一个默认实现即DefaultChannelHandlerInvoker, 不详细解释了, 385 | 还记的上面已经说过的目前pipeline中的顺序是head--> ServerBootstrapAcceptor-->tail 吧? 386 | 第一章节已经讲过outbound的执行顺序是反过来的, 而这三个当中只有head是处理outbound的 387 |public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception { 388 | unsafe.bind(localAddress, promise); 389 | }390 | 391 | 又见unsafe咯 392 |public final void bind(final SocketAddress localAddress, final ChannelPromise promise) { 393 | // ...... 394 | boolean wasActive = isActive(); 395 | try { 396 | doBind(localAddress); 397 | } catch (Throwable t) { 398 | safeSetFailure(promise, t); 399 | closeIfClosed(); 400 | return; 401 | } 402 | 403 | if (!wasActive && isActive()) { 404 | invokeLater(new OneTimeTask() { 405 | @Override 406 | public void run() { 407 | pipeline.fireChannelActive(); 408 | } 409 | }); 410 | } 411 | safeSetSuccess(promise); 412 | }413 | 414 | 上面的doBind()调用的是NioServerSocketChannel的实现: 415 |protected void doBind(SocketAddress localAddress) throws Exception { 416 | javaChannel().socket().bind(localAddress, config.getBacklog()); 417 | }418 | 到此, 赤裸裸的nio api 之 ServerSocket.bind()已呈现在你眼前 419 | 大家做网络IO开发的一定了解第二个参数backlog的重要性,在linux内核中TCP握手过程总共会有两个队列: 420 | 1)一个俗称半连接队列, 装着那些握手一半的连接(syn queue) 421 | 2)另一个是装着那些握手成功但是还没有被应用层accept的连接的队列(accept queue) 422 | backlog的大小跟这两个队列的容量之和息息相关, 还有哇, "爱情不是你想买,想买就能买", backlog的值也不是你设置多少它就是多少的, 具体你要参考linux内核代码(甚至文档都不准) 423 | 我临时翻了一下linux-3.10.28的代码, 逻辑是这样的(socket.c): 424 | 425 |sock = sockfd_lookup_light(fd, &err, &fput_needed); 426 | if (sock) { 427 | somaxconn = sock_net(sock->sk)->core.sysctl_somaxconn; 428 | if ((unsigned int)backlog > somaxconn) 429 | backlog = somaxconn; 430 | 431 | err = security_socket_listen(sock, backlog); 432 | if (!err) 433 | err = sock->ops->listen(sock, backlog); 434 | 435 | fput_light(sock->file, fput_needed); 436 | }437 | 我们清楚的看到backlog 并不是按照你所设置的backlog大小，实际上取的是backlog和somaxconn的最小值 438 | somaxconn的值定义在: 439 |/proc/sys/net/core/somaxconn440 | netty中backlog在linux下的默认值也是somaxconn 441 | 442 | 还有一点要注意, 对于TCP连接的ESTABLISHED状态, 并不需要应用层accept, 只要在accept queue里就已经变成状态ESTABLISHED, 所以在使用ss或netstat排查这方面问题不要被ESTABLISHED迷惑. 443 | 444 | 额, 白呼了一堆java层大家一般不是很关心的东西, 现在我们回到正题, 回到unsafe.bind()方法 445 | 1.在doBind()之前wasActive基本上会是false了, doBind()之后isActive()为true, 所以这里会触发channelActive事件 446 | 447 | 2.这里由于bind是一个outbound, 所以选择invokeLater()的方式去触发channelActive这个inbound, 具体原因我还是把invokeLater()的注释放出来吧, 说的很明白: 448 |private void invokeLater(Runnable task) { 449 | try { 450 | // This method is used by outbound operation implementations to trigger an inbound event later. 451 | // They do not trigger an inbound event immediately because an outbound operation might have been 452 | // triggered by another inbound event handler method. If fired immediately, the call stack 453 | // will look like this for example: 454 | // 455 | // handlerA.inboundBufferUpdated() - (1) an inbound handler method closes a connection. 456 | // -> handlerA.ctx.close() 457 | // -> channel.unsafe.close() 458 | // -> handlerA.channelInactive() - (2) another inbound handler method called while in (1) yet 459 | // 460 | // which means the execution of two inbound handler methods of the same handler overlap undesirably. 461 | eventLoop().unwrap().execute(task); 462 | } catch (RejectedExecutionException e) { 463 | logger.warn("Can't invoke task later as EventLoop rejected it", e); 464 | } 465 | }466 | 467 | 3.channelActive是一个inbound, 再一次回到pipeline的顺序head--> ServerBootstrapAcceptor-->tail, 此时按照head-->tail的顺序执行. 468 | ServerBootstrapAcceptor和tail都是indound handler 469 | 先看DefaultChannelPipeline的fireChannelActive() 470 |public ChannelPipeline fireChannelActive() { 471 | head.fireChannelActive(); 472 | 473 | if (channel.config().isAutoRead()) { 474 | channel.read(); 475 | } 476 | 477 | return this; 478 | }479 | head.fireChannelActive()会让channelActive event按顺序在ServerBootstrapAcceptor和tail中流转, 但是他们俩对这个event都没有实质性的处理, 所以代码我就不贴出来了. 480 | 下面这句channel.read()才是能提起兴趣的代码 481 | 注意这个read可不是一个读数据的 inbound event, 他是一个outbound event, 是"开始读"的意思, 这个event在pipeline中从tail开始溜达最终会溜达到head的read()方法: 482 |public void read(ChannelHandlerContext ctx) { 483 | unsafe.beginRead(); 484 | }485 | 又回到unsafe了 486 |// AbstractChannel 487 | public final void beginRead() { 488 | // ...... 489 | try { 490 | doBeginRead(); 491 | } catch (final Exception e) { 492 | invokeLater(new OneTimeTask() { 493 | @Override 494 | public void run() { 495 | pipeline.fireExceptionCaught(e); 496 | } 497 | }); 498 | close(voidPromise()); 499 | } 500 | } 501 | 502 | // AbstractNioChannel 503 | protected void doBeginRead() throws Exception { 504 | // ...... 505 | final SelectionKey selectionKey = this.selectionKey; 506 | if (!selectionKey.isValid()) { 507 | return; 508 | } 509 | 510 | readPending = true; 511 | 512 | final int interestOps = selectionKey.interestOps(); 513 | if ((interestOps & readInterestOp) == 0) { 514 | selectionKey.interestOps(interestOps | readInterestOp); 515 | } 516 | }517 | 518 | 记不住了的往上面翻翻看, 上面挖的坑, 注册的时候,doRegister()方法里面的代码: 519 |selectionKey = javaChannel().register(((NioEventLoop) eventLoop().unwrap()).selector, 0, this);520 | 现在是时候填坑了, 当时注册了0, 现在要把readInterestOp注册进去了, readInterestOps就是NioServerSocketChannel构造函数传入的OP_ACCEPT, 再贴一遍代码: 521 |public NioServerSocketChannel(ServerSocketChannel channel) { 522 | super(null, channel, SelectionKey.OP_ACCEPT); 523 | config = new NioServerSocketChannelConfig(this, javaChannel().socket()); 524 | }525 | 526 | 好了, bind到此分析结束.下一篇会尝试分析accept
本菜鸟有过几年的网络IO相关经验, java层面netty也一直关注, 最近想对自己所了解的netty做一个系列的笔记, 不光技术水平有限, 写作水平更有限, 难免有错误之处欢迎指正, 共同学习.
2 | 3 |源码来自Netty5.x版本, 本系列文章不打算从架构的角度去讨论netty, 只想从源码细节展开, 又不想通篇的贴代码, 如果没有太大的必要, 我会尽量避免贴代码或是去掉不影响主流程逻辑的代码, 尽量多用语言描述. 这个过程中我会把我看到的netty对代码进行优化的一些细节提出来探讨, 大家共同学习, 更希望能抛砖引玉.
4 | 5 |java nio api细节这里不会讨论, 不过推荐一个非常好入门系列 http://ifeve.com/overview/
6 | 7 |先从一个简单的代码示例开始
8 | 9 |服务端启动代码示例
10 | 11 | // Configure the server.
12 | EventLoopGroup bossGroup = new NioEventLoopGroup(1);
13 | EventLoopGroup workerGroup = new NioEventLoopGroup();
14 | try {
15 | ServerBootstrap b = new ServerBootstrap();
16 | b.group(bossGroup, workerGroup)
17 | .channel(NioServerSocketChannel.class)
18 | .option(ChannelOption.SO_BACKLOG, 100)
19 | .handler(new LoggingHandler(LogLevel.INFO))
20 | .childHandler(new ChannelInitializer<SocketChannel>() {
21 | @Override
22 | public void initChannel(SocketChannel ch) throws Exception {
23 | ChannelPipeline p = ch.pipeline();
24 | p.addLast(new EchoServerHandler());
25 | }
26 | });
27 | // Start the server.
28 | ChannelFuture f = b.bind(PORT).sync();
29 | // Wait until the server socket is closed.
30 | f.channel().closeFuture().sync();
31 | } finally {
32 | // Shut down all event loops to terminate all threads.
33 | bossGroup.shutdownGracefully();
34 | workerGroup.shutdownGracefully();
35 | }在看这个示例之前, 先抛出netty中几个重要组件以及他们之间的简单关系, 方便理解后续的代码展开.
38 | 39 |1.EventLoopGroup 40 | 2.EventLoop 41 | 3.boss/worker 42 | 4.channel 43 | 5.event(inbound/outbound) 44 | 6.pipeline 45 | 7.handler 46 | -------------------------------------------------------------------- 47 | 1.EventLoopGroup中包含一组EventLoop 48 | 49 | 2.EventLoop的大致数据结构是 50 | a.一个任务队列 51 | b.一个延迟任务队列(schedule) 52 | c.EventLoop绑定了一个Thread, 这直接避免了pipeline中的线程竞争(在这里更正一下4.1.x以及5.x由于引入了FJP[4.1.x现在又去掉了FJP], 线程模型已经有所变化, EventLoop.run()可能被不同的线程执行,但大多数scheduler(包括FJP)在EventLoop这种方式的使用下都能保证在handler中不会"可见性(visibility)"问题, 所以为了理解简单, 我们仍可以理解为为EventLoop绑定了一个Thread) 53 | d.每个EventLoop有一个Selector, boss用Selector处理accept, worker用Selector处理read,write等 54 | 55 | 3.boss可简单理解为Reactor模式中的mainReactor的角色, worker可简单理解为subReactor的角色 56 | a.boss和worker共用EventLoop的代码逻辑 57 | b.在不bind多端口的情况下bossEventLoopGroup中只需要包含一个EventLoop 58 | c.workerEventLoopGroup中一般包含多个EventLoop 59 | d.netty server启动后会把一个监听套接字ServerSocketChannel注册到bossEventLoop中 60 | e.通过上一点我们知道bossEventLoop一个主要责任就是负责accept连接(channel)然后dispatch到worker 61 | f.worker接到boss爷赏的channel后负责处理此chanel后续的read,write等event 62 | 63 | 4.channel分两大类ServerChannel和channel, ServerChannel对应着监听套接字(ServerSocketChannel), channel对应着一个网络连接 64 | 65 | 5.有两大类event:inbound/outbound(上行/下行) 66 | 67 | 6.event按照一定顺序在pipeline里面流转, 流转顺序参见下图 68 | 69 | 7.pipeline里面有多个handler, 每个handler节点过滤在pipeline中流转的event, 如果判定需要自己处理这个event,则处理(用户可以在pipeline中添加自己的handler) 70 | 71 | -------------------------------------------------------------------- 72 | I/O Request 73 | via Channel or 74 | ChannelHandlerContext 75 | | 76 | +---------------------------------------------------+---------------+ 77 | | ChannelPipeline | | 78 | | \|/ | 79 | | +---------------------+ +-----------+----------+ | 80 | | | Inbound Handler N | | Outbound Handler 1 | | 81 | | +----------+----------+ +-----------+----------+ | 82 | | /|\ | | 83 | | | \|/ | 84 | | +----------+----------+ +-----------+----------+ | 85 | | | Inbound Handler N-1 | | Outbound Handler 2 | | 86 | | +----------+----------+ +-----------+----------+ | 87 | | /|\ . | 88 | | . . | 89 | | ChannelHandlerContext.fireIN_EVT() ChannelHandlerContext.OUT_EVT()| 90 | | [ method call] [method call] | 91 | | . . | 92 | | . \|/ | 93 | | +----------+----------+ +-----------+----------+ | 94 | | | Inbound Handler 2 | | Outbound Handler M-1 | | 95 | | +----------+----------+ +-----------+----------+ | 96 | | /|\ | | 97 | | | \|/ | 98 | | +----------+----------+ +-----------+----------+ | 99 | | | Inbound Handler 1 | | Outbound Handler M | | 100 | | +----------+----------+ +-----------+----------+ | 101 | | /|\ | | 102 | +---------------+-----------------------------------+---------------+ 103 | | \|/ 104 | +---------------+-----------------------------------+---------------+ 105 | | | | | 106 | | [ Socket.read() ] [ Socket.write() ] | 107 | | | 108 | | Netty Internal I/O Threads (Transport Implementation) | 109 | +-------------------------------------------------------------------+110 | 111 |
IO线程组的创建:NioEventLoopGroup
112 | 113 |构造方法:
114 | 115 |public NioEventLoopGroup(int nEventLoops, Executor executor, final SelectorProvider selectorProvider) {
116 | super(nEventLoops, executor, selectorProvider);
117 | }
118 |
119 | nEventLoops:
120 | Group内EventLoop个数, 每个EventLoop都绑定一个线程, 默认值为cpu cores * 2, 对worker来说, 这是一个经验值, 当然如果worker完全是在处理cpu密集型任务也可以设置成 cores + 1 或者是根据自己场景测试出来的最优值.
121 | 一般boss group这个参数设置为1就可以了, 除非需要bind多个端口.
122 | boss和worker的关系可以参考Reactor模式,网上有很多资料.简单的理解就是:boss负责accept连接然后将连接转交给worker, worker负责处理read,write等
123 |
124 | executor:
125 | Netty 4.1.x版本以及5.x版本采用Doug Lea在jsr166中的ForkJoinPool作为默认的executor, 每个EventLoop在一次run方法调用的生命周期内都是绑定在fjp中一个Thread身上(EventLoop父类SingleThreadEventExecutor中的thread实例变量)
126 | 目前netty由于线程模型的关系并没有利用fjp的work−stealing, 关于fjp可参考这个paper http://gee.cs.oswego.edu/dl/papers/fj.pdf
127 |
128 | selectorProvider:
129 | group内每一个EventLoop都要持有一个selector, 就由它提供了
130 |
131 | 上面反复提到过每个EventLoop都绑定了一个Thread(可以这么理解,但5.x中实际不是这样子), 这是netty4.x以及5.x版本相对于3.x版本最大变化之一, 这个改变从根本上避免了outBound/downStream事件在pipeline中的线程竞争父类构造方法:
134 | 135 |private MultithreadEventExecutorGroup(int nEventExecutors,
136 | Executor executor,
137 | boolean shutdownExecutor,
138 | Object... args) {
139 | // ......
140 |
141 | if (executor == null) {
142 | executor = newDefaultExecutorService(nEventExecutors); // 默认fjp
143 | shutdownExecutor = true;
144 | }
145 |
146 | children = new EventExecutor[nEventExecutors];
147 | if (isPowerOfTwo(children.length)) {
148 | chooser = new PowerOfTwoEventExecutorChooser();
149 | } else {
150 | chooser = new GenericEventExecutorChooser();
151 | }
152 |
153 | for (int i = 0; i < nEventExecutors; i++) {
154 | boolean success = false;
155 | try {
156 | children[i] = newChild(executor, args); // child即EventLoop
157 | success = true;
158 | } catch (Exception e) {
159 | // ......
160 | } finally {
161 | if (!success) {
162 | // 失败处理......
163 | }
164 | }
165 | }
166 | // ......
167 | }
168 |
169 | 1.如果之前没有指定executor默认为fjp, fjp的parallelism值即为nEventExecutors
170 | executor(scheduler)可以由用户指定, 这给了第三方很大的自由度, 总会有高级用户想完全的控制scheduler, 比如Twitter的Finagle. https://github.com/netty/netty/issues/2250
171 |
172 | 2.接下来创建children数组, 即EventLoop[],现在可以知道 EventLoop与EventLoopGroup的关系了.
173 |
174 | 3.后面会讲到boss把一个就绪的连接转交给worker时会从children中取模拿出一个EventLoop然后将连接交给它.
175 | 值得注意的是由于这段代码是热点代码, 作为"优化狂魔"netty团队岂会放过这种优化细节? 如果children个数为2的n次方, 会采用和HashMap同样的优化方式[位操作]来代替取模操作:
176 | children[childIndex.getAndIncrement() & children.length - 1]
177 |
178 | 4.接下来的newChild()是构造EventLoop, 下面会详细展开接下来我们分析NioEventLoop
181 | 182 |PS:Netty 4.0.16版本开始由Norman Maurer提供了EpollEventLoop, 基于Linux Epoll ET实现的JNI(java nio基于Epoll LT)Edge Triggered(ET) VS Level Triggered(LT).这在一定程度上提供了更高效的传输层, 同时也减少了java层的gc, 这里不详细展开了, 感兴趣的可看这里 Native transport for Linux wiki
183 | 184 |NioEventLoop
185 | 186 |接上面的newchild()
187 | protected EventLoop newChild(Executor executor, Object... args) throws Exception {
188 | return new NioEventLoop(this, executor, (SelectorProvider) args[0]);
189 | }
190 |
191 | 构造方法:
192 | NioEventLoop(NioEventLoopGroup parent, Executor executor, SelectorProvider selectorProvider) {
193 | super(parent, executor, false);
194 | // ......
195 | provider = selectorProvider;
196 | selector = openSelector();
197 | }
198 |
199 | 父类构造方法:
200 | protected SingleThreadEventExecutor(EventExecutorGroup parent, Executor executor, boolean addTaskWakesUp) {
201 | super(parent);
202 | // ......
203 | this.addTaskWakesUp = addTaskWakesUp;
204 | this.executor = executor;
205 | taskQueue = newTaskQueue();
206 | }
207 |
208 | 1.我们看到首先是打开一个selector, selector的优化细节我们下面会讲到
209 |
210 | 2.接着在父类中会构造一个task queue, 这是一个lock-free的MPSC队列, netty的线程(比如worker)一直在一个死循环状态中(引入fjp后是不断自己调度自己)去执行IO事件和非IO事件.
211 | 除了IO事件, 非IO事件都是先丢到这个MPSC队列再由worker线程去异步执行.
212 | MPSC即multi-producer single-consumer(多生产者, 单消费者) 完美贴合netty的IO线程模型(消费者就是EventLoop自己咯), 情不自禁再给"优化狂魔"点32个赞.
213 |
214 | 跑题一下:
215 | 对lock-free队列感兴趣可以仔细看看MpscLinkedQueue的代码, 其中一些比如为了避免伪共享的long padding优化也是比较有意思的.
216 | 如果还对类似并发队列感兴趣的话请转战这里 https://github.com/JCTools/JCTools
217 | 另外报个八卦料曾经也有人提出在这里引入disruptor后来不了了之, 相信用disruptor也会很有趣 https://github.com/netty/netty/issues/447接下来展开openSelector()详细分析
220 | 221 |private Selector openSelector() {
222 | final Selector selector;
223 | try {
224 | selector = provider.openSelector();
225 | } catch (IOException ignored) {}
226 |
227 | if (DISABLE_KEYSET_OPTIMIZATION) {
228 | return selector;
229 | }
230 |
231 | try {
232 | SelectedSelectionKeySet selectedKeySet = new SelectedSelectionKeySet();
233 |
234 | Class<?> selectorImplClass =
235 | Class.forName("sun.nio.ch.SelectorImpl", false, PlatformDependent.getSystemClassLoader());
236 |
237 | // Ensure the current selector implementation is what we can instrument.
238 | if (!selectorImplClass.isAssignableFrom(selector.getClass())) {
239 | return selector;
240 | }
241 |
242 | Field selectedKeysField = selectorImplClass.getDeclaredField("selectedKeys");
243 | Field publicSelectedKeysField = selectorImplClass.getDeclaredField("publicSelectedKeys");
244 |
245 | selectedKeysField.setAccessible(true);
246 | publicSelectedKeysField.setAccessible(true);
247 |
248 | selectedKeysField.set(selector, selectedKeySet);
249 | publicSelectedKeysField.set(selector, selectedKeySet);
250 |
251 | selectedKeys = selectedKeySet;
252 | logger.trace("Instrumented an optimized java.util.Set into: {}", selector);
253 | } catch (Throwable t) {
254 | selectedKeys = null;
255 | logger.trace("Failed to instrument an optimized java.util.Set into: {}", selector, t);
256 | }
257 |
258 | return selector;
259 | }
260 |
261 | 1.首先openSelector, 这是jdk的api就不详细展开了
262 |
263 | 2.接着DISABLE_KEYSET_OPTIMIZATION是判断是否需要对sun.nio.ch.SelectorImpl中的selectedKeys进行优化, 不做配置的话默认需要优化.
264 |
265 | 3.哪些优化呢?原来SelectorImpl中的selectedKeys和publicSelectedKeys是个HashSet, 新的数据结构是双数组A和B, 初始大小1024, 避免了HashSet的频繁自动扩容,
266 | processSelectedKeys时先使用数组A,再一次processSelectedKeys时调用flip的切换到数组B, 如此反复
267 | 另外我大胆胡说一下我个人对这个优化的理解, 如果对于这个优化只是看到避免了HashSet的自动扩容, 我还是认为这有点小看了"优化狂魔"们, 我们知道HashSet用拉链法解决哈希冲突, 也就是说它的数据结构是数组+链表,
268 | 而我们又知道, 对于selectedKeys, 最重要的操作是遍历全部元素, 但是数组+链表的数据结构对于cpu的 cache line 来说肯定是不够友好的.如果是直接遍历数组的话, cpu会把数组中相邻的元素一次加载到同一个cache line里面(一个cache line的大小一般是64个字节), 所以遍历数组无疑效率更高.
269 | 有另一队优化狂魔是上面论调的支持者及推广者 disruptor https://github.com/LMAX-Exchange/disruptorEventLoop构造方法的部分到此介绍完了, 接下来看看EventLoop怎么启动的, 启动后都做什么
272 | 273 |EventLoop的父类SingleThreadEventExecutor中有一个startExecution()方法, 它最终会调用如下代码:
274 |
275 | private final Runnable asRunnable = new Runnable() {
276 | @Override
277 | public void run() {
278 | updateThread(Thread.currentThread());
279 |
280 | if (firstRun) {
281 | firstRun = false;
282 | updateLastExecutionTime();
283 | }
284 |
285 | try {
286 | SingleThreadEventExecutor.this.run();
287 | } catch (Throwable t) {
288 | cleanupAndTerminate(false);
289 | }
290 | }
291 | };
292 |
293 | 这个Runnable不详细解释了, 它用来实现IO线程在fjp中死循环的自己调度自己, 只需要看 SingleThreadEventExecutor.this.run() 便知道, 接下来要转战EventLoop.run()方法了
294 |
295 | protected void run() {
296 | boolean oldWakenUp = wakenUp.getAndSet(false);
297 | try {
298 | if (hasTasks()) {
299 | selectNow();
300 | } else {
301 | select(oldWakenUp);
302 | if (wakenUp.get()) {
303 | selector.wakeup();
304 | }
305 | }
306 |
307 | cancelledKeys = 0;
308 | needsToSelectAgain = false;
309 | final int ioRatio = this.ioRatio;
310 | if (ioRatio == 100) {
311 | processSelectedKeys();
312 | runAllTasks();
313 | } else {
314 | final long ioStartTime = System.nanoTime();
315 | processSelectedKeys();
316 | final long ioTime = System.nanoTime() - ioStartTime;
317 | runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
318 | }
319 |
320 | if (isShuttingDown()) {
321 | closeAll();
322 | if (confirmShutdown()) {
323 | cleanupAndTerminate(true);
324 | return;
325 | }
326 | }
327 | } catch (Throwable t) {
328 | try {
329 | Thread.sleep(1000);
330 | } catch (InterruptedException ignored) {}
331 | }
332 | scheduleExecution();
333 | }
334 |
335 | 为了避免代码占用篇幅过大, 我去掉了注释部分
336 | 首先强调一下EventLoop执行的任务分为两大类:IO任务和非IO任务.
337 | 1)IO任务比如: OP_ACCEPT、OP_CONNECT、OP_READ、OP_WRITE
338 | 2)非IO任务比如: bind、channelActive等
339 |
340 | 接下来看这个run方法的大致流程:
341 | 1.先调用hasTask()判断是否有非IO任务, 如果有的话, 选择调用非阻塞的selectNow()让select立即返回, 否则以阻塞的方式调用select. 后续再分析select方法, 目前先把run的流程梳理完.
342 |
343 | 2.两类任务执行的时间比例由ioRatio来控制, 你可以通过它来限制非IO任务的执行时间, 默认值是50, 表示允许非IO任务获得和IO任务相同的执行时间, 这个值根据自己的具体场景来设置.
344 |
345 | 3.接着调用processSelectedKeys()处理IO事件, 后边会再详细分析.
346 |
347 | 4.执行完IO任务后就轮到非IO任务了runAllTasks().
348 |
349 | 5.最后scheduleExecution()是自己调度自己进入下一个轮回, 如此反复, 生命不息调度不止, 除非被shutDown了, isShuttingDown()方法就是去检查state是否被标记为ST_SHUTTING_DOWN.接下来分析阻塞select方法都做了什么, selectNow就略过吧
352 | 353 |private void select(boolean oldWakenUp) throws IOException {
354 | Selector selector = this.selector;
355 | try {
356 | int selectCnt = 0;
357 | long currentTimeNanos = System.nanoTime();
358 | long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
359 | for (;;) {
360 | long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
361 | if (timeoutMillis <= 0) {
362 | if (selectCnt == 0) {
363 | selector.selectNow();
364 | selectCnt = 1;
365 | }
366 | break;
367 | }
368 |
369 | int selectedKeys = selector.select(timeoutMillis);
370 | selectCnt ++;
371 |
372 | if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks() || hasScheduledTasks()) {
373 | break;
374 | }
375 | if (Thread.interrupted()) {
376 | selectCnt = 1;
377 | break;
378 | }
379 |
380 | long time = System.nanoTime();
381 | if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
382 | selectCnt = 1;
383 | } else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
384 | selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
385 | rebuildSelector();
386 | selector = this.selector;
387 |
388 | // Select again to populate selectedKeys.
389 | selector.selectNow();
390 | selectCnt = 1;
391 | break;
392 | }
393 | currentTimeNanos = time;
394 | }
395 | // ...
396 | } catch (CancelledKeyException ignored) {}
397 | }
398 |
399 | 1.首先执行delayNanos(currentTimeNanos), 这个方法是做什么的呢?
400 | 1)要了解delayNanos我们需要知道每个EventLoop都有一个延迟执行任务的队列(在父类SingleThreadEventExecutor中), 是的现在我们知道EventLoop有2个队列了.
401 | 2)delayNanos就是去这个延迟队列里面瞄一眼是否有非IO任务未执行, 如果没有则返回1秒钟
402 | 3)如果很不幸延迟队列里面有任务, delayNanos的计算结果就等于这个task的deadlineNanos到来之前的这段时间, 也即是说select在这个task按预约到期执行的时候就返回了, 不会耽误这个task.
403 | 4)如果最终计算出来的可以无忧无虑select的时间(selectDeadLineNanos - currentTimeNanos)小于500000L纳秒, 就认为这点时间是干不出啥大事业的, 还是selectNow一下直接返回吧, 以免耽误了延迟队列里预约好的task.
404 | 5)如果大于500000L纳秒, 表示很乐观, 就以1000000L纳秒为时间片, 放肆的去执行阻塞的select了, 阻塞时间就是timeoutMillis(n * 1000000L纳秒时间片).
405 |
406 | 2.阻塞的select返回后,如果遇到以下几种情况则立即返回
407 | a)如果select到了就绪连接(selectedKeys > 0)
408 | b)被用户waken up了
409 | c)任务队列(上面介绍的那个MPSC)来了一个任务
410 | d)延迟队列里面有个预约任务到期需要执行了
411 |
412 | 3.如果上面情况都不满足, 代表select返回0了, 并且还有时间继续愉快的玩耍
413 |
414 | 4.这其中有一个统计select次数的计数器selectCnt, select过多并且都返回0, 默认512就代表过多了, 这表示需要调用rebuildSelector()重建selector了, 为啥呢, 因为nio有个臭名昭著的epoll cpu 100%的bug, 为了规避这个bug, 无奈重建吧. 参考下面链接
415 | http://bugs.java.com/view_bug.do?bug_id=6403933
416 | https://github.com/netty/netty/issues/327
417 |
418 | 5.rebuildSelector的实际工作就是:
419 | 重新打开一个selector, 将原来的那个selector中已注册的所有channel重新注册到新的selector中, 并将老的selectionKey全部cancel掉, 最后将的selector关闭
420 |
421 | 6.重建selector后, 不死心的再selectNow一下select过后, 有了一些就绪的读啊写啊等事件, 就需要processSelectedKeys()登场处理了, 我只分析一下优化了selectedKeys的处理方法processSelectedKeysOptimized(selectedKeys.flip())
424 | 425 |private void processSelectedKeysOptimized(SelectionKey[] selectedKeys) {
426 | for (int i = 0;; i ++) {
427 | final SelectionKey k = selectedKeys[i];
428 | if (k == null) {
429 | break;
430 | }
431 | selectedKeys[i] = null;
432 | final Object a = k.attachment();
433 | if (a instanceof AbstractNioChannel) {
434 | processSelectedKey(k, (AbstractNioChannel) a);
435 | } else {
436 | NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
437 | processSelectedKey(k, task);
438 | }
439 |
440 | if (needsToSelectAgain) {
441 | for (;;) {
442 | if (selectedKeys[i] == null) {
443 | break;
444 | }
445 | selectedKeys[i] = null;
446 | i++;
447 | }
448 |
449 | selectAgain();
450 | selectedKeys = this.selectedKeys.flip();
451 | i = -1;
452 | }
453 | }
454 | }
455 |
456 | 1.第一眼就看到这里要遍历SelectionKey[]了, 上面提到HashSet-->array的优化就是为了这一步.
457 |
458 | 2.每次拿到一个之后SelectionKey立即释放array对这个key的强引用
459 | selectedKeys[i] = null;
460 | 这么做是为了帮助GC, 这个key处理完了就应该被GC回收了, 如果array对这个key继续维持强引用, 在循环处理后续其他key的时候可能要消耗很长时间, 对GC, 还是能帮则帮吧, Doug lea在设计jsr166也就是jdk中juc包下面的代码也有用到过类似小优化.
461 |
462 | 3.凭啥k.attachment()就是AbstractNioChannel呢?后续分析到register会看到如下一行代码:
463 | selectionKey = javaChannel().register(((NioEventLoop) eventLoop().unwrap()).selector, 0, this);
464 | 其中this就是channel咯, 具体情况后续章节再详细说
465 |
466 | 4.接下来拿到channel调用processSelectedKey(), 下面再详细分析
467 |
468 | 5.有的时候需要select again, 比如被cancel的时候needsToSelectAgain被标记为true
469 |
470 | 6.接下来那个for循环中的处理同样是 help gc
471 |
472 | 7. selectAgain()调用的是非阻塞的selectNow(), 然后重置index为-1重新开始新的循环再看processSelectedKey方法:
475 | 476 |private static void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {
477 | final AbstractNioChannel.NioUnsafe unsafe = ch.unsafe();
478 | if (!k.isValid()) {
479 | // close the channel if the key is not valid anymore
480 | unsafe.close(unsafe.voidPromise());
481 | return;
482 | }
483 |
484 | try {
485 | int readyOps = k.readyOps();
486 | // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
487 | // to a spin loop
488 | if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
489 | unsafe.read();
490 | if (!ch.isOpen()) {
491 | // Connection already closed - no need to handle write.
492 | return;
493 | }
494 | }
495 | if ((readyOps & SelectionKey.OP_WRITE) != 0) {
496 | // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to write
497 | ch.unsafe().forceFlush();
498 | }
499 | if ((readyOps & SelectionKey.OP_CONNECT) != 0) {
500 | // remove OP_CONNECT as otherwise Selector.select(..) will always return without blocking
501 | // See https://github.com/netty/netty/issues/924
502 | int ops = k.interestOps();
503 | ops &= ~SelectionKey.OP_CONNECT;
504 | k.interestOps(ops);
505 |
506 | unsafe.finishConnect();
507 | }
508 | } catch (CancelledKeyException ignored) {
509 | unsafe.close(unsafe.voidPromise());
510 | }
511 | }
512 |
513 | 1.终于见到熟悉的NIO处理代码了, 首先netty中每个channel都有一个unsafe,
514 | 1)作为NioSocketChannel它对应的unsafe是NioByteUnsafe
515 | 2)作为NioServerSocketChannel它对应的unsafe是NioMessageUnsafe
516 | 以上两个的区别后续章节再详细解释, 先简要说明下1)跟worker的channel相关, 2)跟boss的serverChannel相关
517 |
518 | 2.接下来就是根据readyOps来dispatch了, 后续都由unsafe来处理, unsafe留着以后章节分析执行完IO任务以后, 轮到非IO任务了
521 | 522 |protected boolean runAllTasks(long timeoutNanos) {
523 | fetchFromScheduledTaskQueue();
524 | Runnable task = pollTask();
525 | if (task == null) {
526 | return false;
527 | }
528 |
529 | final long deadline = ScheduledFutureTask.nanoTime() + timeoutNanos;
530 | long runTasks = 0;
531 | long lastExecutionTime;
532 | for (;;) {
533 | try {
534 | task.run();
535 | } catch (Throwable t) {
536 | logger.warn("A task raised an exception.", t);
537 | }
538 |
539 | runTasks ++;
540 |
541 | // Check timeout every 64 tasks because nanoTime() is relatively expensive.
542 | // XXX: Hard-coded value - will make it configurable if it is really a problem.
543 | if ((runTasks & 0x3F) == 0) {
544 | lastExecutionTime = ScheduledFutureTask.nanoTime();
545 | if (lastExecutionTime >= deadline) {
546 | break;
547 | }
548 | }
549 |
550 | task = pollTask();
551 | if (task == null) {
552 | lastExecutionTime = ScheduledFutureTask.nanoTime();
553 | break;
554 | }
555 | }
556 |
557 | this.lastExecutionTime = lastExecutionTime;
558 | return true;
559 | }
560 |
561 | 1. 先是fetchFromScheduledTaskQueue, 将延迟任务队列中已到期的task拿到非IO任务的队列中,此队列即为上文中提到的MPSC队列.
562 |
563 | 2. task即是从MPSC queue中弹出的任务
564 |
565 | 3. 又是计算一个deadline
566 |
567 | 4. 注意到 0x3F 了吧?转换成10进制就是64-1, 就是每执行64个任务就检查下时间, 如果到了deadline, 就退出, 没办法, IO任务是亲生的, 非IO任务是后妈生的, 资源肯定要先紧IO任务用.
568 | 我们使用netty时也要注意, 不要产生大量耗时的非IO任务, 以免影响了IO任务.