netty 源码分析 读后感
一: 回忆
1. Boostrap 与 ServerBootStrap 的启动经过
a. connect 做了啥?
connect 先调用 initAndRegister 方法, init Channel 和 register, 其中 init 主要是初始 化 channel 和其对应的 pipeline(仅添加了 ChannelInitializer) , 然后 register 时注册 eventLoop和将 ops=0注册进入selector(为啥是0 我不太懂) 和触发各几个事fireXX , 其中 fireRegistered 时, 触发到ChannelInitializer时, 才将真正在 initChannel 方法中 addLast 加入的 handle 加入其中, 自然, 这只是一种添加多个 handler 的快捷方式
然后是 connet 方法则调用 channel 的 connect 方法, 最后调用 abstractChannel 的实现即 pipeline.connect方法,而 defaultpipeline的实现是 tail.conncet, 此方法会向职责链一路调用invokeConnect 方法, 其他的context 的默认实现和 tail 一样是查找最后一个, 唯有 headContext 是调用 unsafe.connect, 最后调用 nio 的 api connect 并想 selector注册 OP_CONNECT 事件
b.bind 做了啥?
initAndRegister 基本与客户端类似, 但不同的是, 服务端的双 eventLoop 和双 handler 在此实现, 大致是 init 时只添加了boss的 handler 和注册动作, 而 worker 则是通过 遍历selector时处理 ops 为0的事件时调用 unsafe.read 方法最后调用了 accept 方法返回 channel 添加到 messageUnsafe 中的 msg 中, 然后在 一早添加的handler 中实现 channelRead 方法将 channel取出, 然后做添加 childHandler 和 用eventLoop注册事件及注册在 selector 上,实现双 eventLoop
2. 各个事件是何时注册到 selector 上的
ops=0 , 每次 register 都会注册
ops=OP_READ, 没次 register 会触发 channelActive, 然后调用 unsafe.read-> tail.read, 最后在 beginRead 中注册
ops = OP_WRITE, 这个事件用来刷新,即写完后不需要手动刷新, 自动的 flush
ops = OP_ACCEPT , 与 OP_READ 一样, 在 beginRead 中注册
ops = OP_CONNECT , 这个在 connect 方法一路往下, 大概在unsafe 里 注册,无啥用处
梳理一下服务端客户端交互过程
服务端启动, 调用 bind 方法, 正常 bind 后, 进入 channelActive 事件, 注册了 ACCEPT 事件, 然后客户端连接 connect 方法, 服务端进入 ACCEPT 下的 read 方法, 然后里面 doReadMessages 方法中调用了 accept 方法拿到 channel 对象封装成 netty 的 channel并放入 msg 对象中发送到职责链中 , 然后 serverbootstrap 中不同的 init(channel) 方法中加入的handler 起作用, 将客户端的 channel 对象用 workerEventLoop的 selector 注册 进入read 方法 注册 OP_READ, 然后发送消息时又进入那个if分支, 调用 unsafe.read 方法
二: codec
1.论 StringEncoder( 编码器) , StringDecoder( 解码器)是如何工作的?
StringDecoder 实现了 MessageToMessageDecoder, 重写 decode方法, 将 message(byteBuf 类型) 解成 String (toString() ? )类型, 使用 out 添加即可, 然后MessageToMessageDecoder中重写了 channelRead 方法会遍历 out, 调用职责链的其他 channelRead 方法, 而我们具体的业务比如 HttpServer 这样的工作 hanlder 都是加在最后的( addLast) , 所以客户端的数据到服务器, 是先经过解码的
StringEncoder 实现了 MessageToMessageEncoder( 对象到对象编码转换类 ), 然后重写了其中的 encode 方法, 将 String 分解成 byteBuf, 然后和 decode 类似, 将转换好的对象加入 out 即可, 而 write方法也一样来自职责链的传递, 方向与 read 相反, 最后 head.wirte 则调用 unsafe 对象的 write , 但 unsafe 的 write 并未直接写, 而是在所有职责链 write 方法都执行后, 根据 autoFlush 判断, 执行 unsafe的 flush 方法中的 doWrite, 才是真正的写
