netty服务启动失败主因是eventloopgroup未调用shutdowngracefully().sync()导致端口占用；channelhandler需避免状态共享；bytebuf须成对release；sslcontext应全局复用。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
Netty 服务启动失败：EventLoopGroup 未正确 shutdown 导致端口无法重用
DeepSeek 模型本身不参与 Netty 编程，但如果你在部署 DeepSeek 推理服务时用 Netty 做自定义 HTTP/gRPC 封装，常会卡在这一步——服务重启报 java.net.BindException: Address already in use。这不是端口真被占着，而是前一次 EventLoopGroup 没彻底释放。
关键点：Netty 的 EventLoopGroup（如 NioEventLoopGroup）必须显式调用 shutdownGracefully()，且要等它完成才能退出 JVM。直接调 close() 或忽略返回的 Future，等于没关。
- 务必在
finally块或try-with-resources（需包装成 AutoCloseable）中调用bossGroup.shutdownGracefully().sync()和workerGroup.shutdownGracefully().sync() -
sync()是阻塞等待关闭完成；不加它，主线程可能提前退出，导致线程池残留 - 别在
ChannelFuture的addListener里关EventLoopGroup——此时 channel 可能还没真正 bind 成功，关早了会触发 NPE
ChannelHandler 线程安全陷阱：SimpleChannelInboundHandler vs ChannelInboundHandlerAdapter
写完解码逻辑发现并发请求下数据错乱？大概率是把状态变量（比如 ByteBuffer、StringBuilder）放在了 SimpleChannelInboundHandler 实例里。这个类默认复用实例，且方法由不同 EventLoop 线程调用。
根本原因：Netty 不保证同一个 ChannelHandler 实例只被一个线程访问。除非你明确标注 @Sharable 并确保无状态，否则每个 Channel 应该有独立 handler 实例。
- 用
ChannelInboundHandlerAdapter替代SimpleChannelInboundHandler，自己管理消息生命周期（手动ReferenceCountUtil.release()） - 如果要用
SimpleChannelInboundHandler，确保泛型类型是不可变对象，且内部不存任何跨事件状态 - 需要共享状态（如统计计数器）时，用
AtomicLong或ConcurrentHashMap，别用普通int或HashMap
内存泄漏预警：PooledByteBufAllocator 分配后未 release()
服务跑几天后 OOM，堆外内存持续上涨？io.netty.util.internal.OutOfDirectMemoryError 不是 JVM 堆问题，是 Netty 的池化 ByteBuf 没还回去。
Netty 默认用 PooledByteBufAllocator，分配的 ByteBuf 必须成对 release()。常见漏点：异常分支没释放、ChannelPromise 失败回调里忘了释放、或者把 ByteBuf 传给第三方库后失去控制权。
- 所有从
ctx.alloc().buffer()或解码器输出得到的ByteBuf，只要你不 retain 过，就必须在处理完后调buf.release() - 用
ByteBufUtil.getBytes(buf)转成 byte[] 后，原buf仍需 release —— 这个操作只是拷贝内容 - 开启内存泄漏检测：启动时加 JVM 参数
-Dio.netty.leakDetectionLevel=paranoid，测试阶段就能暴露问题
SSL/TLS 握手卡顿：SslContext 构建耗时且不可复用
高并发下首次 HTTPS 请求延迟突增几百毫秒？不是网络问题，是每次新建 SslContext 都在做密钥解析和证书链验证。
SslContext 是线程安全的，且构建开销大，必须全局单例复用。DeepSeek 类服务若走 HTTPS 暴露模型接口，这点尤其关键。
- 在应用初始化阶段一次性构建
SslContext，例如用SslContextBuilder.forServer(keyCertChainFile, keyFile, keyPassword) - 不要在
initChannel里 newSslContext，那是每个连接都执行一遍 - 如果用 Let’s Encrypt 的自动续期证书，更新后需重建
SslContext并热替换到 pipeline 中（调pipeline.replace()），不能直接改引用
