Pipeline 的生命周期

这篇文章以 Netty 为背景。分析 ChannelPipeline 从创建、添加 Handler、响应 Channel 注册、传播事件，到移除 Handler 和销毁链表的完整过程。

Pipeline 依附于 Channel 存在。不过，一个 Channel 在构造时就会创建一个 Pipeline。之后 Pipeline 中 Handler 的生命周期又会受到 Channel 注册、注销和关闭流程的推动。这篇文章不会重复展开 Channel 的底层注册和关闭逻辑，只关注它们与 Pipeline 发生连接的位置。Channel 本身的状态变化可以参考《Channel的生命周期》。

先建立整体认识

Pipeline 没有独立于 Channel 的生命周期

一个 Channel 只持有一个 Pipeline：

Channel -> ChannelPipeline -> HeadContext -> 业务 ChannelHandlerContext -> TailContext

Pipeline 没有独立状态，也没有单独注册到 EventLoop 的操作。它的关键阶段由 Channel 推动：

Channel 构造 -> 创建 Pipeline向 Pipeline 添加 Handler -> 创建 Context 并插入链表
Channel 注册 -> 执行注册前积累的 handlerAdded
传播 channelRegistered
Channel 激活和读写 -> 在 Pipeline 中传播入站事件和出站操作
Channel 关闭并注销 -> 传播 channelInactive
-> 传播 channelUnregistered
-> 删除业务 Context
-> 执行 handlerRemoved

这里需要区分两个概念：

• Pipeline 对象的生命周期：从 Channel 构造开始，最终与 Channel 一起变为不可达对象并由 GC 回收。
• Pipeline 中 Context 的生命周期：从插入链表开始，到移出链表并完成 handlerRemoved 为止。话说回来，

现在我们根据这两条主线来阅读

Channel、Pipeline、Context 和 Handler 的关系

四者的职责如下：

Channel 表示一条网络通道。并持有一个 Pipeline
ChannelPipeline 维护由 ChannelHandlerContext 组成的双向链表
ChannelHandlerContext 保存链表位置、所属 Pipeline、Handler、执行器和生命周期状态
ChannelHandler 实现具体的入站事件或出站操作处理逻辑

Pipelinet 链表中真正连接的是 ChannelHandlerContext不是 Handler 本身。DefaultChannelHandlerContext 通过组合关系持有 Handler：

final class DefaultChannelHandlerContext extends AbstractChannelHandlerContext {
private final ChannelHandler handler;DefaultChannelHandlerContext(
DefaultChannelPipeline pipeline。EventExecutor executor,String name,ChannelHandler handler) {
super);this.handler = handler;怎么说呢，}
}

Handler 只负责处理逻辑。老实说，它在当前 Pipeline 中的位置、执行线程和生命周期状态属于 Context。

. Pipeline 的创建

AbstractChannel 创建 Pipeline

Pipelin 在 AbstractChannel 的构造方法中创建：

protected AbstractChannel {
this.parent = parent;this.id = id;unsafe = newUnsafe;
按理说，pipeline = newChannelPipeline;}

newChannelPipeline 默认返回 DefaultChannelPipeline

protected DefaultChannelPipeline newChannelPipeline {
return new DefaultChannelPipeline;}

channel 完成对象构造时就已经拥有 Pipeline。此时 channel 通常还没有注册到 EventLoop。也没有激活，但 Pipeline 已经存在。按理说，

初始化 HeadContext 和 TailContext

DefaultChannelPipeline 构造方法会创建两个固定节点：

protected Defaultchannelpipeline{
head = new Headcontext;tail = new Tailcontext;head.next = tail;tail.prev = head;}

从初始链表如下来看。

<-->

"head" 与 "tail" 不仅是哨兵，也是事件传播边界节点。

痛点一这方面，handlerAdded 与事件顺序混乱问题

• 如果在 handlerAdded内部 对 pipeline 做修改。可能导致后续事件被错误地跳过或重复处理，从而出现数据丢失或异常顺序。

1️⃣ 将所有对 pipeline 的修改放到回调外部完成；2️⃣ 若一定要在回调内部修改。请先确认所在线程是该 context 所绑定执行器，以避免跨线程竞争；3️⃣ 使用 replace / remove / addFirst/addLast 可保证同步完成后再继续业务处理。

使用代码片段检查已完成 callback 状态后再添加新的 handler，例如： if .inEventLoop) { ctx.pipeline.addLast);} else { ctx.executor.execute -> ctx.pipeline.addLast));} 这能确保新 handler 已进入可执行状态，避免旧 handler 在 remove 时仍然拦截消息。

遵循 Netty 官方建议：不要在任何回调里直接访问 ctx.channel 来修改管道；若需要动态配置，请使用 ctx.channel.eventLoop.execute 明确提交任务至正确线程。

请确认是否需要进一步调整其他章节？老实说，

---