Netty学习笔记摘要援引

netty防止内存泄露：

https://blog.csdn.net/gt9000/article/details/88206340

里面还提到了一点：
畸形码流攻击：如果客户端按照协议规范，将消息长度值故意伪造的非常大，可能会导致接收方内存溢出。
代码 BUG：错误的将消息长度字段设置或者编码成一个非常大的值，可能会导致对方内存溢出。

这些，也都是需要我考虑拦截的。

避免内存泄漏的策略如下：

无论采用哪种解码器实现，都对消息的最大长度做限制，当超过限制之后，抛出解码失败异常，用户可以选择忽略当前已经读取的消息，或者直接关闭链接。
以 Netty 的 DelimiterBasedFrameDecoder 代码为例，创建 DelimiterBasedFrameDecoder 对象实例时，指定一个比较合理的消息最大长度限制，防止内存溢出：

发送积压导致OOM内存泄漏：

https://blog.csdn.net/MarchRS/article/details/103952718

其他可能导致发送队列积压的因素
然而，在实际情况中，并非只有高并发场景才会导致消息积压，在一些异常场景下，尽管流量不大，但仍然可能导致消息积压，场景如下：

网络瓶颈，当发送速度超过网络链接处理能力，会导致发送队列积压
当对端读取速度小于己方发送速度，导致自身TCP发送缓冲区满，频繁发生write 0字节时，待发送消息会在Netty发送队列中排队。当出现大量排队时，很容易导致Netty的直接内存泄漏。
————————————————
版权声明：本文为CSDN博主「MarchRS」的原创文章，遵循CC 4.0
BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/MarchRS/article/details/103952718

netty的缓存区流量整形解释：

https://www.jianshu.com/p/6c4a7cbbe2b5

Netty-消息发送工作机制：

https://blog.csdn.net/MarchRS/article/details/103919942