1. 设计模式 - 责任链模式

责任链模式（Chain of Responsibility Pattern） 为请求创建了一个处理对象的链。

发起请求和距离处理请求的过程进行解耦：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无需关心请求的处理细节和请求的传递。

2. 实现责任链模式

实现责任链模式的 4个要素 ：

• 处理器抽象类
• 具体的处理器实现类
• 保存处理器信息
• 处理执行

• 代码的例子

// -----链表形式调用------netty就是类似的这种形式
public class PipelineDemo {
    /**
     * 初始化的时候造一个head，作为责任链的开始，但是并没有具体的处理
     */
    public HandlerChainContext head = new HandlerChainContext(new AbstractHandler() {
        @Override
        void doHandler(HandlerChainContext handlerChainContext, Object arg0) {
            handlerChainContext.runNext(arg0);
        }
    });

    public void requestProcess(Object arg0) {
        this.head.handler(arg0);
    }

    public void addLast(AbstractHandler handler) {
        HandlerChainContext context = head;
        while (context.next != null) {
            context = context.next;
        }
        context.next = new HandlerChainContext(handler);
    }


    public static void main(String[] args) {
        PipelineDemo pipelineChainDemo = new PipelineDemo();
        pipelineChainDemo.addLast(new Handler2());
        pipelineChainDemo.addLast(new Handler1());
        pipelineChainDemo.addLast(new Handler1());
        pipelineChainDemo.addLast(new Handler2());

        // 发起请求
        pipelineChainDemo.requestProcess("火车呜呜呜~~");

    }
}

/**
 * handler上下文，我主要负责维护链，和链的执行
 */
class HandlerChainContext {
    HandlerChainContext next; // 下一个节点
    AbstractHandler handler;

    public HandlerChainContext(AbstractHandler handler) {
        this.handler = handler;
    }

    void handler(Object arg0) {
        this.handler.doHandler(this, arg0);
    }

    /**
     * 继续执行下一个
     */
    void runNext(Object arg0) {
        if (this.next != null) {
            this.next.handler(arg0);
        }
    }
}

// 处理器抽象类
abstract class AbstractHandler {
    /**
     * 处理器，这个处理器就做一件事情，在传入的字符串中增加一个尾巴..
     */
    abstract void doHandler(HandlerChainContext handlerChainContext, Object arg0); // handler方法
}

// 处理器具体实现类
class Handler1 extends AbstractHandler {
    @Override
    void doHandler(HandlerChainContext handlerChainContext, Object arg0) {
        arg0 = arg0.toString() + "..handler1的小尾巴.....";
        System.out.println("我是Handler1的实例，我在处理：" + arg0);
        // 继续执行下一个
        handlerChainContext.runNext(arg0);
    }
}

// 处理器具体实现类
class Handler2 extends AbstractHandler {
    @Override
    void doHandler(HandlerChainContext handlerChainContext, Object arg0) {
        arg0 = arg0.toString() + "..handler2的小尾巴.....";
        System.out.println("我是Handler2的实例，我在处理：" + arg0);
        // 继续执行下一个
        handlerChainContext.runNext(arg0);
    }
}

本质来说，就是定义了一个抽象类，然后具体的处理类实现了这个抽象类中定义的方法，如 AbstractHandler 中的 doHandler 方法。而责任链即表示是一个链式结构，上方的HandlerChainContext 正是起到了这个类似链表的效果，这样的话，就起到了职责“链”的效果了。 即每次执行完HandlerChainContext的AbstractHandler的实现类之后，会判断一下当前的HandlerChainContext 是否为空，不为空则继续执行下一个HandlerChainContext的AbstractHandler的实现类，以此类推。

---

3. Netty中的ChannelPipeline责任链

Netty中的ChannelPipeline责任链

---

4. 入站事件和出站事件

入站事件： 通常只I/O 线程生成入站数据。
(通俗理解:从socket底层自己往上冒上来的事件都是入站)
比如EventLoop收到selector的OP_READ事件，入站处理器调用socketChannel.read(ByteBuffer)接收到数据后，这将导致通道的ChannelPipeline中包含的下一个中的channelRead方法被调用。

出站事件：经常是指I/O 线程执行实际的输出操作。
(通俗理解:想主动往socket底层操作的事件的都是出站)
比如bind方法用意是请求server socket绑定到给定的SocketAddress，这将导致通道的ChannelPipeline中包含的下一个出站处理器中的bind方法被调用。

---

5. Netty 中事件的定义

• inbound 入站事件

  
  
  

  入站事件

• outbound 出站事件

出站事件

---

6. Pipeline中的handler是什么

• ChannelHandler：用于处理I/O事件或拦截I/O操作，并转发到ChannelPipeline中的下一个处理器。
  这个顶级接口定义功能很弱，实际使用时会去实现下面两大子接口：
  处理入站I/O事件的ChannelInboundHandler、处理出站I/O操作的ChannelOutboundHandler

• 适配器类：为了开发方便，避免所有handler去实现一边接口方法，Netty提供了简单的实现类：
  1.ChannelInboundHandlerAdapter处理入站I/O事件
  2.ChannelOutboundHandlerAdapter来处理出站I/O操作
  3.ChannelDuplexHandler来支持同时处理入站和出站事件

• ChannelHandlerContext：实际存储在Pipeline中的对象并非ChannelHandler，而是上下文对象。
  将handler，包裹在上下文对象中，通过上下文对象与它所属的ChannelPipeline交互，向上或向下传递事件或者修改pipeline都是通过上下文对象。

7. 维护Pipeline中的handler

ChannelPipeline是线程安全的，ChannelHandler可以在任何时候添加或删除。
例如，你可以在即将交换敏感信息时插入加密处理程序，并在交换后删除它。
一般操作，初始化的时候增加进去，较少删除。下面是Pipeline中管理handler的API

Pipeline中管理handler的API

---

8. Handler 的执行分析

假设当前的ChannelPipeline中有以下几个Handler

正常来说，入站事件是由下到上的执行顺序，出站事件是由上到下的顺序

---

9. 分析registered 入站事件的处理

---

10. 分析bind出站事件的处理

---

11. 分析accept入站事件的处理

这是一个分配的过程，main Group负责accept，然后分配sub Group负责read

---

12. 分析read入站事件的处理

pipeline分析的关键4要素:什么事件、有哪些处理器、哪些会被触发、执行顺序

---

小结

用户在管道中有一个或多个channelhandler来接收I/O事件(例如读取)和请求I/O操作(例如写入和关闭)。

一个典型的服务器在每个通道的管道中都有以下处理程序，但是根据协议和业务逻辑的复杂性和特征，可能会有所不同:

• 协议解码器 - 将二进制数据(例如ByteBuf)转换为Java对象。
• 协议编码器 - 将Java对象转换为二进制数据。
• 业务逻辑处理程序 - 执行实际的业务逻辑(例如数据库访问)。

责任链设计模式的运用，保证了Netty的高度可拓展性！

---

如果觉得有收获就点个赞吧，更多知识，请点击关注查看我的主页信息哦~