从一次netty分享漫谈

上周五，笔者所在的开发小组，组织了一场分享，内容是netty的入门。笔者所在的团队，基本上就是在各条业务线中活蹦乱跳，有经验的看官，到这里已经可以给出分享效果的总体预测：“上次面试完就不记得了”；“好像用过，记不起来”；“这图有点复杂”。。。 所以，今天本博客有了第三篇netty入门

从前言的吐槽，可以感受，分享的效果大概率就是呵呵；绝大部分开发同学上台开讲，多少都会有这味道，why？ 主观臆断原因1：真正有壁垒，有内容的部分，分享的时长不足以完全掰碎讲明白； 主观臆断原因2：开发同学大部分情商偏低，基本上组织文档，以自己能提供啥为导向，不以效果为导向。

笔者倾向的高质量分享： 1 以听众为中心梳理内容、结构；在自洽之余，帮助听众，构建该知识点的知识地图/建立索引； 2 难度和门槛，要和听众能力相对匹配（给一年级上6年纪的，那是学而思） 3 控制篇幅，仅对一两个核心点拆解掰碎

笔者尝试结构化netty相关知识，从是什么，怎么运行，能干啥几个角度看netty

Netty 是由 JBOSS 提供的一个 Java 开源框架，现为 Github上的独立项目。

Netty 是一个 异步的、基于事件驱动 的 网络应用框架，用以快速开发高性能、高可靠性的 网络 IO 程序。相当于简化和流程化了 NIO 的开发过程。

Netty主要针对在 TCP协议下，面向Clients端的高并发应用，或者Peer-to-Peer场景下的 大量数据持续传输 的应用。 Netty本质是一个 NIO框架，适用于 服务器通讯 相关的多种应用场景。

于框架而言，线程模型是重中之重，线程模型图一出，系统如何work则一目了然。

Reactor模式 是一种「事件驱动」模式。

「Reactor线程模型」就是通过 单个线程 使用Java NIO包中的Selector的select()方法，进行监听。当获取到事件(如accept、read等)后，就会分配(dispatch)事件进行相应的事件处理(handle)。

基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象等待，无需阻塞等待所有连接。当某个连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理

基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。 Reactor 模式使用 IO复用 监听事件，收到事件后，分发给某个线程(进程)，这点就是网络服务器高并发处理关键。 Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；

Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

代表选手：redis

Netty 主要基于 主从 Reactors 多线程模型 做了一定的 改进，其中主从 Reactor 多线程模型有多个 Reactor。

1 开发同学通常过于在意自己能输出啥，思路偏向供给；实际工作中，我们更多的是协作，协作必然要在意相关利益方的诉求，即需求侧；两者之间要达到平衡，才能实现最大价值。 2 换个角度看，分享也是一次项目，花费了团队参会者人均1小时，+分享者N个小时的准备时间，要达到该项目的最大价值，组织者需要考虑，如何让参会者所有人的利益最大化（涉众利益）

参考：https://www.51cto.com/article/666816.html 参考：https://lish98.blog.csdn.net/article/details/124232377