为啥选择 Netty 作为基础通信组件

Posted 2023-04-13

参考技术A 一、什么是Netty
Netty是一个高性能 事件驱动、异步非堵塞的IO(NIO)Java开源框架，Jboss提供，用于建立TCP等底层的连接，基于Netty可以建立高性能的Http服务器，快速开发高性能、高可靠性的网络服务器和客户端程序。支持HTTP、 WebSocket 、Protobuf、 Binary TCP |和UDP，Netty已经被很多高性能项目作为其Socket底层基础，如HornetQ Infinispan Vert.x Play Framework Finangle和 Cassandra。其竞争对手是：Apache MINA和 Grizzly。
也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。
逗快速地和逗简单地并不意味着会让你的最终应用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMTP,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。
二、不选择Java原生NIO编程的原因
首先开发出高质量的NIO程序并不是一件简单的事情，除去NIO固有的复杂性和BUG不谈，作为一个NIO服务端，还需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况，如果你没有足够的NIO编程经验积累，一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是，一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，需要重启服务器，这种非正常停机会带来巨大的损失。
从可维护性角度看，由于NIO采用了异步非阻塞编程模型，而且是一个I/O线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。
现在我们总结一下为什么不建议开发者直接使用JDK的NIO类库进行开发，具体原因如下。
1）跨平台与兼容性：NIO算是底层的APIs需依赖系统的IO APIs。但Java NIO发现在不同系统平台会出现问题。大量测试也耗不少时间；NIO2只支持JDK1.7+，而且没提供DatagramSocket，故NIO2不支持UDP协议。而Netty提供统一接口，同一语句无论在JDK6.X 还是JDK7.X 都可运行，无需关心底层架构功能！
2）JAVA NIO的ByteBuffer构造函数私有，无法扩展。Netty提供了自己的ByteBuffer实现，通过简单APIs对其进行构造、使用和操作，一此解决NIO的一些限制。
3）NIO对缓冲区的聚合与分散操作可能会导致内存泄漏。直到JDK1.7才解决此问题。
4）NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
5）使用JAVA NIO需要具备其他的额外技能做铺垫，例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序。
6）可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题。
7）JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK 1.6版本的update18修复了该问题，但是直到JDK 1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有得到根本性解决。该BUG以及与该BUG相关的问题单可以参见以下链接内容。
异常堆栈如下。
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x0000000750928190> (a sun.nio.ch.Util$2)
- locked <0x00000007509281a8> (a java.util.Collections$ UnmodifiableSet)
- locked <0x0000000750946098> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)
由于上述原因，在大多数场景下，不建议大家直接使用JDK的NIO类库，除非你精通NIO编程或者有特殊的需求。在绝大多数的业务场景中，我们可以使用NIO框架Netty来进行NIO编程，它既可以作为客户端也可以作为服务端，同时支持UDP和异步文件传输，功能非常强大。

Netty优雅退出机制和原理

“

在实际项目中，Netty作为高性能的异步NIO通信框架，往往用作基础通信框架负责各种协议的接入、解析和调度等，当应用进程优雅退出时，作为通信框架的Netty也需要优雅退出。为什么？怎么做？

老司机简介

李林锋，2007年毕业于东北大学，2008年进入华为公司从事电信软件的设计和开发工作，有多年Java NIO、平台中间件设计和开发经验，精通Netty、Mina、分布式服务框架等,《Netty权威指南》、《分布式服务框架原理与实践》作者。目前从事云平台相关的架构和设计工作。

进程的优雅退出

1、Kill -9 PID带来的问题

在Linux上通常会通过kill -9 pid的方式强制将某个进程杀掉，这种方式简单高效，因此很多程序的停止脚本经常会选择使用kill -9 pid的方式。

无论是Linux的Kill -9 pid还是windows的taskkill /f /pid强制进程退出,都会带来一些副作用：对应用软件而言其效果等同于突然掉电，可能会导致如下一些问题：

1. 缓存中的数据尚未持久化到磁盘中，导致数据丢失；

2. 正在进行文件的write操作，没有更新完成，突然退出，导致文件损坏；

3. 线程的消息队列中尚有接收到的请求消息还没来得及处理，导致请求消息丢失；

4. 数据库操作已经完成，例如账户余额更新，准备返回应答消息给客户端时，消息尚在通信线程的发送队列中排队等待发送，进程强制退出导致应答消息没有返回给客户端，客户端发起超时重试，会带来重复更新问题；

5. 其它问题等...

2、JAVA优雅退出

Java的优雅停机通常通过注册JDK的ShutdownHook来实现，当系统接收到退出指令后，首先标记系统处于退出状态，不再接收新的消息，然后将积压的消息处理完，最后调用资源回收接口将资源销毁，最后各线程退出执行。

通常优雅退出需要有超时控制机制，例如30S，如果到达超时时间仍然没有完成退出前的资源回收等操作，则由停机脚本直接调用kill -9 pid，强制退出。

如何实现Netty的优雅退出

要实现Netty的优雅退出，首先需要了解通用Java进程的优雅退出如何实现。下面我们先讲解下优雅退出的实现原理，并结合实际代码进行讲解。最后看下如何实现Netty的优雅退出。

1、信号简介

信号是在软件层次上对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的，它是进程间一种异步通信的机制。以Linux的kill命令为例，kill -s SIGKILL pid (即kill -9 pid) 立即杀死指定pid的进程，SIGKILL就是发送给pid进程的信号。

信号具有平台相关性，Linux平台支持的一些终止进程信号如下所示：

信号名称	用途
SIGKILL	终止进程，强制杀死进程
SIGTERM	终止进程，软件终止信号
SIGTSTP	停止进程，终端来的停止信号
SIGPROF	终止进程，统计分布图用计时器到时
SIGUSR1	终止进程，用户定义信号1
SIGUSR2	终止进程，用户定义信号2
SIGINT	终止进程，中断进程
SIGQUIT	建立CORE文件终止进程，并且生成core文件

Windows平台存在一些差异，它的一些信号举例如下：SIGINT（Ctrl+C中断）、SIGILL、SIGTERM （kill发出的软件终止）、SIGBREAK （Ctrl+Break中断）。

信号选择：为了不干扰正常信号的运作，又能模拟Java异步通知，在Linux上我们需要先选定一种特殊的信号。通过查看信号列表上的描述，发现 SIGUSR1 和 SIGUSR2 是允许用户自定义的信号,我们可以选择SIGUSR2，为了测试方便，在Windows上我们可以选择SIGINT。

2、Java程序的优雅退出

首先看下通用的Java进程优雅退出的流程图：

第一步，应用进程启动的时候，初始化Signal实例，它的代码示例如下：

Signal sig = new Signal(getOSSignalType());

其中Signal构造函数的参数为String字符串，也就是2.1.1小节中介绍的信号量名称。

第二步，根据操作系统的名称来获取对应的信号名称，代码如下：

private String getOSSignalType()   {       return System.getProperties().getProperty("os.name"). toLowerCase().startsWith("win") ? "INT" : "USR2";    }

判断是否是windows操作系统，如果是则选择SIGINT，接收Ctrl+C中断的指令；否则选择USR2信号，接收SIGUSR2（等价于kill -12 pid）指令。

第三步，将实例化之后的SignalHandler注册到JDK的Signal，一旦Java进程接收到kill -12 或者 Ctrl+C则回调handle接口，代码示例如下：

Signal.handle(sig, shutdownHandler);

其中shutdownHandler实现了SignalHandler接口的handle(Signal sgin)方法，代码示例如下：

第四步，在接收到信号回调的handle接口中，初始化JDK的ShutdownHook线程，并将其注册到Runtime中，示例代码如下：

private void invokeShutdownHook() { Thread t = new Thread(new ShutdownHook(), "ShutdownHook-Thread"); Runtime.getRuntime().addShutdownHook(t); }

第五步，接收到进程退出信号后，在回调的handle接口中执行虚拟机的退出操作，示例代码如下：

Runtime.getRuntime().exit(0);

虚拟机退出时，底层会自动检测用户是否注册了ShutdownHook任务，如果有，则会自动将ShutdownHook线程拉起，执行它的Run方法，用户只需要在ShutdownHook中执行资源释放操作即可，示例代码如下：

class ShutdownHook implements Runnable { @Override public void run() { System.out.println("ShutdownHook execute start..."); System.out.print("Netty NioEventLoopGroup shutdownGracefully..."); try { TimeUnit.SECONDS.sleep(10);//模拟应用进程退出前的处理操作 } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("ShutdownHook execute end..."); System.out.println("Sytem shutdown over, the cost time is 10000MS"); } }

下面我们在Windows环境中对通用的Java优雅退出程序进行测试，打开CMD控制台，拉起待测试程序，如下所示：

启动进程：

查看线程信息，发现注册的ShutdownHook线程没有启动，符合预期：

在控制台执行Ctrl+C，使进程退出，示例如下：

如上图所示，我们定义的ShutdownHook线程在JVM退出时被执行，作为测试程序，它休眠10S之后退出，控制台打印的相关信息如下：

下面我们总结下通用的Java程序优雅退出的技术要点：

3、Netty的优雅退出

在实际项目中，Netty作为高性能的异步NIO通信框架，往往用作基础通信框架负责各种协议的接入、解析和调度等，例如在RPC和分布式服务框架中，往往会使用Netty作为内部私有协议的基础通信框架。

当应用进程优雅退出时，作为通信框架的Netty也需要优雅退出，主要原因如下：

1. 尽快的释放NIO线程、句柄等资源；

2. 如果使用flush做批量消息发送，需要将积攒在发送队列中的待发送消息发送完成；

3. 正在write或者read的消息，需要继续处理；

4. 设置在NioEventLoop线程调度器中的定时任务，需要执行或者清理。

下面我们看下Netty优雅退出涉及的主要操作和资源对象：

Netty的优雅退出总结起来有三大步操作：

1. 把NIO线程的状态位设置成ST_SHUTTING_DOWN状态，不再处理新的消息（不允许再对外发送消息）；

2. 退出前的预处理操作：把发送队列中尚未发送或者正在发送的消息发送完、把已经到期或者在退出超时之前到期的定时任务执行完成、把用户注册到NIO线程的退出Hook任务执行完成；

3. 资源的释放操作：所有Channel的释放、多路复用器的去注册和关闭、所有队列和定时任务的清空取消，最后是NIO线程的退出。

下面我们具体看下如何实现Netty的优雅退出：

Netty优雅退出的接口和总入口在EventLoopGroup，调用它的shutdownGracefully方法即可，相关代码如下：

bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully();

除了无参的shutdownGracefully方法，还可以指定退出的超时时间和周期，相关接口定义如下：

EventLoopGroup的shutdownGracefully工作原理下个章节做详细讲解，结合Java通用的优雅退出机制，即可实现Netty的优雅退出，相关伪代码如下：

//统一定义JVM退出事件，并将JVM退出事件作为主题对进程内部发布 //所有需要优雅退出的消费者订阅JVM退出事件主题 //监听JVM退出的ShutdownHook被启动之后，发布JVM退出事件 //消费者监听到JVM退出事件，开始执行自身的优雅退出 //如果所有的非守护线程都成功完成优雅退出，进程主动退出 //如果到了退出的超时时间仍然没正常退出，则由停机脚本通过kill -9 pid强杀进程，强制退出

总结一下：JVM的ShutdownHook被触发之后，调用所有EventLoopGroup实例的shutdownGracefully方法进行优雅退出。由于Netty自身对优雅退出有较完善的支持，所以实现起来相对比较简单。

4、 一些误区

在实际工作中，由于对优雅退出和资源释放的原理不太清楚，或者对Netty的接口不太了解，很容易把优雅退出和资源释放混淆，导致出现各种问题。

如下案例：本意是想把某个Channel关闭，但是却调用了Channel关联的EventLoop的shutdownGracefully，导致把EventLoop线程和注册在该线程持有的多路复用器上所有的Channel都关闭了，错误代码如下所示：

ctx.channel().eventLoop().shutdownGracefully();

正确的做法如下所示：调用channel的close方法，关闭链路，释放与该Channel相关的资源：

ctx.channel().close();

除非是整个进程优雅退出，一般情况下不会调用EventLoopGroup和EventLoop的shutdownGracefully方法，更多的是链路channel的关闭和资源释放。

Netty优雅退出原理分析

Netty优雅退出涉及到线程组、线程、链路、定时任务等，底层实现细节非常复杂，下面我们就层层分解，通过源码来剖析它的实现原理。

1、NioEventLoopGroup

NioEventLoopGroup实际是NioEventLoop的线程组，它的优雅退出比较简单，直接遍历EventLoop数组，循环调用它们的shutdownGracefully方法，源码如下：

2、NioEventLoop

调用NioEventLoop的shutdownGracefully方法，首先就是要修改线程状态为正在关闭状态，它的实现在父类SingleThreadEventExecutor中，它们的继承关系如下：

SingleThreadEventExecutor的shutdownGracefully代码比较简单，就是修改线程的状态位，需要注意的是修改时需要对并发调用做判断，如果是由NioEventLoop自身调用，则不需要加锁，否则需要加锁，代码如下：

解释下为什么要加锁，因为shutdownGracefully是public的方法，任何能够获取到NioEventLoop的代码都可以调用它，在Netty中，业务代码通常不需要直接获取NioEventLoop并操作它，但是Netty对NioEventLoop做了比较厚的封装，它不仅仅只能读写消息，还能够执行定时任务，并作为线程池执行用户自定义Task。因此在Channel中将获取NioEventLoop的方法开放了出来，这就意味着用户只要能够获取到Channel，理论上就会存在并发执行shutdownGracefully的可能，因此在优雅退出的时候做了并发保护。

完成状态修改之后，剩下的操作主要在NioEventLoop中进行，代码如下：

我们继续看下closeAll的实现，它的原理是把注册在selector上的所有Channel都关闭，但是有些Channel正在发送消息，暂时还不能关，需要稍后再执行，核心代码如下：

循环调用Channel Unsafe的close方法，下面我们跳转到Unsafe中，对close方法进行分析。

3、AbstractUnsafe

AbstractUnsafe的close方法主要做了如下几件事：

1．判断当前该链路是否有消息正在发送，如果有则将关闭操作封装成Task放到eventLoop中稍后再执行：

2．将发送队列清空，不再允许发送新的消息：

3．调用SocketChannel的close方法，关闭链路：

4．调用pipeline的fireChannelInactive，触发链路关闭通知事件：

5．最后是调用deregister，从多路复用器上取消SelectionKey：

至此，优雅退出流程已经完成，这是否意味着NioEventLoop线程可以退出了，其实并非如此。

在此处，只是做了Channel的关闭和从Selector上的去注册，总结如下：

1. 通过inFlush0来判断当前是否正在发送消息，如果是，则不执行Channel关闭动作，放入NIO线程的任务队列中稍后再执行close()操作；

2. 因为已经不允许新的发送消息加入，一旦发送操作完成，就执行链路关闭、触发链路关闭事件和从Selector上取消注册操作。

之前已经说了，NioEventLoop除了I/O读写之外，还兼具定时任务执行、关闭ShutdownHook的执行等，如果此时有到期的定时任务，即使Chanel已经关闭，但是仍然需要继续执行，线程不能退出。下面我们具体分析下TaskQueue的处理流程。

4、TaskQueue

NioEventLoop执行完closeAll（）操作之后，需要调用confirmShutdown看是否真的能够退出，它的处理逻辑如下：

1．执行TaskQueue中排队的Task，代码如下：

2．执行注册到NioEventLoop中的ShutdownHook，代码如下：

3．判断是否到达优雅退出的指定超时时间，如果达到或者过了超时时间，则立即退出，代码如下：

4．如果没到达指定的超时时间，暂时不退出，每隔100MS检测下是否有新的任务加入，有则继续执行：

在confirmShutdown方法中，夹杂了一些对已经废弃的shutdown（）方法的处理，例如：

调用新的shutdownGracefully系列方法，该判断条件是永远都不会成立的，因此对于已经废弃的shutdown相关的处理逻辑，不再详细分析。

到此为止，confirmShutdown方法讲解完毕，confirmShutdown返回true，则NioEventLoop线程正式退出，Netty的优雅退出完成，代码如下：

5、疑问解答

runAllTasks重复执行问题

在NioEventLoop的run方法中，已经调用了runAllTasks方法，为何紧随其后，在confirmShutdown中有继续调用runAllTasks方法呢，疑问代码如下：

原因主要有两个：

1. 为了防止定时任务Task或者用户自定义的线程Task的执行过多占用NioEventLoop线程的调度资源，Netty对NioEventLoop线程I/O操作和非I/O操作时间做了比例限制，即限制非I/O操作的执行时间，如上图红框中代码所示。有了执行时间限制，因此可能会导致已经到期的定时任务、普通任务没有执行完，需要等待下次Selector轮询继续执行。在线程退出之前，需要对本该执行但是没有执行完成的Task进行扫尾处理，所以在confirmShutdown中再次调用了runAllTasks方法；

2. 在调用runAllTasks方法之后，执行confirmShutdown之前，用户向NioEventLoop中添加了新的普通任务或者定时任务，因此需要在退出之前再次遍历并处理一遍Task Queue。

优雅退出是否能够保证所有在通信线程排队的消息全部发送出去

实际是无法保证的，它只能保证如果现在正在发送消息过程中，调用了优雅退出方法，此时不会关闭链路，继续发送，如果发送操作完成，无论是否还有消息尚未发送出去，在下一轮Selector的轮询中，链路将会关闭，没有发送完成的消息将会被丢弃，甚至是半包消息。它的处理原理图如下：

它的原理比较复杂，现对主要逻辑处理进行解读：

1. 调用优雅退出之后，是否关闭链路，判断标准是inFlush0是否为true，如果为False，则会执行链路关闭操作；

2. 如果用户是类似批量发送，例如每达到N条或者定时触发flush操作，则在此期间调用优雅退出方法，inFlush0为False，链路关闭，积压的待发送消息会被丢弃掉；

3. 如果优雅退出时链路正好在发送消息过程中，则它不会立即退出，等待发送完成之后，下次Selector轮询的时候才退出。在这种场景下，又有两种可能的场景：

场景A：如果一次把积压的消息全部发送完，没有发生写半包，则不会发生消息丢失；

场景B：如果一次没有把消息发送完成，此时Netty会监听写事件，触发Selector的下一次轮询并发送消息，代码如下：

Selector轮询时，首先处理读写事件，然后再处理定时任务和普通任务，因此在链路关闭之前，还有最后一次继续发送的机会，代码如下：

如果非常不幸，再次发送仍然没有把积压的消息全部发送完毕，再次发生了写半包，那无论是否有积压消息，执行AbstractUnsafe.close的Task还是会把链路给关闭掉，原因是只要完成一次消息发送操作，Netty就会把inFlush0置为false，代码如下：

链路关闭之后，所有尚未发送的消息都将被丢弃。

可能有些读者会有疑问，如果在第二次发送之后，执行AbstractUnsafe.close之前，业务正好又调用了flush操作，inFlush0是否会被修改成True呢？这个是不可能的，因为从Netty 4.X之后线程模型发生了变更，flush操作不是由用户线程执行，而是由Channel对应的NioEventLoop线程执行，所以在两者之间不会发生inFlush0被修改的情况。

Netty 4.X之后的线程模型如下所示：

另外，由于优雅退出有超时时间，如果在超时时间内没有完成积压消息的发送，也会发生消息丢弃的情况。

对于上述场景，需要应用层来保证相关的可靠性，或者对Netty的优雅退出机制进行优化。

• InfoQ大咖说直播预告：

▽

延展阅读（点击标题）：

• 
  

• 
  

---

本文系InfoQ原创首发，未经授权谢绝转载。