云服务官网源码 服务端源码_云服务官网源码

前言：

在之前的博文中，本人讲解了 Netty 的 概念、基本使用 以及 各种机制

那么，在本篇博文中，本人将来讲解 Netty 的 服务端 的 核心源码

首先，是 启动流程：

启动流程：


接下来，是 请求处理：

请求处理：


客户端 的 核心源码，和 服务端 的 核心源码 十分类似

本人现在来通过一张图，既 总结服务端源码，也 概括下客户端源码：

总结：

云服务官网源码 服务端源码_启动流程_02

对 客户端源码 感兴趣的的同学，请按照本人上图所示的流程，自行 debug 哦！

可能只看到本篇博文的同学，也想了解 Netty 的 心跳机制 的 源码逻辑

心跳机制：


最后，本人还要来讲解一下，一个很有必要的问题 —— BossGroup线程 问题：

BossGroup 单线程 与 多线程：

问题产生：

相信有部分同学，和本人一样，用了几次 Netty的API，看了部分核心代码 之后，就有了如下误解：

BossGroup线程的大小 在我们设置的时候，如果设置的是 大于1，
那么，在处理客户端请求的时候，就会 默认使用 多个线程 去接收

但是，这是不对的！

为什么说上述的思想是错误的呢？

原理探究：

我们可以思考下：

Netty 再怎么封装，也都是封装了 NIO 的API
所以，作为 服务端 的 同一对ip和port，只能对应 一个线程

因此，不论我们设置的 BossGroup线程 有多大，只要我们只指定了 一对ip和port，
那么，Netty内部 只会启动 一个线程 去 接收客户端连接

那么，如果只指定 一对ip和port，我们是不是就不用设置 大于1 的 BossGroup大小 呢？

参数设置：

  • 既然只使用一个线程为什么要用线程池呢？
    主要是 异常 的情况下，线程die了，可以再创建一个新线程
  • 那什么情况下boss线程池可以使用多个线程呢？
    那就是当ServerBootstrap bind多个端口时。每个端口都有一个线程eventloop accept事件

那么，至此，Netty 的 核心源码解析，到这里就结束了！

云服务官网源码 服务端源码_启动流程_03