Z
文章
42
分类
25
评论
8

从Tomcat Connector 看透抽象模板设计模式

| 性能调优 •
字数总计 10950 | 阅读时长 27分钟 | 阅读量 8

Connector 组件介绍

Connector 组件作为接收客户端请求并返回响应的核心模块，通过三个高度内聚且松耦合的子组件，实现了网络通信、协议处理与容器交互的高效协作：

  1. Endpoint（端点） - 网络通信管理

    • 负责底层 Socket 连接的生命周期管理，支持 BIO、NIO、NIO2、APR 等多种 I/O 模型

    • 实现对 HTTP、HTTPS、AJP 等协议的传输层支持

    • 通过线程池管理并发连接，优化网络 I/O 性能

  2. Processor（处理器） - 协议解析

    • 解析 HTTP 请求行、请求头、请求体等协议元素

    • 处理 HTTP/1.1、HTTP/2、HTTP/3 等多版本协议的兼容性

    • 验证请求语法，提取 URI、请求方法、参数等关键信息

  3. Adapter（适配器） - 请求对象封装与容器交互

    • 将原始网络数据转换为 Servlet 标准的 HttpServletRequest 对象

    • 解析 Cookie、编码转换、参数映射等应用层处理

    • 作为 Connector 与 Container 的桥梁，将请求分发至 Engine/Host/Context/Servlet 处理链

    • 将 Servlet 响应转换为网络协议格式返回客户端

这三个子组件之间紧密协作，Endpoint 提供数据字节流给 Processor，Processor 将字节流转化为请求对象交给 Adapter，Adapter 再将请求对象适配后传递给 Servlet 容器，它们共同构成了 Connector 组件高效运行的核心机制，确保 Tomcat 能够稳定、高效地处理各种网络请求 。

抽象模板设计模式深度解析

模式定义与原理阐释

抽象模板设计模式是一种行为型设计模式，它定义了一个操作中的算法骨架，将一些步骤延迟到子类中实现 ，使得子类可以在不改变算法整体结构的情况下，重新定义该算法的某些特定步骤。在这个模式中，主要包含两个关键角色 。

  • 抽象模板角色（Abstract Template）：它是整个模式的核心，定义了一个或多个抽象操作，这些抽象操作是顶级逻辑的组成部分，需要由子类来具体实现。同时，抽象模板角色还定义并实现了一个模板方法，这个模板方法通常是具体的，它给出了算法的整体框架，规定了各个步骤的执行顺序，而其中的抽象操作则是算法中可变的部分，会在子类中被具体实现。例如，在一个文件处理系统中，抽象模板类可能定义了读取文件、处理文件内容、保存文件这三个抽象操作，以及一个包含这三个操作执行顺序的模板方法。

  • 具体模板角色（Concrete Template）：具体模板角色是抽象模板角色的子类，它负责实现抽象模板中定义的抽象方法，完成与特定业务相关的功能。每一个抽象模板角色都可以有多个具体模板角色与之对应，不同的具体模板角色通过对抽象方法的不同实现，展现出不同的业务逻辑。例如，在上述文件处理系统中，针对不同类型的文件（如文本文件、图片文件、音频文件），可以分别创建具体的子类来实现读取、处理、保存的具体逻辑，这些子类就是具体模板角色。

抽象模板设计模式的运作原理就像是搭建一座大厦，抽象模板角色制定了大厦的整体结构和施工流程（模板方法），但其中一些具体的施工细节（抽象方法），如使用何种建筑材料、内部装修风格等，留给了具体模板角色来决定。在运行时，客户端通过调用抽象模板的模板方法，触发整个算法流程，而具体的步骤实现则由具体模板角色提供，从而实现了算法的灵活性和可扩展性。

生活中的模式示例

在生活中，抽象模板设计模式的例子比比皆是。以制作蛋糕为例，制作蛋糕的基本流程是相对固定的，就像一个模板。首先需要准备原材料（这是模板方法中的一个步骤），接着搅拌面糊（另一个步骤），然后将面糊倒入模具并放入烤箱烘焙（又一个步骤），最后装饰蛋糕（最后的步骤） 。这个基本流程就是抽象模板中的模板方法。而在制作不同口味的蛋糕时，如巧克力蛋糕、草莓蛋糕、抹茶蛋糕，每个步骤的具体实现会有所不同，这就类似于具体模板角色对抽象方法的实现 。制作巧克力蛋糕时，在准备原材料步骤中，会加入巧克力粉和巧克力块；搅拌面糊时，要充分融合巧克力成分；烘焙时间和温度可能也会根据巧克力的特性进行调整；装饰蛋糕时，会使用巧克力酱和巧克力碎片。而制作草莓蛋糕，准备原材料时会加入新鲜草莓和草莓酱，装饰时则用新鲜草莓切片点缀。虽然具体实现不同，但整个制作蛋糕的流程框架是不变的，这就是抽象模板设计模式在生活中的生动体现，通过固定的流程框架，允许不同的具体实现来满足多样化的需求。

抽象模板设计模式在 Connector 组件中的精彩呈现

模式应用场景探寻

在 Connector 组件中，抽象模板设计模式在多个关键功能模块中有着广泛且深入的应用，其中网络通信处理和请求处理流程这两大模块尤为典型。

在网络通信处理方面，不同的 I/O 模型（如 BIO、NIO、NIO2 等）需要实现底层 Socket 的连接建立、数据读取与写入等操作 。虽然这些操作在不同 I/O 模型下的具体实现方式千差万别，但整体的网络通信流程却存在着相似的框架。例如，都需要经历监听端口、接受连接、处理连接等基本步骤。抽象模板设计模式在这里发挥了巨大的作用，它将这些共性的流程步骤抽象出来，定义在抽象类中，形成模板方法。而具体的 I/O 模型实现类则作为子类，去实现那些与具体 I/O 特性相关的抽象方法，从而实现了不同 I/O 模型在统一框架下的灵活切换与高效运行。

在请求处理流程中，从接收客户端请求到将处理结果返回给客户端，整个过程涉及多个步骤，包括协议解析、请求对象创建、请求转发、响应处理等 。这些步骤构成了一个相对固定的算法骨架，无论处理的是何种类型的请求（HTTP、AJP 等），这个骨架基本保持不变。抽象模板设计模式将这个骨架定义在抽象类中，把其中一些与具体协议相关的处理步骤（如 HTTP 协议解析、AJP 协议解析）定义为抽象方法，由具体的子类来实现。这样，当需要处理新的协议类型时，只需要创建新的子类并实现相应的抽象方法，而无需修改整个请求处理流程的框架，极大地提高了系统的扩展性和可维护性。

类结构

tomcat9.0.55版本中的连接器相关的类结构图如下：

ProtocolHandler 接口：协议处理的顶层接口

作为 Tomcat 协议处理的核心接口，ProtocolHandler定义了网络连接管理的标准行为，例如：生命周期管理、配置参数设置、协议相关配置、连接池相关设置等。

AbstractProtocol 抽象类：模板模式的骨架实现

AbstractProtocol 是 Tomcat 中所有协议处理器的抽象基类，位于 org.apache.coyote 包路径下。它实现了 模板方法模式，定义了协议处理的通用框架实现，比如生命周期管理、对Endpoint、Processor、Adapter的整合等，同时将具体实现细节延迟到子类。

AbstractHttp11Protocol 与 AbstractAjpProtocol抽象协议类：延续模板模式

分别处理 HTTP 和 AJP 协议的语义解析、请求封装，也通过抽象模板实现了协议处理的共性逻辑，同时保留了各自协议的特性。

具体实现类

具体实现类通过组合不同的I/O模型（如NIO、NIO2）和协议（如Http/1.1、AJP），提供了多样化的网络通信方案。

相关源码剖析

以 Tomcat 9.0.55 的源码为例，在 Connector 组件中，AbstractEndpoint类是抽象模板设计模式的典型应用。AbstractEndpoint类定义了一系列抽象方法，如bind、start、stop、serverSocketAccept等 ，这些抽象方法是与具体网络通信实现相关的操作，需要由具体的子类来实现。同时，AbstractEndpoint类还定义了一些模板方法，如init方法，它给出了 Endpoint 初始化的整体流程。

// org.apache.tomcat.util.net.AbstractEndpoint#init

public final void init() throws Exception {
    if (bindOnInit) {
        // 方法内有抽象方法bind()，由子类实现具体的绑定端口的方法
        // 比如NioEndpoint、Nio2Endpoint中分别对bind()方法的实现
        bindWithCleanup();
        bindState = BindState.BOUND_ON_INIT;
    }
    if (this.domain != null) {
        // Register endpoint (as ThreadPool - historical name)
        oname = new ObjectName(domain + ":type=ThreadPool,name=\"" + getName() + "\"");
        Registry.getRegistry(null, null).registerComponent(this, oname, null);

        ObjectName socketPropertiesOname = new ObjectName(domain +
                ":type=SocketProperties,name=\"" + getName() + "\"");
        socketProperties.setObjectName(socketPropertiesOname);
        Registry.getRegistry(null, null).registerComponent(socketProperties, socketPropertiesOname, null);

        for (SSLHostConfig sslHostConfig : findSslHostConfigs()) {
            registerJmx(sslHostConfig);
        }
    }
}

在init方法中，首先会检查bindOnInit属性，如果为true，则调用抽象方法bind来绑定端口 。这里init方法就是模板方法，它规定了初始化的流程框架，而bind方法是抽象方法，其具体实现由子类决定。例如，NioEndpoint类继承自AbstractEndpoint类，它实现了bind方法，在bind方法中，会创建ServerSocketChannel并绑定到指定端口，实现了 NIO 模式下的端口绑定逻辑。

// NioEndpoint对bind方法的实现
// org.apache.tomcat.util.net.NioEndpoint#bind
/**
 * Initialize the endpoint.
 */
@Override
public void bind() throws Exception {
    initServerSocket();
    setStopLatch(new CountDownLatch(1));
    // Initialize SSL if needed
    initialiseSsl();
}

// Nio2Endpoint对bind方法的实现
// org.apache.tomcat.util.net.Nio2Endpoint#bind
/**
 * Initialize the endpoint.
 */
@Override
public void bind() throws Exception {

    // Create worker collection
    if (getExecutor() == null) {
        createExecutor();
    }
    if (getExecutor() instanceof ExecutorService) {
        threadGroup = AsynchronousChannelGroup.withThreadPool((ExecutorService) getExecutor());
    }
    // AsynchronousChannelGroup needs exclusive access to its executor service
    if (!internalExecutor) {
        log.warn(sm.getString("endpoint.nio2.exclusiveExecutor"));
    }

    serverSock = AsynchronousServerSocketChannel.open(threadGroup);
    socketProperties.setProperties(serverSock);
    InetSocketAddress addr = new InetSocketAddress(getAddress(), getPortWithOffset());
    serverSock.bind(addr, getAcceptCount());

    // Initialize SSL if needed
    initialiseSsl();
}

通过这种方式，抽象模板设计模式使得不同的 I/O 模型（如 NIO、NIO2 等）可以在AbstractEndpoint类定义的统一框架下，通过实现各自的抽象方法来完成特定的功能，既保证了代码的复用性，又提高了系统的灵活性和可扩展性。

抽象模板设计模式在 Connector 组件中的优势

代码复用性提升

在 Connector 组件中，抽象模板设计模式显著提升了代码的复用性。通过将网络通信处理和请求处理流程中的通用代码抽象到父类，如AbstractEndpoint类，避免了在不同的 I/O 模型实现类（如NioEndpoint、Nio2Endpoint等）中重复编写相同的代码 。以端口绑定操作为例，虽然不同 I/O 模型下端口绑定的具体实现细节有所不同，但整体的端口绑定概念和基本步骤是一致的。在抽象模板设计模式下，将端口绑定的抽象方法bind定义在AbstractEndpoint类中，具体的实现由子类完成。这样，当需要添加新的 I/O 模型时，只需要创建新的子类继承AbstractEndpoint类，并实现bind方法即可，而无需重新编写整个端口绑定相关的代码框架，大大减少了代码量，提高了开发效率 。

灵活性与可扩展性增强

抽象模板设计模式为 Connector 组件带来了极高的灵活性与可扩展性。由于算法的骨架由抽象类定义，具体的实现细节由子类完成，这使得在不影响整体架构的前提下，方便添加新的协议处理方式或请求处理逻辑 。例如，当 Tomcat 需要支持新的 HTTP/3 协议时，开发人员可以创建一个新的子类继承抽象的Processor类，在这个子类中实现 HTTP/3 协议的解析和处理逻辑。对于请求处理流程，如果需要添加新的预处理步骤，如增加对请求头的额外验证逻辑，只需要在具体的子类中重写相应的抽象方法，添加新的逻辑即可，而不会影响到整个请求处理的框架和其他已有的功能 。这种设计模式使得 Connector 组件能够轻松应对不断变化的网络技术和业务需求，具有很强的适应性和扩展性，为 Tomcat 的持续发展和功能升级提供了有力支持。

系统维护成本降低

在 Connector 组件中应用抽象模板设计模式，也可降低对系统的维护成本。由于通用逻辑被集中在抽象类中，当需要修改这些通用逻辑时，只需要在一处进行修改，而不是在多个子类中逐一修改 。例如，当需要优化网络连接的超时处理逻辑时，只需要在AbstractEndpoint类中对相关的模板方法进行修改，所有继承自AbstractEndpoint类的子类都会自动应用这些修改，大大减少了维护的工作量和出错的可能性。同时，清晰的代码结构和职责划分也使得新加入的开发人员能够更快地理解系统的工作原理和代码逻辑，降低了学习成本，提高了团队协作开发的效率。在系统出现问题时，也更容易定位和解决问题，因为每个类的职责明确，问题的排查范围能够被有效缩小，从而提高了系统的维护效率和稳定性。

总结

抽象模板设计模式在 Tomcat Connector 组件中的应用是 Java 开发中设计模式精妙运用的典型范例。它通过将网络通信和请求处理流程中的共性抽象为模板方法，把可变部分留给子类实现，显著提升了代码的复用性、灵活性与可扩展性 ，同时降低了系统的维护成本。在 Connector 组件的开发中，这种模式使得不同 I/O 模型和协议处理逻辑能够在统一框架下高效运行，有力地保障了 Tomcat 作为 Web 容器的高性能与稳定性。

文章作者： Z
本文链接：
版权声明： 本站所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 微博客！
性能调优
喜欢就支持一下吧