type
status
date
slug
summary
tags
category
icon
password
原生 NIO 存在的问题
NIO的类库和API繁杂,使用麻烦:需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
- 需要具备其他的额外技能:要熟悉
Java多线程编程,因为NIO编程涉及到Reactor模式,你必须对多线程和网络编程非常熟悉,才能编写出高质量的NIO程序。
- 开发工作量和难度都非常大:例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常流的处理等等。
JDK NIO的Bug:例如臭名昭著的Epoll Bug,它会导致Selector空轮询,最终导致CPU100%。直到JDK1.7版本该问题仍旧存在,没有被根本解决。
Netty 官网说明
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

Netty 的优点
Netty 对 JDK 自带的 NIO 的 API 进行了封装,解决了上述问题。- 设计优雅:适用于各种传输类型的统一
API阻塞和非阻塞Socket;基于灵活且可扩展的事件模型,可以清晰地分离关注点;高度可定制的线程模型-单线程,一个或多个线程池。
- 使用方便:详细记录的
Javadoc,用户指南和示例;没有其他依赖项,JDK5(Netty3.x)或6(Netty4.x)就足够了。
- 高性能、吞吐量更高:延迟更低;减少资源消耗;最小化不必要的内存复制。
- 安全:完整的
SSL/TLS和StartTLS支持。
- 社区活跃、不断更新:社区活跃,版本迭代周期短,发现的
Bug可以被及时修复,同时,更多的新功能会被加入。
Netty 版本说明
Netty版本分为Netty 3.x和Netty 4.x、Netty 5.x
- 因为
Netty 5出现重大bug,已经被官网废弃了,目前推荐使用的是Netty 4.x的稳定版本
- 目前在官网可下载的版本
Netty 3.x、Netty 4.0.x和Netty 4.1.x
- 在本套课程中,我们讲解
Netty4.1.x版本
Netty下载地址:https://bintray.com/netty/downloads/netty/
Netty 高性能架构设计
线程模型基本介绍
- 不同的线程模式,对程序的性能有很大影响,为了搞清
Netty线程模式,我们来系统的讲解下各个线程模式,最后看看Netty线程模型有什么优越性。
- 目前存在的线程模型有:传统阻塞
I/O服务模型 和Reactor模式
- 根据
- 单
Reactor单线程; - 单
Reactor多线程; - 主从
Reactor多线程
的数量和处理资源池线程的数量不同,有
种典型的实现
Netty线程模式(Netty主要基于主从Reactor多线程模型做了一定的改进,其中主从Reactor多线程模型有多个Reactor)
传统阻塞 I/O 服务模型
工作原理图
- 黄色的框表示对象,蓝色的框表示线程
- 白色的框表示方法(
API)
模型特点
- 采用阻塞
IO模式获取输入的数据
- 每个连接都需要独立的线程完成数据的输入,业务处理,数据返回
问题分析
- 当并发数很大,就会创建大量的线程,占用很大系统资源
- 连接创建后,如果当前线程暂时没有数据可读,该线程会阻塞在 Handler对象中的
read操作,导致上面的处理线程资源浪费

Reactor 模式
针对传统阻塞 I/O 服务模型的 2 个缺点,解决方案:
基于
I/O 复用模型:多个连接共用一个阻塞对象ServiceHandler,应用程序只需要在一个阻塞对象等待,无需阻塞等待所有连接。当某个连接有新的数据可以处理时,操作系统通知应用程序,线程从阻塞状态返回,开始进行业务处理。Reactor 在不同书中的叫法:- 反应器模式
- 分发者模式(Dispatcher)
- 通知者模式(notifier)
- 基于线程池复用线程资源:不必再为每个连接创建线程,将连接完成后的业务处理任务分配给线程进行处理,一个线程可以处理多个连接的业务。(解决了当并发数很大时,会创建大量线程,占用很大系统资源)
- 基于
I/O复用模型:多个客户端进行连接,先把连接请求给ServiceHandler。多个连接共用一个阻塞对象ServiceHandler。假设,当C1连接没有数据要处理时,C1客户端只需要阻塞于ServiceHandler,C1之前的处理线程便可以处理其他有数据的连接,不会造成线程资源的浪费。当C1连接再次有数据时,ServiceHandler根据线程池的空闲状态,将请求分发给空闲的线程来处理C1连接的任务。(解决了线程资源浪费的那个问题)

I/O 复用结合线程池,就是 Reactor 模式基本设计思想,如图

对上图说明:
Reactor模式,通过一个或多个输入同时传递给服务处理器(ServiceHandler)的模式(基于事件驱动)
- 服务器端程序处理传入的多个请求,并将它们同步分派到相应的处理线程,因此
Reactor模式也叫Dispatcher模式
Reactor模式使用IO复用监听事件,收到事件后,分发给某个线程(进程),这点就是网络服务器高并发处理关键
原先有多个Handler阻塞,现在只用一个ServiceHandler阻塞
Reactor 模式中核心组成
Reactor(也就是那个ServiceHandler):Reactor在一个单独的线程中运行,负责监听和分发事件,分发给适当的处理线程来对IO事件做出反应。它就像公司的电话接线员,它接听来自客户的电话并将线路转移到适当的联系人;
Handlers(处理线程EventHandler):处理线程执行I/O事件要完成的实际事件,类似于客户想要与之交谈的公司中的实际官员。Reactor通过调度适当的处理线程来响应I/O事件,处理程序执行非阻塞操作。
Reactor 模式分类
根据
Reactor 的数量和处理资源池线程的数量不同,有 3 种典型的实现- 单
Reactor单线程
- 单
Reactor多线程
- 主从
Reactor多线程
单 Reactor 单线程
原理图,并使用
NIO 群聊系统验证
方案说明
Select是前面I/O复用模型介绍的标准网络编程API,可以实现应用程序通过一个阻塞对象监听多路连接请求
Reactor对象通过Select监控客户端请求事件,收到事件后通过Dispatch进行分发
- 如果是建立连接请求事件,则由
Acceptor通过Accept处理连接请求,然后创建一个Handler对象处理连接完成后的后续业务处理
- 如果不是建立连接事件,则
Reactor会分发调用连接对应的Handler来响应
Handler会完成Read→ 业务处理 →Send的完整业务流程
结合实例:服务器端用一个线程通过多路复用搞定所有的
IO 操作(包括连接,读、写等),编码简单,清晰明了,但是如果客户端连接数量较多,将无法支撑,前面的 NIO 案例就属于这种模型。方案优缺点分析
- 优点:模型简单,没有多线程、进程通信、竞争的问题,全部都在一个线程中完成
- 缺点:性能问题,只有一个线程,无法完全发挥多核
CPU的性能。Handler在处理某个连接上的业务时,整个进程无法处理其他连接事件,很容易导致性能瓶颈
- 缺点:可靠性问题,线程意外终止,或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障
- 使用场景:客户端的数量有限,业务处理非常快速,比如
Redis在业务处理的时间复杂度O(1)的情况
单 Reactor 多线程
方案说明

Reactor对象通过Select监控客户端请求事件,收到事件后,通过Dispatch进行分发
- 如果是建立连接请求,则由
Acceptor通过accept处理连接请求,然后创建一个Handler对象处理完成连接后的各种事件
- 如果不是连接请求,则由
Reactor分发调用连接对应的handler来处理(也就是说连接已经建立,后续客户端再来请求,那基本就是数据请求了,直接调用之前为这个连接创建好的handler来处理)
handler只负责响应事件,不做具体的业务处理(这样不会使handler阻塞太久),通过read读取数据后,会分发给后面的worker线程池的某个线程处理业务。【业务处理是最费时的,所以将业务处理交给线程池去执行】
worker线程池会分配独立线程完成真正的业务,并将结果返回给handler
handler收到响应后,通过send将结果返回给client
方案优缺点分析
- 优点:可以充分的利用多核
cpu的处理能力
- 缺点:多线程数据共享和访问比较复杂。
Reactor承担所有的事件的监听和响应,它是单线程运行,在高并发场景容易出现性能瓶颈。也就是说Reactor主线程承担了过多的事
主从 Reactor 多线程
工作原理图
针对单
Reactor 多线程模型中,Reactor 在单线程中运行,高并发场景下容易成为性能瓶颈,可以让 Reactor 在多线程中运行

SubReactor是可以有多个的,如果只有一个SubReactor的话那和单 Reactor 多线程就没什么区别了。
Reactor主线程MainReactor对象通过select监听连接事件,收到事件后,通过Acceptor处理连接事件
- 当
Acceptor处理连接事件后,MainReactor将连接分配给SubReactor
subreactor将连接加入到连接队列进行监听,并创建handler进行各种事件处理
- 当有新事件发生时,
subreactor就会调用对应的handler处理
handler通过read读取数据,分发给后面的worker线程处理
worker线程池分配独立的worker线程进行业务处理,并返回结果
handler收到响应的结果后,再通过send将结果返回给client
Reactor主线程可以对应多个Reactor子线程,即MainRecator可以关联多个SubReactor
Scalable IO in Java 对 Multiple Reactors 的原理图解

方案优缺点说明
- 优点:父线程与子线程的数据交互简单职责明确,父线程只需要接收新连接,子线程完成后续的业务处理。
- 优点:父线程与子线程的数据交互简单,
Reactor主线程只需要把新连接传给子线程,子线程无需返回数据。
- 缺点:编程复杂度较高
结合实例:这种模型在许多项目中广泛使用,包括
Nginx 主从 Reactor 多进程模型,Memcached 主从多线程,Netty 主从多线程模型的支持Reactor 模式小结
3 种模式用生活案例来理解
- 单
Reactor单线程,前台接待员和服务员是同一个人,全程为顾客服
- 单
Reactor多线程,1个前台接待员,多个服务员,接待员只负责接待
- 主从
Reactor多线程,多个前台接待员,多个服务生
Reactor 模式具有如下的优点
- 响应快,不必为单个同步时间所阻塞,虽然
Reactor本身依然是同步的(比如你第一个SubReactor阻塞了,我可以调下一个 SubReactor为客户端服务)
- 可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销
- 扩展性好,可以方便的通过增加
Reactor实例个数来充分利用CPU资源
- 复用性好,
Reactor模型本身与具体事件处理逻辑无关,具有很高的复用性
Netty 模型
讲解netty的时候采用的是先写代码体验一下,再细讲里面的原理。前面看不懂的可以先不用纠结,先往后面看,后面基本都会讲清楚
工作原理示意图1 - 简单版

对上图说明
BossGroup线程维护Selector,只关注Accecpt
- 当接收到
Accept事件,获取到对应的SocketChannel,封装成NIOScoketChannel并注册到Worker线程(事件循环),并进行维护
- 当
Worker线程监听到Selector中通道发生自己感兴趣的事件后,就进行处理(就由handler),注意handler已经加入到通道
工作原理示意图2 - 进阶版

BossGroup有点像主Reactor 可以有多个,WorkerGroup则像SubReactor一样可以有多个。工作原理示意图3 - 详细版

Netty抽象出两组线程池 ,BossGroup专门负责接收客户端的连接,WorkerGroup专门负责网络的读写
BossGroup和WorkerGroup类型都是NioEventLoopGroup
NioEventLoopGroup相当于一个事件循环组,这个组中含有多个事件循环,每一个事件循环是NioEventLoop
NioEventLoop表示一个不断循环的执行处理任务的线程,每个NioEventLoop都有一个Selector,用于监听绑定在其上的socket的网络通讯
NioEventLoopGroup可以有多个线程,即可以含有多个NioEventLoop
- 每个
- 轮询
accept事件 - 处理
accept事件,与client建立连接,生成NioScocketChannel,并将其注册到某个workerGroupNIOEventLoop上的Selector - 继续处理任务队列的任务,即
runAllTasks
下面的
循环执行的步骤有
步
- 每个
- 轮询
read,write事件 - 处理
I/O事件,即read,write事件,在对应NioScocketChannel处理 - 处理任务队列的任务,即
runAllTasks
循环执行的步骤
- 每个
WorkerNIOEventLoop处理业务时,会使用pipeline(管道),pipeline中包含了channel(通道),即通过pipeline可以获取到对应通道,管道中维护了很多的处理器。(这个点目前只是简单的讲,后面重点说)
Netty 快速入门实例 - TCP 服务
实例要求:使用
IDEA 创建 Netty 项目Netty服务器在6668端口监听,客户端能发送消息给服务器"hello,服务器~"
- 服务器可以回复消息给客户端"hello,客户端~"
- 目的:对
Netty线程模型有一个初步认识,便于理解Netty模型理论
- 编写服务端
- 编写客户端
- 对
netty程序进行分析,看看netty模型特点 - 说明:创建
Maven项目,并引入Netty包
- 代码如下
NettyServer
NettyServerHandler
NettyClient
NettyClientHandler
任务队列中的 Task 有 3 种典型使用场景
- 用户程序自定义的普通任务【举例说明】
- 用户自定义定时任务
- 非当前
Reactor线程调用Channel的各种方法 例如在推送系统的业务线程里面,根据用户的标识,找到对应的Channel引用,然后调用Write类方法向该用户推送消息,就会进入到这种场景。最终的Write会提交到任务队列中后被异步消费
前两种的代码举例:
方案再说明
Netty抽象出两组线程池,BossGroup专门负责接收客户端连接,WorkerGroup专门负责网络读写操作。
NioEventLoop表示一个不断循环执行处理任务的线程,每个NioEventLoop都有一个Selector,用于监听绑定在其上的socket网络通道。
NioEventLoop内部采用串行化设计,从消息的 读取->解码->处理->编码->发送,始终由IO线程NioEventLoop负责
NioEventLoopGroup下包含多个NioEventLoop
- 每个
NioEventLoop中包含有一个Selector,一个taskQueue
- 每个
NioEventLoop的Selector上可以注册监听多个NioChannel
- 每个
NioChannel只会绑定在唯一的NioEventLoop上
- 每个
NioChannel都绑定有一个自己的ChannelPipeline
异步模型
基本介绍
- 异步的概念和同步相对。当一个异步过程调用发出后,调用者不能立刻得到结果。实际处理这个调用的组件在完成后,通过状态、通知和回调来通知调用者。
Netty中的I/O操作是异步的,包括Bind、Write、Connect等操作会首先简单的返回一个ChannelFuture。
- 调用者并不能立刻获得结果,而是通过
Future-Listener机制,用户可以方便的主动获取或者通过通知机制获得IO操作结果。
Netty的异步模型是建立在future和callback的之上的。callback就是回调。重点说Future,它的核心思想是:假设一个方法fun,计算过程可能非常耗时,等待fun返回显然不合适。那么可以在调用fun的时候,立马返回一个Future,后续可以通过Future去监控方法fun的处理过程(即:Future-Listener机制)
Future 说明
- 表示异步的执行结果,可以通过它提供的方法来检测执行是否完成,比如检索计算等等。
ChannelFuture是一个接口:public interface ChannelFuture extends Future<Void>我们可以添加监听器,当监听的事件发生时,就会通知到监听器。
工作原理示意图
下面第一张图就是管道,中间会经过多个handler


说明:
- 在使用
Netty进行编程时,拦截操作和转换出入站数据只需要您提供callback或利用future即可。这使得链式操作简单、高效,并有利于编写可重用的、通用的代码。
Netty框架的目标就是让你的业务逻辑从网络基础应用编码中分离出来、解脱出来。
Future-Listener 机制
这里看不懂的可以看笔者的并发系列-JUC部分
- 当
Future对象刚刚创建时,处于非完成状态,调用者可以通过返回的ChannelFuture来获取操作执行的状态,注册监听函数来执行完成后的操作。
- 常见有如下操作
- 通过
isDone方法来判断当前操作是否完成; - 通过
isSuccess方法来判断已完成的当前操作是否成功; - 通过
getCause方法来获取已完成的当前操作失败的原因; - 通过
isCancelled方法来判断已完成的当前操作是否被取消; - 通过
addListener方法来注册监听器,当操作已完成(isDone方法返回完成),将会通知指定的监听器;如果Future对象已完成,则通知指定的监听器
举例说明 演示:绑定端口是异步操作,当绑定操作处理完,将会调用相应的监听器处理逻辑
快速入门实例 - HTTP服务
- 实例要求:使用
IDEA创建Netty项目
Netty服务器在6668端口监听,浏览器发出请求http://localhost:6668/
- 服务器可以回复消息给客户端"Hello!我是服务器5",并对特定请求资源进行过滤。
- 目的:
Netty可以做Http服务开发,并且理解Handler实例和客户端及其请求的关系。
- 看老师代码演示
TestServer
TestServerInitializer
TestServerHandler
Netty 核心模块组件
各种东西看不懂,可以先看第三话,第三话我自认为用通俗的语言讲的还算清楚。
Bootstrap、ServerBootstrap
Bootstrap意思是引导,一个Netty应用通常由一个Bootstrap开始,主要作用是配置整个Netty程序,串联各个组件,Netty中Bootstrap类是客户端程序的启动引导类,ServerBootstrap是服务端启动引导类。
- 常见的方法有
public ServerBootstrap group(EventLoopGroup parentGroup, EventLoopGroup childGroup),该方法用于服务器端,用来设置两个EventLooppublic B group(EventLoopGroup group),该方法用于客户端,用来设置一个EventLooppublic B channel(Class<? extends C> channelClass),该方法用来设置一个服务器端的通道实现public <T> B option(ChannelOption<T> option, T value),用来给ServerChannel添加配置public <T> ServerBootstrap childOption(ChannelOption<T> childOption, T value),用来给接收到的通道添加配置public ServerBootstrap childHandler(ChannelHandler childHandler),该方法用来设置业务处理类(自定义的handler)public ChannelFuture bind(int inetPort),该方法用于服务器端,用来设置占用的端口号public ChannelFuture connect(String inetHost, int inetPort),该方法用于客户端,用来连接服务器端
Future、ChannelFuture
Netty 中所有的 IO 操作都是异步的,不能立刻得知消息是否被正确处理。但是可以过一会等它执行完成或者直接注册一个监听,具体的实现就是通过 Future 和 ChannelFutures,他们可以注册一个监听,当操作执行成功或失败时监听会自动触发注册的监听事件常见的方法有
Channel channel(),返回当前正在进行IO操作的通道
ChannelFuture sync(),等待异步操作执行完毕
Channel
Netty网络通信的组件,能够用于执行网络I/O操作。
- 通过
Channel可获得当前网络连接的通道的状态
- 通过
Channel可获得网络连接的配置参数(例如接收缓冲区大小)
Channel提供异步的网络I/O操作(如建立连接,读写,绑定端口),异步调用意味着任何I/O调用都将立即返回,并且不保证在调用结束时所请求的I/O操作已完成
- 调用立即返回一个
ChannelFuture实例,通过注册监听器到ChannelFuture上,可以I/O操作成功、失败或取消时回调通知调用方
- 支持关联
I/O操作与对应的处理程序
- 不同协议、不同的阻塞类型的连接都有不同的
NioSocketChannel,异步的客户端TCPSocket连接。NioServerSocketChannel,异步的服务器端TCPSocket连接。NioDatagramChannel,异步的UDP连接。NioSctpChannel,异步的客户端Sctp连接。NioSctpServerChannel,异步的Sctp服务器端连接,这些通道涵盖了UDP和TCP网络IO以及文件IO。
类型与之对应,常用的
类型:
Selector
Netty基于Selector对象实现I/O多路复用,通过Selector一个线程可以监听多个连接的Channel事件。
- 当向一个
Selector中注册Channel后,Selector内部的机制就可以自动不断地查询(Select)这些注册的Channel是否有已就绪的I/O事件(例如可读,可写,网络连接完成等),这样程序就可以很简单地使用一个线程高效地管理多个Channel
ChannelHandler 及其实现类
ChannelHandler是一个接口,处理I/O事件或拦截I/O操作,并将其转发到其ChannelPipeline(业务处理链)中的下一个处理程序。
ChannelHandler本身并没有提供很多方法,因为这个接口有许多的方法需要实现,方便使用期间,可以继承它的子类
ChannelHandler及其实现类一览图(后)

- 我们经常需要自定义一个
Handler类去继承ChannelInboundHandlerAdapter,然后通过重写相应方法实现业务逻辑,我们接下来看看一般都需要重写哪些方法

Pipeline 和 ChannelPipeline
ChannelPipeline 是一个重点:ChannelPipeline是一个Handler的集合,它负责处理和拦截inbound或者outbound的事件和操作,相当于一个贯穿Netty的链。(也可以这样理解:ChannelPipeline是保存ChannelHandler的List,用于处理或拦截Channel的入站事件和出站操作)
ChannelPipeline实现了一种高级形式的拦截过滤器模式,使用户可以完全控制事件的处理方式,以及Channel中各个的ChannelHandler如何相互交互
- 在
Netty中每个Channel都有且仅有一个ChannelPipeline与之对应,它们的组成关系如下

- 常用方法
ChannelPipeline addFirst(ChannelHandler... handlers),把一个业务处理类(handler)添加到链中的第一个位置ChannelPipeline addLast(ChannelHandler... handlers),把一个业务处理类(handler)添加到链中的最后一个位置
想要更清楚的了解pipeline,可以对之前的代码进行debug,看一下pipeline里究竟有什么东西。
从head看一下debug

TestServerInitializer和HttpServerCodec这些东西本身也是handler
- 一般来说事件从客户端往服务器走我们称为出站,反之则是入站。
ChannelHandlerContext
- 保存
Channel相关的所有上下文信息,同时关联一个ChannelHandler对象
- 即
ChannelHandlerContext中包含一个具体的事件处理器ChannelHandler,同时ChannelHandlerContext中也绑定了对应的pipeline和Channel的信息,方便对ChannelHandler进行调用。

- 常用方法
ChannelFuture close(),关闭通道
ChannelOutboundInvoker flush(),刷新
ChannelFuture writeAndFlush(Object msg),将数据写到
ChannelPipeline中当前ChannelHandler的下一个ChannelHandler开始处理(出站)

ChannelOption
Netty在创建Channel实例后,一般都需要设置ChannelOption参数。
ChannelOption参数如下:

EventLoopGroup 和其实现类 NioEventLoopGroup
EventLoopGroup是一组EventLoop的抽象,Netty为了更好的利用多核CPU资源,一般会有多个EventLoop同时工作,每个EventLoop维护着一个Selector实例。
EventLoopGroup提供next接口,可以从组里面按照一定规则获取其中一个EventLoop来处理任务。在Netty服务器端编程中,我们一般都需要提供两个EventLoopGroup,例如:BossEventLoopGroup和WorkerEventLoopGroup。
- 通常一个服务端口即一个
ServerSocketChannel对应一个Selector和一个EventLoop线程。BossEventLoop负责接收客户端的连接并将SocketChannel交给WorkerEventLoopGroup来进行IO处理,如下图所示

- 常用方法
public NioEventLoopGroup(),构造方法public Future<?> shutdownGracefully(),断开连接,关闭线程
Unpooled 类
Netty提供一个专门用来操作缓冲区(即Netty的数据容器)的工具类
- 常用方法如下所示

- 举例说明
Unpooled获取Netty的数据容器ByteBuf的基本使用

案例 1
案例 2
Netty 应用实例-群聊系统
实例要求:
- 编写一个
Netty群聊系统,实现服务器端和客户端之间的数据简单通讯(非阻塞)
- 实现多人群聊
- 服务器端:可以监测用户上线,离线,并实现消息转发功能
- 客户端:通过
channel可以无阻塞发送消息给其它所有用户,同时可以接受其它用户发送的消息(有服务器转发得到)
- 目的:进一步理解
Netty非阻塞网络编程机制

代码如下:
NettyGroupChatServer
GroupChatServerHandler
NettyGroupChatClient
NettyGroupChatClientHandler
Netty 心跳检测机制案例
实例要求:
- 编写一个
Netty心跳检测机制案例,当服务器超过3秒没有读时,就提示读空闲
- 当服务器超过
5秒没有写操作时,就提示写空闲
- 实现当服务器超过
7秒没有读或者写操作时,就提示读写空闲
- 代码如下:
HeartBeatServer
HeartBeatHandler
Netty 通过 WebSocket 编程实现服务器和客户端长连接
实例要求:
Http协议是无状态的,浏览器和服务器间的请求响应一次,下一次会重新创建连接。
- 要求:实现基于
WebSocket的长连接的全双工的交互
- 改变
Http协议多次请求的约束,实现长连接了,服务器可以发送消息给浏览器
- 客户端浏览器和服务器端会相互感知,比如服务器关闭了,浏览器会感知,同样浏览器关闭了,服务器会感知
NettyWebSocketHandler
网页客户端
可以看到并不是发一次数据,连接就关闭了,而是可以继续发送。
- 作者:IT小舟
- 链接:https://www.codezhou.top/article/JAVA%E3%80%90Netty%E3%80%91%E7%AC%AC%E4%BA%8C%E8%AE%B2
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。



