Netty面试问题汇总
什么是Reactor线程模型？
一种事件驱动处理模型，类似于多路复用IO模型，包括三种角色：Reactor、Acceptor和Handler。Reactor用来监听事件，包括：连接建立、读就绪、写就绪等。然后针对监听到的不同事件，将它们分发给对应的线程去处理。其中acceptor处理客户端建立的连接，handler对读写事件进行业务处理。
Reactor线程模型消息处理的流程？
- Reactor线程通过多路复用器监控IO事件。
- 如果是连接建立的事件，则由acceptor线程来接受连接，并创建handler来处理之后该连接上的读写事件。
- 如果是读写事件，则Reactor会调用该连接上的handler进行业务处理。
Reactor线程模型的三种模式？
单Reactor单线程模式
仅由一个线程来进行事件监控和事件处理，即整个消息处理流程都在一个线程中完成。
单Reactor多线程模式
对于连接上的读写事件，会使用线程池中的线程来执行该连接上的handler操作，即对读写事件的处理不会阻塞Reactor线程。
主从Reactor多线程模式
在单Reactor多线程模式的基础上，使用两个Reactor线程分别对建立连接事件和读写事件进行监听，每个Reactor线程拥有一个多路复用器。当主Reactor线程监听到连接建立事件后，创建SocketChannel，然后将SocketChannel注册到子Reactor线程的多路复用器中，使子Reactor线程监听连接的读写事件。
讲一下Netty线程模型
netty线程模型采用的是主从线程模型，不过进行了改进。netty中定义了两个线程池：bossGroup和workerGroup（EventLoopGroup，有一个属性children为NioEventLoop[]）。线程池中的所有线程（NioEventLoop）都包含一个多路复用器（selector）。bossGroup中的线程用来监听连接建立（accept）的事件，workerGroup中的线程用来监听通道上的读写（read、write）事件。
当boss线程监听到accept事件，接受连接并创建channel，然后将channel注册到一个worker线程中。worker线程不断的监听channel上的读写事件，当有事件发生时，会调用channel上的ChannelHandler进行处理。
什么是Netty的零拷贝？
零拷贝（Zero-copy）及其应用详解 - 简书
- Netty可以在堆外创建一个直接缓冲区（ByteBuf），当进行IO写时，将数据放在直接缓冲区，可以避免频繁将数据从堆中复制到直接内存中。
- 通过CompositeByteBuf 可以将多个ByteBuf合并成一个逻辑上的ByteBuf，避免了对每个ByteBuf的拷贝。
ByteBuf header = ...
ByteBuf body = ...
CompositeByteBuf compositeByteBuf = Unpooled.compositeBuffer();
compositeByteBuf.addComponents(true, header, body);
private final List<Component> components;
private static final class Component {
final ByteBuf buf;
final int length;
int offset;
int endOffset;
Component(ByteBuf buf) {
this.buf = buf;
length = buf.readableBytes();
}
......
}- 通过Unpooled工具类的wrappedBuffer（bytes）可以将一个byte[]转换成ByteBuf，避免了拷贝；通过Unpooled.slice()可以将一个ByteBuf切分成多个逻辑上的Bytebuf，同样也不涉及数据拷贝。
ByteBuf header = ...
ByteBuf body = ...
ByteBuf allByteBuf = Unpooled.wrappedBuffer(header, body);
byte[] bytes = ...
ByteBuf byteBuf = Unpooled.wrappedBuffer(bytes);
ByteBuf byteBuf = ...
ByteBuf header = byteBuf.slice(0, 5);
ByteBuf body = byteBuf.slice(5, 10);- 通过FileChannel.transferTo()进行文件传输，可以直接将文件系统缓冲区的数据发送到目标channel，避免了传统IO通过循环read、write而导致的内存拷贝问题。（站在内核的角度来说，避免了把数据从内核缓冲区拷贝到用户内存中）
* <p> This method is potentially much more efficient than a simple loop * that reads from this channel and writes to the target channel. Many * operating systems can transfer bytes directly from the filesystem cache * to the target channel without actually copying them. </p>
- sendFile()和mmap()底层调用，见文档。
TCP 粘包/拆包的原因及解决方法？
TCP是以流的方式来处理数据，一个完整的数据包可能会被TCP拆分成多个包进行发送，也可能把多个小的包封装成一个大的数据包。由于TCP数据包之间没有边界保护，所以当发生粘包或拆包时，接收端难以从数据流中准确获取数据。
TCP粘包/分包的原因：
应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生拆包现象，而应用程序写入数据小于套接字缓冲区大小，网卡将应用程序多次写入的数据封装成一个数据包发送到网络上，这将会发生粘包现象。
解决方法：
netty提供了3种类型的解码器对TCP 粘包/拆包问题进行处理：
- 定长消息解码器：FixedLengthFrameDecoder。发送方和接收方规定一个固定的消息长度，不够用空格等字符补全，这样接收方每次从接受到的字节流中读取固定长度的字节即可，长度不够就保留本次接受的数据，再在下一个字节流中获取剩下数量的字节数据。
- 分隔符解码器：LineBasedFrameDecoder或DelimiterBasedFrameDecoder。LineBasedFrameDecoder是行分隔符解码器，分隔符为\n或\r\n；DelimiterBasedFrameDecoder是自定义分隔符解码器，可以定义一个或多个分隔符。接收端在收到的字节流中查找分隔符，然后返回分隔符之前的数据，没找到就继续从下一个字节流中查找。
- 数据长度解码器：LengthFieldBasedFrameDecoder。将发送的消息分为header和body，header存储消息的长度（字节数），body是发送的消息的内容。同时发送方和接收方要协商好这个header的字节数，因为int能表示长度，long也能表示长度。接收方首先从字节流中读取前n（header的字节数）个字节（header），然后根据长度读取等量的字节，不够就从下一个数据流中查找。