ChannelFuture 的 addListener 是通知式回调而非真正异步，因它仅注册监听器，由 EventLoop 线程在 I/O 完成后同步调用，不开启新线程；耗时逻辑需显式提交至业务线程池。
ChannelFuture 的 addListener 为什么不是“真正异步”而是“通知式回调”
Netty 的 ChannelFuture 本身不执行异步操作，它只是 I/O 操作的“结果占位符”。真正的异步发生在 EventLoop 线程里，addListener 只是注册一个监听器，等对应操作（比如 connect、write）在 EventLoop 中完成后再调用你传入的 ChannelFutureListener。
常见错误现象：
— 在非 EventLoop 线程里直接调用 future.sync() 或 future.get()，导致线程阻塞甚至死锁
— 把 addListener 当成“开启新线程”，结果发现回调仍在 EventLoop 线程中执行，耗时逻辑卡住整个 channel
- 回调函数始终由触发该 future 完成的那个
EventLoop执行，不是新线程，也不切换线程上下文 - 如果监听器里做了阻塞操作（如 JDBC 查询、
Thread.sleep），会拖慢整个EventLoop，影响其他 channel - 想真正“卸载”耗时逻辑，得显式提交到业务线程池：
executor.submit(() -> { /* 耗时操作 */ })
addListener 和 sync() / await() 的本质区别在哪
addListener 是纯事件驱动、零等待；sync() 和 await() 是同步等待，会把当前线程挂起直到 future 完成或超时。
使用场景：
— addListener：适合响应式链路，比如 write 后立即注册日志监听，不打断 pipeline 流水线
— sync()：仅限测试、启动阶段初始化（如等待 bind 完成），绝不能出现在 handler 的 channelRead 中
-
sync()抛出InterruptedException，而await()不抛，只返回布尔值表示是否超时 -
syncUninterruptibly()忽略中断，但依然阻塞 —— 这个方法容易掩盖线程中断意图，慎用 - 所有阻塞方法都绕过了 Netty 的异步设计初衷，一旦被滥用，系统吞吐量会断崖下跌
监听器里怎么安全访问 Channel 或 pipeline
回调执行时，Channel 通常仍是可用的，但必须确认其活跃状态，不能假设“既然监听器被调用了，channel 就一定还活着”。
常见错误现象：
— 在 operationComplete 中直接调用 channel.writeAndFlush(...)，但此时 channel 已 close，抛 IllegalStateException: channel inactive
— 修改 pipeline 时没加 synchronized 或没走 channel.eventLoop().execute()，引发并发修改异常
- 务必先检查
future.channel().isActive()再做写操作 - 如果要动态添加 handler，必须通过
channel.eventLoop().execute(() -> { pipeline.addLast(...); }) - 避免在监听器里调用
channel.close()后又继续用这个 channel —— close 是异步的，后续代码仍可能执行
为什么 addListener 有时像“没触发”？几个典型漏点
最常被忽略的是：future 对象本身可能已经完成，再 addListener 就会立刻同步调用监听器 —— 但如果监听器注册前 future 就失败了，而你的监听器没处理 failure 分支，就等于“什么都没发生”。
参数差异：addListener 接收 ChannelFutureListener，而 addListeners 可批量注册多个，但无序执行，不保证先后
- 永远为
operationComplete方法加上if (future.isSuccess()) { ... } else { future.cause().printStackTrace(); } - 不要依赖监听器执行顺序 —— 多个 listener 的调用顺序不保证，尤其当部分 listener 提交任务到外部线程池时
- 注意：Bootstrap.connect() 返回的 future，在 connect 超时后会自动失败；但如果你设置了 connect timeout，却没在 listener 里检查
cause instanceof TimeoutException，就会漏掉超时诊断
复杂点在于：future 的生命周期和 channel 生命周期解耦，监听器可能在 channel 关闭后才被调用，也可能在 connect 成功前就被取消。这些边界条件不靠文档，得靠日志和 future.isCancelled() / isDone() 主动兜底。
