netty填坑----论填坑，我是专业的

1、为什么netty服务端启动后又无异常地自动退出？

网站设计制作过程拒绝使用模板建站；使用PHP+MYSQL原生开发可交付网站源代码;符合网站优化排名的后台管理系统；成都网站设计、网站制作收费合理；免费进行网站备案等企业网站建设一条龙服务.我们是一家持续稳定运营了10年的创新互联网站建设公司。

由于代码1处执行完后直接进入2、3，那么netty服务端就会关闭退出。

解决一、直接在代码1后面处加上同步阻塞sync，那么只有服务端正常关闭channel时才会执行下面的语句

解决二、把代码2和3移到operationComplete里面，那么也只有channel关闭时才会让netty的两个线程组关闭

2、netty客户端连接池资源OOM

生产环境用netty作为客户端，为了提高性能，客户端与服务端创建多条链路，同时客户端创建一个TCP连接池。结果业务高峰期OOM

从异常日志和线程资源占用来看，导致内存泄漏的原因是应用创建了大量的EventLoopGroup线程池。这就是一个TCP连接对应一个NIO线程的模式。错误之在就是采用BIO模式来调用NIO通信框架，不仅没优化效果，还发生了OOM。

正确操作是

注意：Bootstrap自身不是线程安全的，但执行Bootstrap的连接操作是串行执行的。connect方法它会创建一个新的NioSocketChannel，并从初始构造的EventLoopGroup中选择一个NioEventLoop线程执行真正的Channel连接操作，与执行Boostrap的线程无关。在同一个Boostrap创建多个客户端连接，EventLoopGroup是共享的，这些连接共用同一个NIO线程组EventLoopGroup，当某个链路发生异常或关闭时，只需要关闭并释放Channel本身即可，不能同时销毁NioEventLoop和所在线程组EventLoopGroup，下方是错误代码 

Bootstrap不是线程安全的，因此在多个线程中并发操作Bootstrap是比较危险而且没有意义。

3、netty居然会产生内存池泄漏问题

在调用ctx.writeAndFlush方法时，当消息发送完成，Netty会主动帮助应用释放内存，内存释放场景如下

(1)如果是堆内存(PooledHeapByteBuf)，则将HeapByteBuffer转换成DirectByteBuffer，并释放PooledHeapByteBuf到内存池。

(2)如果是DirectByteBuffer，则不需要转换，在消息发送完成后，由ChannelOutboundBuffer的remove方法负责释放

为了在实际项目中更好地管理ByteBuf，下面分4种场景说明

（1）基于内存池的请求ByteBuf，这类主要包括PooledDirectByteBuf和PooledHeapByteBuf，它由NioEventLoop线程在处理Channel读操作时分配，需要在业务ChannelInboundHandler处理完请求消息后释放（通常在解码之后），它的释放策略如下：

1. ChannelInboundHandler继承自SimpleChannelInboundHandler，实现它的抽象方法channelRead0，ByteBuf的释放业务不用关心，由SimpleChannelInboundHandler负责释放

2. 在业务ChannelInboundHandler中调用ctx.fireChannelRead(msg)，让请求继续向后执行，直至调用DefaultChannelPipeline的内部类TailContext，由它负责释放请求信息

3. 直接调用在channelRead方法里调用ReferenceCountUtil.release(reqMsg)

（2） 基于非内存池的请求ByteBuf,它也是需要按照内存池的方式释放内存

（3）基于内存池的响应ByteBuf，根据之前的分析，只要调用了writeAndFlush或flush方法，在消息发送完成后都会由Netty框架进行内存释放，业务不需要主动释放内存

（4）基于非内存池的响应ByteBuf，业务不需要主动释放内存

当然非内存池也不一定要手动释放，但最好手动释放。Netty里有4种主力的ByteBuf，其中UnpooledHeapByteBuf底下的byte[]能够依赖JVM GC自然回收；而UnpooledDirectByteBuf底下是DirectByteBuffer，是Java堆外内存，除了等JVM GC，最好也能主动进行回收，否则导致内存不足也产生内存泄露的假象；而PooledHeapByteBuf和PooledDirectByteBuf，则必须要主动将用完的byte[]/ByteBuffer放回池里，否则内存就要爆掉。

对于内存池泄露可以的监控可以配置启动参数

不同参数信息如下： 

1. DISABLED 完全关闭内存泄露检测，并不建议

2. SIMPLE 以1%的抽样率检测是否泄露，默认级别

3. ADVANCED 抽样率同SIMPLE，但显示详细的泄露报告

4. PARANOID 抽样率为100%，显示报告信息同ADVANCED

最后，悄悄告诉你，网上的你些netty入门demo大都存在内存池泄露问题，只不过数据量传输少，可能运行大半年才会出现LEAK，就连《netty权威指南》入门demo也存在这个问题，也许就只是个入门demo,所以不弄得太复杂。什么你不信，你可以在入门demo的TimeClientHandler或TimeServerHandler加上下面这坨代码。

        ByteBuf firstMessage = null;        
        for (int j = 0; j < Integer.MAX_VALUE; j++) {
            firstMessage = Unpooled.buffer(1024);            
            for (int i = 0; i < firstMessage.capacity(); i ++) {
                firstMessage.writeByte((byte) i);
            }
            ctx.writeAndFlush(firstMessage);
        }

 妥妥的

这就是为什么很多人照抄网上的demo仍会出现内存池泄露的原因

4、Netty发送队列积压导致内存泄漏

客户端频繁发送消息可以导致发送队列积压，进而内存增大，响应时间长，CPU占用高。

此时我们可以为客户端设置高低水位机制，防止自身队列消息积压

此外，除了客户端消息队列积压也可能因网络链接处理能力、服务器读取速度小于己方发送速度有关。所以在日常监控中，需要将Netty的链路数、网络读写速度等指标纳入监控系统，发现问题之后需要及时告警。

5、API网关高并发压测性能波动

 服务端转发请求

public void channelRead(ChannelHandlerContext ctx, Object msg) {
        ctx.write(msg);
        char [] req = new char[64 * 1024];
        executorService.execute(()->
        {
            char [] dispatchReq = req;
            //简单处理之后，转发请求消息到后端服务，代码省略
            try
            {
                //模拟业务逻辑处理耗时
                TimeUnit.MICROSECONDS.sleep(100);
            }catch (Exception e)
            {
                e.printStackTrace();
            }
        });
    }

结果发现内存和CPU占用高，同时QPS下降，停止压测一段时间，CPU占用和内存下降，QPS恢复正常。

用MAT分析

得出是线程池的char[]积压，进入老年代，导致频繁full gc。究其原因是，每次都创建64kb的char来存放处理消息，哪怕实际接收消息有 100字节。修改char大小为消息大小，问题得到解决

6、为什么Netty Server端无法收到Client端发来的消息 

原因：在handler里面是直接处理业务信息，导致IO的操作阻塞，无法读取Client端发来的消息

建议将业务操作将由另一个线程处理，而不应放在IO线程里处理

推荐线程的计算公式：

（1） 线程数量=（线程总时间/瓶颈资源时间）*瓶颈资源的线程并行数

（2）QPS=1000/线程总时间*线程数

7、Netty3.x升级到Netty4.x后产生"bug"

1、版本升级后偶现服务端发送给客户端的应答数据被篡改？

netty升级4后，线程模型发生变化，响应消息的编码由NioEventLoop线程异步执行，业务线程返回。这时如果编码操作在修改应答消息的业务逻辑后执行，则运行结果错误，数据被篡改。

2、升级后为什么上下文丢失问题？

Netty4修改了outbound的线程模型，正好影响了业务消息发送时的上下文传递，最终导致业务线程变量丢失

3、升级后没有像官方描述那样性能得到提升，反而下降了？

可将耗时的反序列操作放到业务线程里，而不是ChannelHandler，因为Netty4只有一个NioEventLoop线程来处理这个操作，业务耗时ChannelHandler被I/O线程串行执行，所以执行效率低。Netty3在消息发送线程模型上，充分利用业务线程的并行编码和ChanelHandler的优势，在一个周期T内可以处理N条业务消息。

性能优化建议：适当高大work线程组的线程数（NioEventLoopGroup），分担每个NioEventLoop线程的负载，提升ChannelHandler执行的并发度。同时，将业务上耗时的操作从ChannelHandler移除，放入业务线程池处理。对于不合适转移到业务线程处理的一些耗时逻辑，也可以通过为ChannelHandler绑定线程池的方式提升性能。Netty3的Downstream由业务线程执行，意味着某一时刻有多个业务线程同时操作ChannelHandler，用户需要并发保护。

8、为什么netty自带的业务线程池没有提高性能，netty有bug？

server端使用netty自带的线程池来处理业务

而client端如下

实际结果server端的QPS只有个位数，究其原因是一个tcp连接对应一个channel，一个channel就对应一个DefaultEventExecutor（业务线程） 执行，所以它虽然给channel绑定线程池，但一个channel还是一个业务线程在处理。解决办法是在ChannelHandler里面再创建一个线程池，此时就能利用线程池的并行处理能力。

当然， server端使用netty自带的线程池来处理业务，它的用法是当建立多个tcp连接时，每个连接能对应一个线程来处理ChannelHandler。所以它在多tcp连接时能提高业务的并行处理能力。

Netty提供的业务线程池能降低了锁竞争，提升了系统的并发处理性能。如果使用业务自定义实现的线程池，如果追求更高的性能，就要在消除或减轻锁竞争上下工夫（ThreadPoolExecutor采用的是“一个阻塞队列+N个工作线程”的模型，如果业务线程数比较多，就会形成激烈的锁竞争）

9、发送端和接收端处理速度不均衡怎么办？

可用流量×××方案， 流量×××和流控的最大区别在于，流控会拒绝消息，流量×××不拒绝和丢弃消息，无论接收量多大，它总能以近似恒定的速度下发消息，跟变压器的原理和功能类似。

接收端代码如下：

        // 配置服务端的NIO线程组
        EventLoopGroup bossGroup = new NioEventLoopGroup();
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .option(ChannelOption.SO_BACKLOG, 100)
                    .handler(new LoggingHandler(LogLevel.INFO))
                    .childHandler(new ChannelInitializer() {
                        @Override
                        public void initChannel(SocketChannel ch)
                                throws Exception {
                            ch.pipeline().addLast("Channel Traffic Shaping", new ChannelTrafficShapingHandler(1024 * 1024, 1024 * 1024, 1000));
                            ByteBuf delimiter = Unpooled.copiedBuffer("$_"
                                    .getBytes());
                            ch.pipeline().addLast(
                                    new DelimiterBasedFrameDecoder(2048 * 1024,
                                            delimiter));
                            ch.pipeline().addLast(new StringDecoder());
                            ch.pipeline().addLast(new TrafficShapingServerHandler());
                        }
                    });
            // 绑定端口，同步等待成功
            ChannelFuture f = b.bind(port).sync();
            // 等待服务端监听端口关闭
            f.channel().closeFuture().sync();
        } finally {
            // 优雅退出，释放线程池资源
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }