盘点Tomcat中常见的13种设计模式

单例模式全局维护单一对象，适合生命周期长（与应用生命周期相同）、全局访问的对象，避免创建/销毁开销，但为了全局唯一，创建对象时需要使用“同步”的机制；业务中全局共享、生命周期长的组件考虑设计为单例工厂模式根据入参构建对象，屏蔽内部实现细节，常用于构建/复用复杂对象；业务中根据不同参数创建/获取不同实现组件考虑使用工厂适配器模式将原本不兼容的接口转换为期望的接口，提高兼容性，但转换过程存在开销；业务

不会敲代码的谌

939人浏览 · 2024-05-30 13:55:55

不会敲代码的谌 · 2024-05-30 13:55:55 发布

盘点Tomcat中常见的13种设计模式

Tomcat的源码深处蕴含着一系列精妙的设计模式，它们共同支撑起了这个高性能、高灵活性的服务器平台

本文旨在深入探索Tomcat架构的底层逻辑，揭示隐藏其中的13种设计模式，从适配器模式到享元模式，从责任链模式到模板方法模式，我们将一一揭开这些设计模式的神秘面纱，展示它们如何协同工作，成就了Tomcat的稳定与高效

Tomcat设计模式思维导图：

创建型

单例模式

单例模式能够让对象全局唯一共享使用，适合生命周期长（与应用相同）、全局共享访问的对象，减少开销提高利用率

但是为了让对象全局唯一，防止并发访问而导致对象变成“多例”，通常需要使用加锁的方式保证唯一

无论是饿汉式（类加载时synchronized锁），还是懒汉式，都会通过加锁的方式创建对象

单例模式实现的多种方式就不过多赘述，Tomcat中会使用StringManager分离错误信息的存储与处理

StringManager是Tomcat中实现错误消息和日志消息国际化管理的核心组件，使用的是单例模式，通过静态工厂方法获取对象

protected static final StringManager sm = StringManager.getManager(NioChannel.class);

在获取对象时，最终也会加锁防止并发创建对象

public static final synchronized StringManager getManager(
        String packageName, Locale locale) {
    Map<Locale,StringManager> map = managers.get(packageName);
    if (map == null) {
        map = new LinkedHashMap<Locale,StringManager>(LOCALE_CACHE_SIZE, 1, true) {
            private static final long serialVersionUID = 1L;
            @Override
            protected boolean removeEldestEntry(
                    Map.Entry<Locale,StringManager> eldest) {
                if (size() > (LOCALE_CACHE_SIZE - 1)) {
                    return true;
                }
                return false;
            }
        };
        managers.put(packageName, map);
    }
    StringManager mgr = map.get(locale);
    if (mgr == null) {
        mgr = new StringManager(packageName, locale);
        map.put(locale, mgr);
    }
    return mgr;
}

注意：Tomcat中一些如线程池Executor可能不是单例，因为Executor属于Connector连接器，而Tomcat设计上运行存在多连接器，这就可能导致变为多例

如果平时业务中也有负责、全局共享的组件也可以设计为单例

工厂模式

工厂模式能够通过传入一个定义的参数CODE，来获取对应对象实例，无需关心其内部实现

Tomcat中获取日志的日志工厂LogFactory.getLog(StandardContext.class)

获取过滤器链的过滤器链工厂ApplicationFilterFactory.createFilterChain(request, wrapper, servlet)

工厂模式常用于创建复杂对象，根据入参构建复杂对象返回，使用工厂屏蔽内部实现细节

Tomcat中还使用大量的工厂方法进行创建对象，而创建型模式中剩下的建造者模式和原型模式并不常见

结构型

适配器模式

适配器模式能够将接口转换为期望的接口，使得原本不兼容的类可以一起工作，提高兼容性，但转换过程复杂可能会导致开销太大

在Tomcat中，连接器与容器之间会使用适配器对请求/响应进行适配

连接器Connector中的请求/响应是Tomcat定义的org.apache.coyote.Request, org.apache.coyote.Response

而容器中的请求/响应需要遵循servlet规范，要求实现servlet规定的接口org.apache.catalina.connector.implements HttpServletRequest

Tomcat中的CoyoteAdapter作为适配器则来将请求/响应进行适配，提高兼容性

装饰者模式

装饰者模式能够通过组合的方式，动态的给对象添加额外的功能，相比继承会更加灵活

装饰者模式又叫包装器模式，Tomcat中大量使用包装器，给对象多套一层增加功能

比如Tomcat网络通信中曾说到过处理完网络通信将socket封装为 SocketWrapperBase 再去交给线程池处理

其子类NioSocketWrapper在其基础上又增加Nio处理相关功能

public static class NioSocketWrapper extends SocketWrapperBase<NioChannel> {
    private final SynchronizedStack<NioChannel> nioChannels;
    private final Poller poller;
    private int interestOps = 0;
    private volatile SendfileData sendfileData = null;
    private volatile long lastRead = System.currentTimeMillis();
    private volatile long lastWrite = lastRead;
    private final Object readLock;
    private volatile boolean readBlocking = false;
    private final Object writeLock;
    private volatile boolean writeBlocking = false;
}

Nio2SocketWrapper在其基础上增加读写回调相关功能

public static class Nio2SocketWrapper extends SocketWrapperBase<Nio2Channel> {
    private final SynchronizedStack<Nio2Channel> nioChannels;
    private SendfileData sendfileData = null;
    private final CompletionHandler<Integer, ByteBuffer> readCompletionHandler;
    private boolean readInterest = false; // Guarded by readCompletionHandler
    private boolean readNotify = false;
    private final CompletionHandler<Integer, ByteBuffer> writeCompletionHandler;
    private final CompletionHandler<Long, ByteBuffer[]> gatheringWriteCompletionHandler;
    private boolean writeInterest = false; // Guarded by writeCompletionHandler
    private boolean writeNotify = false;
    private CompletionHandler<Integer, SendfileData> sendfileHandler；
}

组合模式

组合模式能够将各个对象组合为树形结构的组件，易于扩展（想加新功能继续组合其他组件）、复用性好、层次清晰

21张图解析Tomcat运行原理与架构全貌中曾分析过Tomcat组件关系，自顶向下可以分为:

Tomcat只能有一个Server，Server下允许存在多个Service，Service中又允许多个Connector和一个Container

Connector和Container中又存在各自的组件，这种就是使用组合模式将各个组件组合为树形结构

外观模式

外观模型对子系统定义一个更高层的接口，使用高层接口简化操作，屏蔽内部实现，相当于中间加一层

前文说过Tomcat中连接器与容器的适配器Adapter会将Tomcat定义org.apache.coyote.Request/Response转化为遵循servlet规范的org.apache.catalina.connector.Request/Response（实现HttpServletRequest/HttpServletResponse接口）

org.apache.catalina.connector.Request内部会使用 org.apache.coyote.Request 来实现servlet规范接口HttpServletRequest

为了屏蔽内部实现，防止使用内部其他细节，使用外观模式中间加一层，我们平常使用的HttpServletRequest都是外观类RequestFacade (RequestFacade implements HttpServletRequest 也实现servlet规范HttpServletRequest接口)

当调用HttpServletRequest接口时，RequestFacade会再去调用org.apache.catalina.connector.Request的实现

（Response同理）

享元模式

享元模式通过“共享”的方式，让对象进行复用，旨在减少频繁创建、销毁对象，减少开销提高性能

线程池、连接池、对象池等池化技术是实现享元模式的方式之一，Tomcat中主要使用线程池、对象池来实现享元模式

线程池用于管理线程，避免频繁创建、销毁线程，减少内核开销，提高性能

对象池用于管理常用的复杂对象，也是避免频繁创建、销毁复杂对象，从而减少GC，提高性能

在享元模式中会把对象共享的与单独变化的数据进行隔离，其中共享的数据叫内部状态，而复用对象时动态变化的数据叫外部状态

那么享元模式有没有什么缺点呢？

说到对象的复用，那么使用对象时，对象中外部状态数据还是上次使用时遗留的数据

因此复用对象时要清理对象这些外部状态的数据，否则会出现脏数据，享元模式的缺点就是需要手动维护外部状态

线程池以前的文章说过，这篇文章就不再说明，感兴趣的同学可以查看Tomcat线程池如何进行扩展？

Tomcat自定义SynchronizedStack数据结构用作对象池，SynchronizedStack的实现比较简单，从名称看就知道是栈，并且使用Synchronized保证多线程下入栈、出栈等方法的原子性

Tomcat中对象池在很多地方进行使用：

SynchronizedStack<NioChannel> nioChannels NioChannel对象池

SynchronizedStack<PollerEvent> eventCache PollerEvent对象池

SynchronizedStack<SocketProcessorBase<S>> processorCache SocketProcessor对象池

SynchronizedStack<Nio2Channel> nioChannels Nio2EndPoint中Nio2Channel对象池

通过源码举几个例子：

在分析Tomcat网络通信源码的文章中曾说到过NioEndPoint

它获取到客户端连接后，会尝试从使用NioChannel对象池拿出NioChannel对象进行复用

NioChannel对象池

在使用前调用reset清除上次对象使用过（动态变化）的数据 （即清理外部状态）

//连接的对象池
private SynchronizedStack<NioChannel> nioChannels;

// Allocate channel and wrapper
NioChannel channel = null;
//对象池不为空从对象池里拿
if (nioChannels != null) {
    channel = nioChannels.pop();
}
//拿到还为空则创建
if (channel == null) {
    SocketBufferHandler bufhandler = new SocketBufferHandler(
            socketProperties.getAppReadBufSize(),
            socketProperties.getAppWriteBufSize(),
            socketProperties.getDirectBuffer());
    if (isSSLEnabled()) {
        channel = new SecureNioChannel(bufhandler, this);
    } else {
        channel = new NioChannel(bufhandler);
    }
}
NioSocketWrapper newWrapper = new NioSocketWrapper(channel, this);
//防止复用到脏数据
channel.reset(socket, newWrapper);

当连接关闭时，再放入对象池中

//EndPoint还在跑
if (getEndpoint().running) {
    //不为空尝试push
    if (nioChannels == null || !nioChannels.push(getSocket())) {
        getSocket().free();
    }
}

使用对象池进行复用时，一般都会reset清理脏数据，防止用到以前的数据导致程序错误

public void reset(SocketChannel channel, NioSocketWrapper socketWrapper) throws IOException {
    this.sc = channel;
    this.socketWrapper = socketWrapper;
    bufHandler.reset();
}

从reset方法也可以看出，NioChannel中的连接SocketChannel、连接包装NioSocketWrapper和bufHandler缓冲池相关是外部状态，需要清理

PollerEvent对象池

在NioEndPoint与Poller进行通信时，封装PollerEvent也会使用到对象池

//PollerEvent对象池
private SynchronizedStack<PollerEvent> eventCache;

private PollerEvent createPollerEvent(NioSocketWrapper socketWrapper, int interestOps) {
    PollerEvent r = null;
    if (eventCache != null) {
        r = eventCache.pop();
    }
    //为空就创建，复用就reset
    if (r == null) {
        r = new PollerEvent(socketWrapper, interestOps);
    } else {
        r.reset(socketWrapper, interestOps);
    }
    return r;
}

当Poller在event（将连接注册到selector上）使用完后，又把对象返回池中

if (running && eventCache != null) {
    pe.reset();
    eventCache.push(pe);
}

Tomcat中的对象池为了复用对象，还需要使用同步手段（Synchronized）来保证原子性，从而会导致一些性能开销

思考：有没有又能复用对象，又不需要使用同步手段的方式呢？

如果让我们来实现，能否使用线程局部变量ThreadLocal来实现对象池呢？

比如 mybatis使用sqlsession

public class SqlSessionManager implements SqlSessionFactory, SqlSession {
  private final SqlSessionFactory sqlSessionFactory;
  private final SqlSession sqlSessionProxy;
  private final ThreadLocal<SqlSession> localSqlSession = new ThreadLocal<>();
}

这样就不涉及多线程操作，不需要使用同步手段，避免这部分的开销；但是每个线程占用的空间都会变大，由于对象池存在每个线程上，也不太方便进行管理

如果平时某个业务GC比较频繁，可以看看是不是频繁创建、销毁复杂对象导致的，如果复杂对象能将固定、动态变化的数据分离，考虑使用享元模式

行为型

责任链模式

责任链模式将处理者串联成链，请求只需要交给责任链上的第一个处理者，依次被处理者进行处理，对于请求者无需关心处理者是谁，并且处理者只需要关心自己要处理的那部分，无法处理就交给下一个处理者

前文曾经说过在多级容器的调用链路中每个容器都使用职责链模式

Pipeline接口为职责链中的管道，Valve接口为管道中负责处理的节点，其中作为Basic的Valve将会去调用下一级容器

包括最后执行的过滤器链也是责任链模式

业务上如果有需要进行一系列的操作/验证也可以考虑使用责任链模式

命令模式

命令模式将请求命令与执行命令分离，对两者进行解耦，提高灵活/扩展性

Processor解析请求向Container容器请求可以看作命令模式，其中Processor为请求命令，容器为处理命令

针对不同的协议HTTP1.1、APR、HTTP2.0，不同的Processor实现类（Http11Processor/AjpProcessor/StreamProcessor）相当于不同命令

迭代器模式

迭代器模式提供方法访问集合中的元素，而不暴露集合内部元素，封装性好（无需关心内部实现），灵活性高（可以提过多种迭代顺序）

Tomcat触发生命周期的事件时就会去通过增强for循环调用监听器（增强for循环就是使用的迭代器）

LifecycleEvent event = new LifecycleEvent(this, type, data);
for (LifecycleListener listener : lifecycleListeners) {
    listener.lifecycleEvent(event);
}

迭代器模式是业务开发最常见的模式（增强for），可能平时没怎么注意

观察者模式

观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新

前文说过，Tomcat中使用监听器来实现观察者模式，生命周期的监听器，当生命周期事件发生时通知所有监听器

protected void fireLifecycleEvent(String type, Object data) {
    LifecycleEvent event = new LifecycleEvent(this, type, data);
    //观察者+迭代器
    for (LifecycleListener listener : lifecycleListeners) {
        listener.lifecycleEvent(event);
    }
}

在通知观察者时常用迭代器模式进行通知

当业务中需要进行监听时可以考虑观察者模式

策略模式

策略模式定义多种不同的算法，算法之间可以互相替换，使用算法无需关心实现，提高扩展性

策略模式在Tomcat中可以广义理解为具有不同的实现策略

比如前文说过网络通信时实现的IO模型：APR、NIO、NIO2，在面对不同场景时可以使用不同的实现策略进行替换

将来如果新出了什么IO模型则又可以增加一种实现策略，在对应场景时进行替换

在业务开发中如果某块需求动态变化的情况多，要考虑扩展性，可以考虑策略模式

模板方法模式

模板方法模式常用于定义算法骨架，用来实现固定的流程，而动态变化的流程往往通过策略模式中的算法来实现

处理完网络通信向后执行时，调用抽象父类AbstractEndpoint.processSocket的模板方法，无需关心SocketProcessorBase的实现是NIO、NIO2还是APR

public boolean processSocket(SocketWrapperBase<S> socketWrapper,
        SocketEvent event, boolean dispatch) {
        if (socketWrapper == null) {
            return false;
        }
        //不同的算法实现
        SocketProcessorBase<S> sc = null;
        if (processorCache != null) {
            sc = processorCache.pop();
        }
        if (sc == null) {
            sc = createSocketProcessor(socketWrapper, event);
        } else {
            sc.reset(socketWrapper, event);
        }
        
        //调用后续执行
        Executor executor = getExecutor();
        if (dispatch && executor != null) {
            executor.execute(sc);
        } else {
            sc.run();
        }
    return true;
}

模板方法常用于抽象父类中，用于定义通用且固定的流程，业务开发中结合策略模式一起使用