Channel、ChannelPipeline 和 ChannelHandler 分别是什么？

简化版

Channel 表示一条网络连接（对 Socket 的抽象），提供读写、关闭、绑定 EventLoop 等能力。ChannelPipeline 是这条连接上的「处理链（流水线）」，每个 Channel 有自己的一条 Pipeline。ChannelHandler 是链上的处理节点——解码器、业务处理器、编码器都是 Handler，每个只做一小块事。事件在链上有方向：入站事件（读、连接、异常）从链头向尾传播（Inbound）；出站事件（写、flush、connect）从当前位置向链头方向传播（Outbound）。方向理解错，Handler 可能永远不执行。

详细版

三者的关系：

Channel（一条连接）
  └─ ChannelPipeline（这条连接的处理链）
       ├─ Handler1（解码器 Inbound）
       ├─ Handler2（业务处理 Inbound）
       └─ Handler3（编码器 Outbound）

入站 vs 出站方向：

入站(Inbound)：网络 → channelRead → 链头 ──向尾──> 业务
  [解码器] → [业务Handler] → ...

出站(Outbound)：业务 write/flush → 从当前 ──向头──> 网络
  ... ← [编码器] ← [业务Handler]

概念	是什么	关键点
Channel	一条连接	读写/关闭/绑定 EventLoop/attribute
ChannelPipeline	连接的处理链	每 Channel 一条，双向链表结构
ChannelHandler	链上处理节点	Inbound 处理读、Outbound 处理写，各司一小块

两类 Handler：

ChannelInboundHandler：处理入站事件（channelRead、channelActive、exceptionCaught）。
ChannelOutboundHandler：处理出站操作（write、flush、connect）。

完整版教学

一、Channel 是连接抽象

在 Netty 里，你不直接操作原生 Socket，而是通过 Channel 操作一条连接。Channel 提供：

读写数据（read/write/writeAndFlush）。
关闭连接（close）。
注册到 EventLoop（绑定处理它的线程）。
获取属性（attr(...)，存连接级的自定义状态，如登录用户）。

Channel 是业务代码识别「一个客户端连接」的核心对象——想给某个客户端发消息，就拿到它的 Channel 调 writeAndFlush。

二、Pipeline 是处理链（流水线）

每个 Channel 都有一条自己的 ChannelPipeline。Pipeline 像一条流水线，把「从原始字节 → 协议帧 → 业务对象 → 响应写出」的处理分层：

入站：ByteBuf(字节) → 解码器 → 业务消息对象 → 业务Handler处理
出站：响应对象 → 编码器 → ByteBuf(字节) → 写到网络

好处：协议逻辑和业务逻辑拆开维护——解码/编码放专门的 Handler，业务放业务 Handler，各自独立、可复用、可测试。Pipeline 内部是一个双向链表（由 ChannelHandlerContext 节点串联）。

三、Handler 是节点（各司一小块）

ChannelHandler 是链上的处理节点，每个只负责一类事：

解码器（Decoder）：把 ByteBuf（原始字节）转成业务消息对象。
业务 Handler：处理请求、执行业务逻辑。
编码器（Encoder）：把响应对象转回 ByteBuf。

每个 Handler 只做一小块事情，链路就清晰——这是责任链模式 + 单一职责的体现。要加新功能（如日志、限流、SSL），插入一个新 Handler 即可，不影响其他。

四、入站和出站方向（关键，易错）

事件在 Pipeline 上传播是有方向的：

入站事件（Inbound）：来自网络——如 channelRead（读到数据）、channelActive（连接建立）、exceptionCaught。它们从 Pipeline 头部向尾部传播（head → tail），只经过 InboundHandler。
出站事件（Outbound）：由应用发起——如 write、flush、connect。它们从当前位置向头部方向传播（tail/当前 → head），只经过 OutboundHandler。

方向理解错，Handler 可能永远不执行——比如你写了一个 OutboundHandler 想拦截写操作，但把它加在了业务 Handler「之后」（更靠尾部），而出站是「向头部传播」的，永远经不过它。所以添加 Handler 的顺序、以及 Inbound/Outbound 的方向，必须对应正确。

方向	触发来源	典型方法	Pipeline 中的关注点
Inbound	网络读入、连接建立、异常传播	`channelRead`、`channelActive`、`exceptionCaught`	解码器通常在业务 Handler 前
Outbound	应用主动写出、连接关闭、flush	`write`、`flush`、`connect`	编码器必须位于写出传播路径上

Pipeline 面试最容易丢分的是方向和顺序：同一个 Handler 放错位置，代码能编译，但事件可能根本走不到它。

五、事件传播要显式

在自定义 Handler 里，事件不会自动传给下一个 Handler——你要显式调用传播方法：

入站：ctx.fireChannelRead(msg) 把消息传给下一个 InboundHandler。
出站：ctx.write(msg) 把写操作传给下一个 OutboundHandler。

如果你处理完不调用传播方法，事件就停在当前 Handler（被「吞掉」）——这是合法的（有时确实想终止传播），但必须是有意为之。忘了调 fireChannelRead 导致「后面的 Handler 收不到消息」是常见 bug。

六、线程安全和共享（@Sharable）

默认每个 Channel 有独立的 Handler 实例——所以 Handler 里可以安全地保存连接级状态（这个连接的状态，不会和别的连接混）。
如果一个 Handler 标记了 @Sharable，表示它可被多个 Channel 共享同一个实例（省内存）——那么它内部就绝不能保存连接级的可变状态（否则多个连接会互相干扰、串号）。@Sharable 的 Handler 必须是无状态的。
连接级状态应该放 Channel 的 attribute（channel.attr(KEY)） 或每个 Channel 独立的 Handler 实例里。

（这和「Servlet 单实例多线程的线程安全」是同一类问题——共享实例不能存可变状态。）

七、异常处理（ByteBuf 释放是考点）

异常会沿 Pipeline 传播到 exceptionCaught 方法。生产代码要在这里统一处理：记录日志、释放资源、关闭异常连接或返回错误响应。

一个高频考点：异常路径下 ByteBuf 是否释放。Netty 的 ByteBuf 用引用计数管理堆外内存（见「引用计数/内存泄漏」专题）——如果在正常路径外（异常发生时）忘记释放 ByteBuf，会导致堆外内存泄漏。所以异常处理和各个 Handler 都要注意：处理完/异常时，确保 ByteBuf 被正确 release。这是 Netty 面试常追问的点。

八、常见误区与追问

误区：Channel 就等于 Java Socket 对象。 Channel 是 Netty 对连接和 I/O 操作的统一抽象，屏蔽了底层 SocketChannel 的很多细节。
误区：一个 Pipeline 被所有连接共享。 每个 Channel 都有自己的 Pipeline，Handler 实例能否共享取决于是否无状态以及是否正确使用 @Sharable。
误区：Inbound 和 Outbound 都按同一个方向执行。 Inbound 从头到尾传播，Outbound 从当前位置向前传播，编码器、解码器放错顺序会导致事件走不到。
追问：为什么 fireChannelRead 很重要？ 当前 Handler 如果不显式传播，后续 Handler 收不到这次入站事件，业务链会在这里被截断。
追问：@Sharable Handler 有什么要求？ Handler 不能保存连接级可变状态，或必须自己保证并发安全，否则多个 Channel 共享同一实例会相互污染。
追问：异常处理中 ByteBuf 为什么容易泄漏？ 异常路径可能跳过正常传播和释放逻辑，当前 Handler 如果消费了消息又不传下去，就要在 finally 或异常分支释放。

九、加强记忆

Channel = 一条连接（Socket 抽象，读写/关闭/绑 EventLoop/attr 存连接级状态）；ChannelPipeline = 这条连接的处理链（每 Channel 一条，双向链表，把「字节↔协议帧↔业务对象」分层）；ChannelHandler = 链上处理节点（解码器/业务/编码器，各司一小块，责任链+单一职责）。方向（关键）：入站事件（channelRead/Active/异常）从头向尾传播（Inbound），出站操作（write/flush/connect）从当前向头传播（Outbound）——方向或顺序错，Handler 不执行。事件传播要显式（ctx.fireChannelRead/ctx.write，不调就被「吞掉」）。@Sharable 共享 Handler 不能存连接级可变状态（连接状态放 Channel attribute 或独立实例）。异常传到 exceptionCaught 统一处理，注意 ByteBuf 在异常路径也要 release（防堆外内存泄漏，高频考点）。

简化版

详细版