netty 源码分析(一)

架构设计

1.核心组件

1.1 Channel

netty 通道顶层接口
在这里插入图片描述

  1. AbstractChannel
    顶层抽象类,内部主要维护面信息
   private final Channel parent;
    private final ChannelId id;
    private final Unsafe unsafe;
    private final DefaultChannelPipeline pipeline;
    private final VoidChannelPromise unsafeVoidPromise = new VoidChannelPromise(this, false);
    private final CloseFuture closeFuture = new CloseFuture(this);
   
    private volatile SocketAddress localAddress;
    private volatile SocketAddress remoteAddress;
    //该channel所绑定的事件循环器
    private volatile EventLoop eventLoop;
    //是否已注册到eventloop
    private volatile boolean registered;
    private boolean closeInitiated;

虽然有众多实现,但下面两为较为核心实现,后面重点分析该两实现
3. NioSocketChannel 表示Nio客户端 Socket连接,内部封装了底层的nio socket
在这里插入图片描述
3. NioServerSocketChannel 表示Nio服务端 Socket ,主要用于接收客户端入处理,内部封装底层的nio ServerSocket
在这里插入图片描述
4. ReflectiveChannelFactory channel创建工厂,客户端或服务端channel都由该工厂通过反射来创建,通道在创建的过程中,就为其创建一个ChannelPipeLine,用于后继管理ChannelHandler

1.2 EventLoopGroup

事件循环组接口
在这里插入图片描述
在这里插入图片描述
上面标记了常用的核心实现

  1. NioEventLoop 从上面继承关系可知该类绑定单个线程
    >在这里插入图片描述
  2. NioEventLoopGroup 从源码可得知一组NioEnventLoop,是一对多的关系
    在这里插入图片描述
1.3 ChannelHandler

通道处理器,设计用于出入站事件流处理,例如,接入事件,读事件,写事件,编解码等

  1. ChannelInboundHandler 继承于ChannelHandler,入站事件处理顶层接口,客户端channle的注册(eventloop),读取channel消息
  2. ChannelOutboundHandler 继承于ChannelHandler,出 站事件处理顶层接口,服务端绑地址端口,客户端连接服务端等操作
  3. ChannelDuplexHandler 集成了出入事件的处理,用于简化应用程序,应用业务处更通常继续这个类去实现
1.4 ChannelHandlerContext

在这里插入图片描述
在这里插入图片描述

  1. AbstractChannelHandlerContext 从该抽象中,可知channelHandlerContext 实质是一个双向链表结构,有两个继承者分别为
  2. DefaultChannelHandlerContext 内部维护了一个ChannelHandler
  3. HeadContext 并没有维护一个ChannelHandler,而是实现了ChannelOutboundHandler,ChannelInboundHandler 接口,其自身就是一个handler,可见其会处理一部分出入站事
  4. TailContext 也没有维护一个ChannelHandler,而是实现了ChannelInboundHandler接口,其自身就是一个handler,可见其专业处理部分入站事件
1.5 ChannelPipeLine

专用于出入事件handler链管理,事件处理链路流向管理,每新建一个channel将为其他创建一个新PipeLine,并将相应的handler

在这里插入图片描述

  1. DefaultChannelPipeline ChannelPipeLine 接口默认实现,创建实例时,默认创建HeadContext,TailContext实例
    在这里插入图片描述
1.6 AbstractBootstrap

抽象启动引导类,具有实现有客户端和服务端
在这里插入图片描述

  1. Bootstrap 客户端启动类
    作用主要服务启动客端socket连接服务端,通常绑定一个EventLoopGroup处理各种出入端事件

  2. ServerBootstrap 服务端启动类
    作用主要服务启动服务端Socket,并开启接受客户端接入,通常绑定两个EventLoopGroup,一个作用于客户端socket接入事件,一个用于处理客户端其它事件,如read或write等事

  3. ServerBootstrapAcceptor 客户端接入处理器
    服务端(ServerBootstrap)初始化是被添加到SeverSocketChannel所在的PipeLine后面

     public void channelRead(ChannelHandlerContext ctx, Object msg) {
           //收到NioSocketChannel接入
            final Channel child = (Channel) msg;
            child.pipeline().addLast(childHandler);
            setChannelOptions(child, childOptions, logger);
            for (Entry<AttributeKey<?>, Object> e: childAttrs) {
                child.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
            }

            try {
                //给刚接入的channel绑定一个eventloop
                childGroup.register(child).addListener(new ChannelFutureListener() {
                    @Override
                    public void operationComplete(ChannelFuture future) throws Exception {
                        if (!future.isSuccess()) {
                            forceClose(child, future.cause());
                        }
                    }
                });
            } catch (Throwable t) {
                forceClose(child, t);
            }
        }

2. 核心组件架构

2.1服务端启动

在这里插入图片描述

2.2 服务端处理其它事件流程

在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Netty5.0 架构剖析和源码解读 作者:李林锋 版权所有 email neu_lilinfeng@ © Netty5.0 架构剖析和源码解读1 1. 概述2 1.1. JAVA 的IO演进2 1.1.1. 传统BIO通信的弊端2 1.1.2. Linux 的网络IO模型简介4 1.1.3. IO复用技术介绍7 1.1.4. JAVA的异步IO8 1.1.5. 业界主流的NIO框架介绍10 2.NIO入门10 2.1. NIO服务端10 2.2. NIO客户端13 3.Netty源码分析16 3.1. 服务端创建16 3.1.1. 服务端启动辅助类ServerBootstrap16 3.1.2. NioServerSocketChannel 的注册21 3.1.3. 新的客户端接入25 3.2. 客户端创建28 3.2.1. 客户端连接辅助类Bootstrap28 3.2.2. 服务端返回ACK应答,客户端连接成功32 3.3. 读操作33 3.3.1. 异步读取消息33 3.4. 写操作39 3.4.1. 异步消息发送39 3.4.2. Flush操作42 4.Netty架构50 4.1. 逻辑架构50 5. 附录51 5.1. 作者简介51 5.2. 使用声明51 1. 概述 1.1.JAVA 的IO演进 1.1.1. 传统BIO通信的弊端 在JDK 1.4推出JAVANIO1.0之前,基于JAVA 的所有Socket通信都采用 BIO 了同步阻塞模式( ),这种一请求一应答的通信模型简化了上层的应用开发, 但是在可靠性和性能方面存在巨大的弊端。所以,在很长一段时间,大型的应 C C++ 用服务器都采用 或者 开发。当并发访问量增大、响应时间延迟变大后, 采用JAVABIO作为服务端的软件只有通过硬件不断的扩容来满足访问量的激 增,它大大增加了企业的成本,随着集群的膨胀,系统的可维护性也面临巨大 的挑战,解决这个问题已经刻不容缓。 首先,我们通过下面这幅图来看下采用BIO 的服务端通信模型:采用BIO 通信模型的 1connect NewThread1 WebBrowse 2connect 2handle(Req) WebBrowse 3connect Acceptor NewThread2 WebBrowse WebBrowse 4connect NewThread3 3sendResponsetopeer NewThread4 图1.1.1-1 BIO通信模型图 服务端,通常由一个独立的Accepto 线程负责监听客户端的连接,接收到客户 端连接之后为客户端连接创建一个新的线程处理请求消息

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值