转载：RPC入门总结（四）RPC IO基础：Netty原理和使用
转载：对于 Netty ByteBuf 的零拷贝(Zero Copy) 的理解
一、Netty的零拷贝
即所谓的 Zero-copy, 就是在操作数据时, 不需要将数据 buffer 从一个内存区域拷贝到另一个内存区域。 因为少了一次内存的拷贝, 因此 CPU 的效率就得到的提升。
在 OS 层面上的 Zero-copy 通常指避免在 用户态(User-space) 与 内核态(Kernel-space) 之间来回拷贝数据。 例如 Linux 提供的 mmap 系统调用， 它可以将一段用户空间内存映射到内核空间， 当映射成功后, 用户对这段内存区域的修改可以直接反映到内核空间； 同样地， 内核空间对这段区域的修改也直接反映用户空间。 正因为有这样的映射关系， 我们就不需要在 用户态(User-space) 与 内核态(Kernel-space) 之间拷贝数据， 提高了数据传输的效率。
而需要注意的是， Netty 中的 Zero-copy 与上面我们所提到到 OS 层面上的 Zero-copy 不太一样， Netty的 Zero-coyp 完全是在用户态(Java 层面)的， 它的 Zero-copy 的更多的是偏向于优化数据操作 这样的概念。
Netty的“零拷贝”主要体现在如下三个方面：
1) Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
从源码知，ByteBuffer由ChannelConfig分配，而ChannelConfig创建ByteBufAllocator默认使用Direct Buffer，这就避免了读写数据的二次内存拷贝问题，从而实现了读写Socket的零拷贝功能，
2) Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。
1. 通过 CompositeByteBuf 实现零拷贝
假设我们有一份协议数据, 它由头部和消息体组成, 而头部和消息体是分别存放在两个 ByteBuf 中的, 即:
ByteBuf header = ...
ByteBuf body = ...
ByteBuf allBuf = Unpooled.buffer(header.readableBytes() + body.readableBytes());
allBuf.writeBytes(header);
allBuf.writeBytes(body);
ByteBuf header = ...
ByteBuf body = ...
CompositeByteBuf compositeByteBuf = Unpooled.compositeBuffer();
compositeByteBuf.addComponents(true, header, body);public CompositeByteBuf addComponents(boolean increaseWriterIndex, ByteBuf... buffers) {
...
}上面 CompositeByteBuf 代码还以一个地方值得注意的是, 我们调用 addComponents(boolean increaseWriterIndex, ByteBuf... buffers) 来添加两个 ByteBuf, 其中第一个参数是 true, 表示当添加新的 ByteBuf 时, 自动递增 CompositeByteBuf 的 writeIndex。如果我们调用的是
compositeByteBuf.addComponents(header, body);2. 通过 wrap 操作实现零拷贝
例如我们有一个 byte 数组, 我们希望将它转换为一个 ByteBuf 对象, 以便于后续的操作, 那么传统的做法是将此 byte 数组拷贝到 ByteBuf 中, 即：
byte[] bytes = ...
ByteBuf byteBuf = Unpooled.buffer();
byteBuf.writeBytes(bytes);
ByteBuf header = ...
ByteBuf body = ...
ByteBuf allByteBuf = Unpooled.wrappedBuffer(header, body);slice 操作和 wrap 操作刚好相反, Unpooled.wrappedBuffer 可以将多个 ByteBuf 合并为一个, 而 slice 操作可以将一个 ByteBuf 切片 为多个共享一个存储区域的 ByteBuf 对象.
ByteBuf 提供了两个 slice 操作方法:
public ByteBuf slice();
public ByteBuf slice(int index, int length);
ByteBuf byteBuf = ...
ByteBuf header = byteBuf.slice(0, 5);
ByteBuf body = byteBuf.slice(5, 10);3) Netty的文件传输采用了 transferTo方 法，它可以直接 将文件缓冲区的数据发送到目标Channel ，避免了传统通过循环write方式导致的内存拷贝问题。
Netty 中使用 FileRegion 实现文件传输的零拷贝, 不过在底层 FileRegion 是依赖于 Java NIO FileChannel.transfer 的零拷贝功能.
首先我们从最基础的 Java IO 开始吧。 假设我们希望实现一个文件拷贝的功能, 那么使用传统的方式, 我们有如下实现：
public static void copyFile(String srcFile, String destFile) throws Exception {
byte[] temp = new byte[1024];
FileInputStream in = new FileInputStream(srcFile);
FileOutputStream out = new FileOutputStream(destFile);
int length;
while ((length = in.read(temp)) != -1) {
out.write(temp, 0, length);
}
in.close();
out.close();
}下面我们来看一下使用 Java NIO 的 FileChannel 是如何实现零拷贝的：
public static void copyFileWithFileChannel(String srcFileName, String destFileName) throws Exception {
RandomAccessFile srcFile = new RandomAccessFile(srcFileName, "r");
FileChannel srcFileChannel = srcFile.getChannel();
RandomAccessFile destFile = new RandomAccessFile(destFileName, "rw");
FileChannel destFileChannel = destFile.getChannel();
long position = 0;
long count = srcFileChannel.size();
srcFileChannel.transferTo(position, count, destFileChannel);
}有了上面的一些理论知识， 我们来看一下在 Netty 中是怎么使用 FileRegion 来实现零拷贝传输一个文件的：
@Override
public void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
RandomAccessFile raf = null;
long length = -1;
try {
// 1. 通过 RandomAccessFile 打开一个文件.
raf = new RandomAccessFile(msg, "r");
length = raf.length();
} catch (Exception e) {
ctx.writeAndFlush("ERR: " + e.getClass().getSimpleName() + ": " + e.getMessage() + '\n');
return;
} finally {
if (length < 0 && raf != null) {
raf.close();
}
}
ctx.write("OK: " + raf.length() + '\n');
if (ctx.pipeline().get(SslHandler.class) == null) {
// SSL not enabled - can use zero-copy file transfer.
// 2. 调用 raf.getChannel() 获取一个 FileChannel.
// 3. 将 FileChannel 封装成一个 DefaultFileRegion
ctx.write(new DefaultFileRegion(raf.getChannel(), 0, length));
} else {
// SSL enabled - cannot use zero-copy file transfer.
ctx.write(new ChunkedFile(raf));
}
ctx.writeAndFlush("\n");
}可以看到， 第一步是通过 RandomAccessFile 打开一个文件， 然后 Netty 使用了 DefaultFileRegion 来封装一个 FileChannel，当有了 FileRegion 后， 我们就可以直接通过它将文件的内容直接写入 Channel 中， 而不需要像传统的做法: 拷贝文件内容到临时 buffer， 然后再将 buffer 写入 Channel. 通过这样的零拷贝操作， 无疑对传输大文件很有帮助。
二、Netty内存管理
随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。netty 内存管理的高性能主要依赖于两个关键点：内存的池化管理和使用堆外直接内存（Direct Memory）。
1. Netty内存池
Netty4的内存池集大家之精华，参考了各路英雄豪杰的优秀思想，它参考了slab分配，Buddy（伙伴）分配。接触过memcached的应该了解slab分配，它的思路是把内存分割成大小不等的内存块，用户线程请求内存时根据请求的内存大小分配最贴近size的内存块，在减少内存碎片的同时又能很好的避免内存浪费。Buddy分配是在分配的过程中把一些内存块等量分割，回收时合并，尽可能保证系统中有足够大的连续内存。
从内存回收的角度分类Netty中的ByteBuf可分为：
（1）基于对象池的ByteBuf（PoolByteBuf）：PooledByteBuf和它的子类PoolDirectByteBuf、PoolUnsafeDirectByteBuf、PooledHeapByteBuf。它的特点是可以循环利用创建的ByteBuf，提高了内存的使用效率，PoolByteBuf的实现牵涉的数据结构很多，PoolByteBuf首先会申请一大块内存区域PoolArena，PoolArena由多个Chunk组成，而每个Chunk由一个或多个page组成
（2）普通的ByteBuf（UnPoolByteBuf）：UnPoolDirectByteBuf、UnPoolUnsafeDirectByteBuf、UnPoolHeapByteBuf
总结：
在高负载，大并发的情况下对象池的ByteBuf更好，而在一般情况下，可以使用UnPoolByteBuf
2. Netty直接内存
从内存分配角度分类Netty中的ByteBuf可分为：
（1）堆内存字节缓冲区（HeapByteBuf）：UnPoolHeapByteBuf、PooledHeapByteBuf
它的特点是内存的分配和回收都在堆，所以速度很快；缺点就是进行Socket的IO读写，需要把堆内存对应的缓冲区复制到内核Channel中，这内存复制会影响性能
（2）直接内存缓冲区（DirectByteBuf）：UnPoolDirectByteBuf、UnPoolUnsafeDirectByteBuf、PoolDirectByteBuf、PoolUnsafeDirectByteBuf
它的特点是由于内存的分配在非堆（方法区），不需要内存复制，所以IO读取的速度较快，但是内存的分配较慢
总结：
根据两种内存的特点，我们可以知道，IO读写时最好使用DirectByteBuf，而在后端业务消息的解编码最好使用HeapByteBuf
三、Netty的无锁化串行设计理念
在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能的避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。
为了尽可能提升性能，Netty采用了串行无锁化设计，在IO线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。Netty的串行化设计工作原理图如下：
Netty的NioEventLoop读取到消息之后，直接调用ChannelPipeline的fireChannelRead(Object msg)，只要用户不主动切换线程，一直会由NioEventLoop调用到用户的Handler，期间不进行线程切换，这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。
（但是遗憾的是，虽然IO操作可以做到无锁化设计，但是在代码实现时一般在复杂逻辑中要将IO设计与业务逻辑分离，IO操作后使用Runnable封装为任务，使用业务逻辑线程池知行业务，此时需要在串行化的基础上再加线程池，那就是另外层面的事情了，业务的复杂性导致无锁化串行只能是局部设计，最优的设计永远在路上。）
四、Netty业务设计原则
1. 时间可控的简单业务直接在IO线程上处理
如果业务非常简单，执行时间非常短，不需要与外部网元交互、访问数据库和磁盘，不需要等待其它资源，则建议直接在业务ChannelHandler中执行，不需要再启业务的线程或者线程池。避免线程上下文切换，也不存在线程并发问题。2. 复杂和时间不可控业务建议投递到后端业务线程池统一处理
对于此类业务，不建议直接在业务ChannelHandler中启动线程或者线程池处理，建议将不同的业务统一封装成Task，统一投递到后端的业务线程池中进行处理。过多的业务ChannelHandler会带来开发效率和可维护性问题，不要把Netty当作业务容器，对于大多数复杂的业务产品，仍然需要集成或者开发自己的业务容器，做好和Netty的架构分层。
3. 业务线程避免直接操作ChannelHandler
对于ChannelHandler，IO线程和业务线程都可能会操作，因为业务通常是多线程模型，这样就会存在多线程操作ChannelHandler。为了尽量避免多线程并发问题，建议按照Netty自身的做法，通过将操作封装成独立的Task由NioEventLoop统一执行，而不是业务线程直接操作，if (ctx.executor().inEventLoop()) {
try{
doFlush();
} catch {
if (logger.isWarnEnabled) {
logger.warn("Unexpected exception while sending chunks.", e);
}
}
} else {
ctx.executor().execute(new Runnable() {
@Override
public void run() {
try{
doFlush(ctx);
} catch (Exception e) {
...
}
}
})
}五、Netty海量推送服务设计要点
1. 最大句柄数修改
百万长连接接入，首先需要优化的就是Linux内核参数，其中Linux最大文件句柄数是最重要的调优参数之一，默认单进程打开的最大句柄数是1024，通过ulimit -a可以查看相关参数，示例如下：
[root@lilinfeng ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256324
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
......后续输出省略通过vi /etc/security/limits.conf 添加如下配置参数：修改之后保存，注销当前用户，重新登录，通过ulimit -a 查看修改的状态是否生效。
* soft nofile 1000000
* hard nofile 10000002. 当心CLOSE_WAIT
在百万长连接的推送系统中，服务端需要能够正确处理这些网络异常，设计要点如下：
1. 客户端的重连间隔需要合理设置，防止连接过于频繁导致的连接失败（例如端口还没有被释放）；
2. 客户端重复登陆拒绝机制；
3. 服务端正确处理I/O异常和解码异常等，防止句柄泄露。
4. 最后特别需要注意的一点就是close_wait 过多问题，
由于网络不稳定经常会导致客户端断连，如果服务端没有能够及时关闭socket，就会导致处于close_wait状态的链路过多。close_wait状态的链路并不释放句柄和内存等资源，如果积压过多可能会导致系统句柄耗尽，发生“Too many open files”异常，新的客户端无法接入，涉及创建或者打开句柄的操作都将失败。
close_wait是被动关闭连接时形成的，根据TCP状态机，服务器端收到客户端发送的FIN，TCP协议栈会自动发送ACK，链接进入close_wait状态。但如果服务器端不执行socket的close()操作，状态就不能由close_wait迁移到last_ack，则系统中会存在很多close_wait状态的连接。通常来说，一个close_wait会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆close_wait消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。
导致close_wait过多的可能原因如下：
1. 程序处理Bug，导致接收到对方的fin之后没有及时关闭socket，这可能是Netty的Bug，也可能是业务层Bug，需要具体问题具体分析；
2. 关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。
下面我们结合Netty的原理，对潜在的故障点进行分析。
设计要点1：不要在Netty的I/O线程上处理业务（心跳发送和检测除外）。
对于Java进程，线程不能无限增长，这就意味着Netty的Reactor线程数必须收敛。Netty的默认值是CPU核数 * 2，通常情况下，I/O密集型应用建议线程数尽量设置大些，但这主要是针对传统同步I/O而言，对于非阻塞I/O，线程数并不建议设置太大，尽管没有最优值，但是I/O线程数经验值是[CPU核数 + 1，CPU核数*2 ]之间。
设计要点2：在I/O线程上执行自定义Task要当心。
Netty的I/O处理线程NioEventLoop支持两种自定义Task的执行：
1. 普通的Runnable: 通过调用NioEventLoop的execute(Runnable task)方法执行；
2. 定时任务ScheduledFutureTask:通过调用NioEventLoop的schedule(Runnable command, long delay, TimeUnit unit)系列接口执行。
在NioEventLoop中执行Runnable和ScheduledFutureTask，意味着允许用户在NioEventLoop中执行非I/O操作类的业务逻辑，这些业务逻辑通常用消息报文的处理和协议管理相关。它们的执行会抢占NioEventLoop I/O读写的CPU时间，如果用户自定义Task过多，或者单个Task执行周期过长，会导致I/O读写操作被阻塞，这样也间接导致close_wait堆积。
所以，如果用户在代码中使用到了Runnable和ScheduledFutureTask，请合理设置ioRatio的比例，通过NioEventLoop的setIoRatio(int ioRatio)方法可以设置该值，默认值为50，即I/O操作和用户自定义任务的执行时间比为1：1。
我的建议是当服务端处理海量客户端长连接的时候，不要在NioEventLoop中执行自定义Task，或者非心跳类的定时任务。
设计要点3：IdleStateHandler使用要当心。
很多用户会使用IdleStateHandler做心跳发送和检测，这种用法值得提倡。相比于自己启定时任务发送心跳，这种方式更高效。但是在实际开发中需要注意的是，在心跳的业务逻辑处理中，无论是正常还是异常场景，处理时延要可控，防止时延不可控导致的NioEventLoop被意外阻塞。
例如，心跳超时或者发生I/O异常时，业务调用Email发送接口告警，由于Email服务端处理超时，导致邮件发送客户端被阻塞，级联引起IdleStateHandler的AllIdleTimeoutTask任务被阻塞，最终NioEventLoop多路复用器上其它的链路读写被阻塞。对于ReadTimeoutHandler和WriteTimeoutHandler，约束同样存在。
3. 合理的心跳周期
百万级的推送服务，意味着会存在百万个长连接，每个长连接都需要靠和App之间的心跳来维持链路。合理设置心跳周期是非常重要的工作，推送服务的心跳周期设置需要考虑移动无线网络的特点。当一台智能手机连上移动网络时，其实并没有真正连接上Internet，运营商分配给手机的IP其实是运营商的内网IP，手机终端要连接上Internet还必须通过运营商的网关进行IP地址的转换，这个网关简称为NAT(NetWork Address Translation)，简单来说就是手机终端连接Internet 其实就是移动内网IP，端口，外网IP之间相互映射。
GGSN(GateWay GPRS Support Note)模块就实现了NAT功能，由于大部分的移动无线网络运营商为了减少网关NAT映射表的负荷，如果一个链路有一段时间没有通信时就会删除其对应表，造成链路中断，正是这种刻意缩短空闲连接的释放超时，原本是想节省信道资源的作用，没想到让互联网的应用不得以远高于正常频率发送心跳来维护推送的长连接。以中移动的2.5G网络为例，大约5分钟左右的基带空闲，连接就会被释放。
由于移动无线网络的特点，推送服务的心跳周期并不能设置的太长，否则长连接会被释放，造成频繁的客户端重连，但是也不能设置太短，否则在当前缺乏统一心跳框架的机制下很容易导致信令风暴（例如微信心跳信令风暴问题）。具体的心跳周期并没有统一的标准，180S也许是个不错的选择，微信为300S。
4. 合理设置接收和发送缓冲区容量
对于长链接，每个链路都需要维护自己的消息接收和发送缓冲区，JDK原生的NIO类库使用的是java.nio.ByteBuffer,它实际是一个长度固定的Byte数组，我们都知道数组无法动态扩容，ByteBuffer也有这个限制，容量无法动态扩展会给用户带来一些麻烦，例如由于无法预测每条消息报文的长度，可能需要预分配一个比较大的ByteBuffer，这通常也没有问题。但是在海量推送服务系统中，这会给服务端带来沉重的内存负担。假设单条推送消息最大上限为10K，消息平均大小为5K，为了满足10K消息的处理，ByteBuffer的容量被设置为10K，这样每条链路实际上多消耗了5K内存，如果长链接链路数为100万，每个链路都独立持有ByteBuffer接收缓冲区，则额外损耗的总内存 Total(M) = 1000000 * 5K = 4882M。内存消耗过大，不仅仅增加了硬件成本，而且大内存容易导致长时间的Full GC，对系统稳定性会造成比较大的冲击。实际上，最灵活的处理方式就是能够动态调整内存，即接收缓冲区可以根据以往接收的消息进行计算，动态调整内存，利用CPU资源来换内存资源，具体的策略如下：
1. ByteBuffer支持容量的扩展和收缩，可以按需灵活调整，以节约内存；
2. 接收消息的时候，可以按照指定的算法对之前接收的消息大小进行分析，并预测未来的消息大小，按照预测值灵活调整缓冲区容量，以做到最小的资源损耗满足程序正常功能。
幸运的是，Netty提供的ByteBuf支持容量动态调整，对于接收缓冲区的内存分配器，Netty提供了两种：
1. FixedRecvByteBufAllocator：固定长度的接收缓冲区分配器，由它分配的ByteBuf长度都是固定大小的，并不会根据实际数据报的大小动态收缩。但是，如果容量不足，支持动态扩展。动态扩展是Netty ByteBuf的一项基本功能，与ByteBuf分配器的实现没有关系；
2. AdaptiveRecvByteBufAllocator：容量动态调整的接收缓冲区分配器，它会根据之前Channel接收到的数据报大小进行计算，如果连续填充满接收缓冲区的可写空间，则动态扩展容量。如果连续2次接收到的数据报都小于指定值，则收缩当前的容量，以节约内存。
相对于FixedRecvByteBufAllocator，使用AdaptiveRecvByteBufAllocator更为合理，可以在创建客户端或者服务端的时候指定RecvByteBufAllocator，代码如下：
Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)另外值得注意的是，无论是接收缓冲区还是发送缓冲区，缓冲区的大小建议设置为 消息的平均大小，不要设置成最大消息的上限，这会导致额外的内存浪费。通过如下方式可以设置接收缓冲区的初始大小：
/**
* Creates a new predictor with the specified parameters.
*
* @param minimum
* the inclusive lower bound of the expected buffer size
* @param initial
* the initial buffer size when no feed back was received
* @param maximum
* the inclusive upper bound of the expected buffer size
*/
public AdaptiveRecvByteBufAllocator(int minimum, int initial, int maximum) 5. 内存池
推送服务器承载了海量的长链接，每个长链接实际就是一个会话。如果每个会话都持有心跳数据、接收缓冲区、指令集等数据结构，而且这些实例随着消息的处理朝生夕灭，这就会给服务器带来沉重的GC压力，同时消耗大量的内存。最有效的解决策略就是使用内存池，每个NioEventLoop线程处理N个链路，在线程内部，链路的处理时串行的。假如A链路首先被处理，它会创建接收缓冲区等对象，待解码完成之后，构造的POJO对象被封装成Task后投递到后台的线程池中执行，然后接收缓冲区会被释放，每条消息的接收和处理都会重复接收缓冲区的创建和释放。如果使用内存池，则当A链路接收到新的数据报之后，从NioEventLoop的内存池中申请空闲的ByteBuf，解码完成之后，调用release将ByteBuf释放到内存池中，供后续B链路继续使用。
使用内存池优化之后，单个NioEventLoop的ByteBuf申请和GC次数从原来的N = 1000000/64 = 15625 次减少为最少0次（假设每次申请都有可用的内存）。
在Netty 4中实现了一个新的ByteBuf内存池，它是一个纯Java版本的 jemalloc （Facebook也在用）。现在，Netty不会再因为用零填充缓冲区而浪费内存带宽了。不过，由于它不依赖于GC，开发人员需要小心内存泄漏。如果忘记在处理程序中释放缓冲区，那么内存使用率会无限地增长。
Netty默认不使用内存池，需要在创建客户端或者服务端的时候进行指定，代码如下：
Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)值得注意的是，如果使用内存池，完成ByteBuf的解码工作之后必须显式的调用 ReferenceCountUtil.release(msg)对接收缓冲区ByteBuf进行内存释放，否则它会被认为仍然在使用中，这样会导致内存泄露。
6. 当心“日志隐形杀手”
通常情况下，大家都知道不能在Netty的I/O线程上做执行时间不可控的操作，例如访问数据库、发送Email等。但是有个常用但是非常危险的操作却容易被忽略，那便是记录日志。
通常，在生产环境中，需要实时打印接口日志，其它日志处于ERROR级别，当推送服务发生I/O异常之后，会记录异常日志。如果当前磁盘的WIO比较高，可能会发生写日志文件操作被同步阻塞，阻塞时间无法预测。这就会导致Netty的NioEventLoop线程被阻塞，Socket链路无法被及时关闭、其它的链路也无法进行读写操作等。
以最常用的log4j为例，尽管它支持异步写日志（AsyncAppender），但是当日志队列满之后，它会同步阻塞业务线程，直到日志队列有空闲位置可用，相关代码如下：
synchronized (this.buffer) {
while (true) {
int previousSize = this.buffer.size();
if (previousSize < this.bufferSize) {
this.buffer.add(event);
if (previousSize != 0) break;
this.buffer.notifyAll(); break;
}
boolean discard = true;
if ((this.blocking) && (!Thread.interrupted()) && (Thread.currentThread() != this.dispatcher)) //判断是业务线程
{
try
{
this.buffer.wait();//阻塞业务线程
discard = false;
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
}7. TCP参数优化
常用的TCP参数，例如TCP层面的接收和发送缓冲区大小设置，在Netty中分别对应ChannelOption的SO_SNDBUF和SO_RCVBUF，需要根据推送消息的大小，合理设置，对于海量长连接，通常32K是个不错的选择。另外一个比较常用的优化手段就是软中断，如图所示：如果所有的软中断都运行在CPU0相应网卡的硬件中断上，那么始终都是cpu0在处理软中断，而此时其它CPU资源就被浪费了，因为无法并行的执行多个软中断。
大于等于2.6.35版本的Linux kernel内核，开启RPS，网络通信性能提升20%之上。RPS的基本原理：根据数据包的源地址，目的地址以及目的和源端口，计算出一个hash值，然后根据这个hash值来选择软中断运行的cpu。从上层来看，也就是说将每个连接和cpu绑定，并通过这个hash值，来均衡软中断运行在多个cpu上，从而提升通信性能。
8. JVM参数
最重要的参数调整有两个：-Xmx:JVM最大内存需要根据内存模型进行计算并得出相对合理的值；
GC相关的参数: 例如新生代和老生代、永久代的比例，GC的策略，新生代各区的比例等，需要根据具体的场景进行设置和测试，并不断的优化，尽量将Full GC的频率降到最低。
上文转载：Netty系列之Netty百万级推送服务设计要点，厉害了
扫一扫
666
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
