k的博客

导致NioSocketChannel泄漏的可能原因有两个。（1）代码有缺陷，HTTPS客户端关闭连接之后，服务端没有正确关闭连接。（2）服务端负载比较重，客户端超时之后的断连和重连速度超过服务端关闭连接速度，导致服务端的NioSocketChannel发生积压。随着积压数的增加，导致占用的内存快速增加，频繁GC使得服务端处理更慢，积压更严重，最终导致OOM异常。在贴一个NIO的客户端、服务端的模型。不要忘了客户端也可以连接多个服务器，可以用多路复用来增加吞吐量。

发现有时经常搞混BIO和reactor模型的关系。这里记录下。

当收到一个完整的应用层消息报文，channelRead会被触发一次。每次读取完Socket的接收缓冲区的报文，channelReadComplete会被触发一次。

Netty，所有的网络I/O操作都是异步执行的。netty 中的API操作，大都是异步的，会返回一个future，如有必要，我们需要监听该future的处理结果 或者同步阻塞等待异步的返回结果。这个基础就是多线程交互：一个线程发生了变化，如何通知另一个线程呢？下面看一下常见的方法或问题。

ByteBuf释放注意的问题

自定义线程池的问题；使用netty自带的channelpool

netty addLast(group,handler) 以及 SINGLE_EVENTEXECUTOR_PER_GROUP