Netty是什么？
是一个网络通信框架
能做什么？
绝大多数的网络通信Netty都能做，BIO的服务端与客户端通信，NIO的服务端网络通信
为什么要用Netty？
一般对于NIO来说，jdk提供的NIO实现是真的有点复杂，很原生，还有点bug，其中最难顶的就是空selector导致的cpu过高问题，Netty是指在减少NIO的开始技术难度，即使不太熟悉的NIO的开发者，只要按照Netty的规范去写代码也能写出很棒的并发通信应用。
Netty的几个基本组件：
ByteBuf：对标JDK的ByteBuffer，是一个操作序列，可以说是缓冲区，零拷贝实现的一个重要组件
Channel：对标JDK的Channel，通道，通信的核心类包装了一个unsafe，操作IO的工具或方法需要注意的是IO不是写进channel的，而是缓冲区
ChannelHandler：用户自定义的IO数据处理实现，有channelRead、register等IO通知方法，方便我们在各种IO事件后做相应的业务操作。
如：
1. 注册事件 fireChannelRegistered。
2. 连接建立事件 fireChannelActive。
3. 读事件和读完成事件 fireChannelRead、fireChannelReadComplete。
4. 异常通知事件 fireExceptionCaught。
5. 用户自定义事件 fireUserEventTriggered。
6. Channel 可写状态变化事件 fireChannelWritabilityChanged。
7. 连接关闭事件 fireChannelInactive。
EventLoop:还有另一个概念EventLoopGroup,在初始化netty时我们会定义两个线程组，一个负责IO事件的分发，另一个负责IO的事的处理，但要注意的是每个Channel都会绑定一个EventLoop。确保在单线程中完成一次IO事件
bootstrap：netty的引导器，负责引导Netty程序的启动
还有一个概念引自一位大佬的知乎：面试系列 深入理解NIO select&epoll - 知乎
为什么会出现epoll，它的背景是什么
select和poll函数的缺陷是：
- 函数调用参数拷贝问题：这两系统函数每次调用都需要我们提供给他所有需要监听的socket文件描述符集合，而且我们主线程是死循环调用select/poll函数，这涉及到用户空间数据到内核空间的拷贝过程，这个操作比较耗费性能。其实我们的fd集合是比较稳定的，可能它每次只有1-2个socket_fd需要更改，但是我们每次都需要传整个。因为select/poll没有在kernel层面保留任何数据信息，所以说每次调用都需要进行数据拷贝。
- 系统调用返回后不知道哪些socket就绪问题：select和poll函数它的返回值是个int整型，只能代表有几个socket就绪了，导致我们程序被唤醒之后，还需要新一轮的系统调用，去检查哪个socket是就绪状态的
怎么解决，epoll怎么设计的呢？
需要epoll函数在内核空间内，它有一个对应的数据结构去存储一些数据。这个数据结构实际上就是eventpoll对象，eventpoll的结构，主要是三块重要的区域，一块是检查列表，存放需要监听的socket_fd监听符，红黑树，因为这个socket集合信息经常会有增删改查的需求，保持了时间复杂度为O(logN)
另一块就是就绪列表，存放就绪状态的socket信息,双向链表。 另一块是等待队列，把调用epollwait函数的进程放到这里面去。
它主要提供了两个函数，epoll_ctl函数，它负责维护检查列表，可以根据eventpoll-id去增加删除改动需要检查的socket文件描述符。 epoll_wait函数它主要参数是eventpoll-id,表示此次系统调用需要监测的socket_fd集合是eventpoll里面的信息。默认情况下它会阻塞调用线程，直到eventpoll中关联的某个socket就绪以后，epoll_wait函数才会返回。
怎么维护就绪队列
靠的是中断程序，对等待队列和就绪队列进行操作
epoll_wait返回0表示没有就绪socket,大于0表示有几个就绪socket，它怎么解决第二个识别就绪socket问题的呢。
epollwait函数调用的时候，会传入一个epoll_event事件数组指针，epoll_wait函数正常返回之前会把就绪的socket事件信息拷贝到这个数组指针里面。上层程序就可以通过这个数组拿到就绪的socket列表。所以它的时间复杂度是O(1)
epoll_wait函数可以设置成非阻塞的 吗?
默认是阻塞的，但可以设置阻塞时间，如果设置为0表示非阻塞，每次调用都会去检查就绪列表
检查队列采用的数据结构是什么？
红黑树，因为这个socket集合信息经常会有增删改查的需求
epoll_wait阻塞期间另一个线程执行epoll_ctl是否安全
- 添加：没问题，另一个线程增加fd进监听列表，epoll_wait是可以监听到的
- 删除：官方描述的话，是部分unix系统关闭socket会被认为是就绪，从而读写失败报错，部分是没问题
- 删除再打开：如果关闭了socket就相当于把它从红黑树监听列表移除了，必须再次添加才能被监听
边缘触发和水平触发的区别
- 水平触发:如果文件描述符已经就绪可以非阻塞的执行IO操作了,此时会触发通知.允许在任意时刻重复检测IO的状态.select,poll就属于水平触发.
- 简单来说只要缓冲区还有内容，就会返回读就绪。
- 边缘触发:如果文件描述符自上次状态改变后有新的IO活动到来,此时才会触发通知.在收到一个IO事件通知后要尽可能多的执行IO操作,因为如果在一次通知中没有执行完IO那么就需要等到下一次新的IO活动到来才能获取到就绪的描述符.
- 简单来说，只有当缓冲区内容发生变化时，才会返回读就绪
使用场景
epoll默认是水平触发，优点是保证数据完整性，会一直通知你，缺点是这种通知涉及内核态到用户态的切换，会浪费一定性能。
边缘触发，优点是每次内核只会通知一次，提高效率，缺点是不能保证数据的完整性，不一定能及时取出所有数据。一般来说如果处理大数据的情况下会使用边缘触发。
一个管道收到了1kb的数据,epoll会立即返回,此时读了512字节数据,然后再次调用epoll.这时如果是水平触发的,epoll会立即返回,因为有数据准备好了.如果是边缘触发的不会立即返回,因为此时虽然有数据可读但是已经触发了一次通知,在这次通知到现在还没有新的数据到来,直到有新的数据到来epoll才会返回,此时老的数据和新的数据都可以读取到(当然是需要这次你尽可能的多读取).