不同的netty版本代码量差距很大,4.1.8版本代码量达到快50万,所以推荐大家阅读4.0版本,同时高版本与低版本核心的一些细节实现各有特点
源码模块
- transport 核心项目: tcp传输上层api的统一封装[包含nio,bio]
- codec: 核心项目[但非本系列重点,对协议有兴趣可以关注]
- buffer: 核心项目[本系列文章重点关注]
- handler: io事件处理的下游流机制设计实现
- transport-native-epoll: transport实现之一,本项目重点
netty类设计
eventloop设计图
- NioEventLoop本身继承SingleThreadEventExecutor
- SingleThreadEventExecutor是一个(单线程处理NioEventLoop事件的)线程封装类
- 4.0是单线程实现,到4.1.8已经变成线程池
- 一个NioEventLoop持有一个Selector,客户端建立连接时,BossEventGroup通过轮询策略获取不同的WorkerEventLoop,注册到不同的selector选择器上
虽然是线程池,但还是单线程处理网卡回调事件,富余线程用于处理加入eventloop队列(taskQueue)中一些任务,提高网络事件处理的吞吐
channel设计图
类名 | 作用 |
---|---|
Channel | nio channel 封装java原生SocketChannel |
Pipeline | nio事件处理管道 |
Context | 管道中的节点 context封装了具体处理handler以及eventExecutor事件执行线程 |
ChannelInitializer | 一个特殊的Handler,处理注册事件:注册时为相关channel.pipeline添加子handler集合 |
Unsafe | nettyChannel与java Channel模型边界,用于处理javachannel读写事件 |
EventLoop | reactor线程模型的实现,除去io事件,内部含有任务队列可以处理普通事件 |
selecor设计图
- 默认实现KQueueSelectorProvider
- 负责构建KQueueSelectorImpl
- KQueueSelectorImpl通过select将触发就绪的selectKey加入[就绪key集合]
- reactor通过查询selectKeys处理就绪key集合
- 前文提过selectKeys.remove作用,这里再次说明,因为KQueueSelectorImpl.doSelect只会追加到selectKeys,不会覆盖,所以eventLoop或者reactor线程处理事件后需要执行selectKeys.remove
- netty通过SelectedSelectionKeySet装饰了原生的SelectionKey集合,将remove操作封装到SelectedSelectionKeySet,开发者无需再手动调用remove,通过装饰者模式自动调用remove
总结
- 本文概述了netty的代码框架结构,重点关注transport和buffer等底层项目
- 简介了常见类,便于下文切入源码分析
- Netty的Channel是对java channel的封装,当eventLoop处理java channel事件时,通过Unsafe读取其数据并交给Netty Channel处理;
- 当Netty channel通过handler写数据时,默认先写入Unsafe的缓冲区,之后在写入java socket
- 需要注意java socket写入网卡依旧还有一层滑动窗口缓冲区