共计 25657 个字符，预计需要花费 65 分钟才能阅读完成。
Tomcat 倒退这么多年，曾经比拟成熟稳固。在现在『追新求快』的时代，Tomcat 作为 Java Web 开发必备的工具仿佛变成了『相熟的陌生人』，难道说现在就没有必要深刻学习它了么？学习它咱们又有什么播种呢？
静下心来，细细品味经典的开源作品。晋升咱们的「内功」，具体来说就是学习大牛们如何设计、架构一个中间件零碎，并且让这些教训为我所用。
美妙的事物往往是整洁而优雅的。但这并不等于简略，而是要将简单的零碎分解成一个个小模块，并且各个模块的职责划分也要清晰正当。
与此相反的是凌乱无序，比方你看到城中村一堆相互纠缠在一起的电线，可能会感到不适。保护的代码一个类几千行、一个办法好几百行。办法之间互相耦合糅杂在一起，你可能会说 what the f*k！
学习目标
把握 Tomcat 架构设计与原理进步内功
宏观上看
Tomcat 作为一个「Http 服务器 + Servlet 容器」，对咱们屏蔽了应用层协定和网络通信细节，给咱们的是规范的 Request 和 Response 对象；对于具体的业务逻辑则作为变动点，交给咱们来实现。咱们应用了SpringMVC 之类的框架，可是却从来不须要思考 TCP 连贯、Http 协定的数据处理与响应。就是因为 Tomcat 曾经为咱们做好了这些，咱们只须要关注每个申请的具体业务逻辑。
宏观上看
Tomcat 外部也隔离了变动点与不变点，应用了组件化设计，目标就是为了实现「俄罗斯套娃式」的高度定制化（组合模式），而每个组件的生命周期治理又有一些共性的货色，则被提取进去成为接口和抽象类，让具体子类实现变动点，也就是模板办法设计模式。
当今风行的微服务也是这个思路，依照性能将单体利用拆成「微服务」，拆分过程要将共性提取进去，而这些共性就会成为外围的根底服务或者通用库。「中台」思维亦是如此。
设计模式往往就是封装变动的一把利器，正当的使用设计模式能让咱们的代码与零碎设计变得优雅且整洁。
这就是学习优良开源软件能取得的「内功」，从不会过期，其中的设计思维与哲学才是基本之道。从中借鉴设计教训，正当使用设计模式封装变与不变，更能从它们的源码中吸取教训，晋升本人的零碎设计能力。
宏观了解一个申请如何与 Spring 分割起来
在工作过程中，咱们对 Java 语法曾经很相熟了，甚至「背」过一些设计模式，用过很多 Web 框架，然而很少有机会将他们用到理论我的项目中，让本人独立设计一个零碎仿佛也是依据需要一个个 Service 实现而已。脑子里仿佛没有一张 Java Web 开发全景图，比方我并不知道浏览器的申请是怎么跟 Spring 中的代码分割起来的。
为了冲破这个瓶颈，为何不站在伟人的肩膀上学习优良的开源零碎，看大牛们是如何思考这些问题。
学习 Tomcat 的原理，我发现 Servlet 技术是 Web 开发的原点，简直所有的 Java Web 框架（比方 Spring）都是基于 Servlet 的封装，Spring 利用自身就是一个 Servlet（DispatchSevlet），而 Tomcat 和 Jetty 这样的 Web 容器，负责加载和运行 Servlet。如图所示：
晋升本人的零碎设计能力
学习 Tomcat，我还发现用到不少 Java 高级技术，比方 Java 多线程并发编程、Socket 网络编程以及反射等。之前也只是理解这些技术，为了面试也背过一些题。然而总感觉「晓得」与会用之间存在一道沟壑，通过对 Tomcat 源码学习，我学会了什么场景去应用这些技术。
还有就是零碎设计能力，比方面向接口编程、组件化组合模式、骨架抽象类、一键式启停、对象池技术以及各种设计模式，比方模板办法、观察者模式、责任链模式等，之后我也开始模拟它们并把这些设计思维使用到理论的工作中。
关注公众号“码哥字节”更多硬核等你解锁
整体架构设计
明天咱们就来一步一步剖析 Tomcat 的设计思路，一方面咱们能够学到 Tomcat 的总体架构，学会从宏观上怎么去设计一个简单零碎，怎么设计顶层模块，以及模块之间的关系；另一方面也为咱们深刻学习 Tomcat 的工作原理打下基础。
Tomcat 启动流程：startup.sh -> catalina.sh start ->java -jar org.apache.catalina.startup.Bootstrap.main()
Tomcat 实现的 2 个外围性能：
- 解决
Socket连贯，负责网络字节流与Request和Response对象的转化。 - 加载并治理
Servlet，以及解决具体的Request申请。
所以 Tomcat 设计了两个外围组件连接器（Connector）和容器（Container）。连接器负责对外交换，容器负责外部 解决
Tomcat为了实现反对多种 I/O 模型和应用层协定，一个容器可能对接多个连接器，就好比一个房间有多个门。
- Server 对应的就是一个 Tomcat 实例。
- Service 默认只有一个，也就是一个 Tomcat 实例默认一个 Service。
- Connector：一个 Service 可能多个 连接器，承受不同连贯协定。
- Container: 多个连接器对应一个容器，顶层容器其实就是 Engine。
每个组件都有对应的生命周期，须要启动，同时还要启动本人外部的子组件，比方一个 Tomcat 实例蕴含一个 Service，一个 Service 蕴含多个连接器和一个容器。而一个容器蕴含多个 Host，Host 外部可能有多个 Contex t 容器，而一个 Context 也会蕴含多个 Servlet，所以 Tomcat 利用组合模式治理组件每个组件，看待过个也想看待单个组一样看待。整体上每个组件设计就像是「俄罗斯套娃」一样。
连接器
在开始讲连接器前，我先铺垫一下 Tomcat反对的多种 I/O 模型和应用层协定。
Tomcat反对的 I/O 模型有：
NIO：非阻塞I/O，采纳Java NIO类库实现。NIO2：异步I/O，采纳JDK 7最新的NIO2类库实现。APR：采纳Apache可移植运行库实现，是C/C++编写的本地库。
Tomcat 反对的应用层协定有：
HTTP/1.1：这是大部分 Web 利用采纳的拜访协定。AJP：用于和 Web 服务器集成（如 Apache）。HTTP/2：HTTP 2.0 大幅度的晋升了 Web 性能。
所以一个容器可能对接多个连接器。连接器对 Servlet 容器屏蔽了网络协议与 I/O 模型的区别，无论是 Http 还是 AJP，在容器中获取到的都是一个规范的 ServletRequest 对象。
细化连接器的性能需要就是：
- 监听网络端口。
- 承受网络连接申请。
- 读取申请网络字节流。
- 依据具体应用层协定（
HTTP/AJP）解析字节流，生成对立的Tomcat Request对象。 - 将
Tomcat Request对象转成规范的ServletRequest。 - 调用
Servlet容器，失去ServletResponse。 - 将
ServletResponse转成Tomcat Response对象。 - 将
Tomcat Response转成网络字节流。 - 将响应字节流写回给浏览器。
需要列分明后，咱们要思考的下一个问题是，连接器应该有哪些子模块？优良的模块化设计应该思考 高内聚、低耦合。
- 高内聚 是指相关度比拟高的性能要尽可能集中，不要扩散。
- 低耦合 是指两个相干的模块要尽可能减少依赖的局部和升高依赖的水平，不要让两个模块产生强依赖。
咱们发现连接器须要实现 3 个 高内聚 的性能：
- 网络通信。
- 应用层协定解析。
Tomcat Request/Response与ServletRequest/ServletResponse的转化。
因而 Tomcat 的设计者设计了 3 个组件来实现这 3 个性能，别离是 EndPoint、Processor 和 Adapter。
网络通信的 I/O 模型是变动的, 应用层协定也是变动的，然而整体的解决逻辑是不变的，EndPoint 负责提供字节流给 Processor，Processor负责提供 Tomcat Request 对象给 Adapter，Adapter负责提供 ServletRequest对象给容器。
封装变与不变
因而 Tomcat 设计了一系列形象基类来 封装这些稳固的局部 ，形象基类 AbstractProtocol 实现了 ProtocolHandler接口。每一种应用层协定有本人的形象基类，比方 AbstractAjpProtocol和 AbstractHttp11Protocol，具体协定的实现类扩大了协定层形象基类。
这就是模板办法设计模式的使用。
总结下来，连接器的三个外围组件 Endpoint、Processor和 Adapter来别离做三件事件，其中 Endpoint和 Processor放在一起形象成了 ProtocolHandler组件，它们的关系如下图所示。
ProtocolHandler 组件
次要解决 网络连接 和 应用层协定，蕴含了两个重要部件 EndPoint 和 Processor，两个组件组合造成 ProtocoHandler，上面我来具体介绍它们的工作原理。
EndPoint
EndPoint是通信端点，即通信监听的接口，是具体的 Socket 接管和发送处理器，是对传输层的形象，因而 EndPoint是用来实现 TCP/IP 协定数据读写的，实质调用操作系统的 socket 接口。
EndPoint是一个接口，对应的形象实现类是 AbstractEndpoint，而 AbstractEndpoint的具体子类，比方在 NioEndpoint和 Nio2Endpoint中，有两个重要的子组件：Acceptor和 SocketProcessor。
其中 Acceptor 用于监听 Socket 连贯申请。SocketProcessor用于解决 Acceptor 接管到的 Socket申请，它实现 Runnable接口，在 Run办法里调用应用层协定解决组件 Processor 进行解决。为了进步解决能力，SocketProcessor被提交到线程池来执行。
咱们晓得，对于 Java 的多路复用器的应用，无非是两步：
- 创立一个 Seletor，在它身上注册各种感兴趣的事件，而后调用 select 办法，期待感兴趣的事件产生。
- 感兴趣的事件产生了，比方能够读了，这时便创立一个新的线程从 Channel 中读数据。
在 Tomcat 中 NioEndpoint 则是 AbstractEndpoint 的具体实现，外面组件尽管很多，然而解决逻辑还是后面两步。它一共蕴含 LimitLatch、Acceptor、Poller、SocketProcessor和 Executor 共 5 个组件，别离分工合作实现整个 TCP/IP 协定的解决。
- LimitLatch 是连贯控制器，它负责管制最大连接数，NIO 模式下默认是 10000，达到这个阈值后，连贯申请被回绝。
Acceptor跑在一个独自的线程里，它在一个死循环里调用accept办法来接管新连贯，一旦有新的连贯申请到来，accept办法返回一个Channel对象，接着把Channel对象交给 Poller 去解决。Poller的实质是一个Selector，也跑在独自线程里。Poller在外部保护一个Channel数组，它在一个死循环里一直检测Channel的数据就绪状态，一旦有Channel可读，就生成一个SocketProcessor工作对象扔给Executor去解决。- SocketProcessor 实现了 Runnable 接口，其中 run 办法中的
getHandler().process(socketWrapper, SocketEvent.CONNECT_FAIL);代码则是获取 handler 并执行解决 socketWrapper，最初通过 socket 获取适合应用层协定处理器，也就是调用 Http11Processor 组件来解决申请。Http11Processor 读取 Channel 的数据来生成 ServletRequest 对象，Http11Processor 并不是间接读取 Channel 的。这是因为 Tomcat 反对同步非阻塞 I/O 模型和异步 I/O 模型，在 Java API 中，相应的 Channel 类也是不一样的，比方有 AsynchronousSocketChannel 和 SocketChannel，为了对 Http11Processor 屏蔽这些差别，Tomcat 设计了一个包装类叫作 SocketWrapper，Http11Processor 只调用 SocketWrapper 的办法去读写数据。 Executor就是线程池，负责运行SocketProcessor工作类，SocketProcessor的run办法会调用Http11Processor来读取和解析申请数据。咱们晓得，Http11Processor是应用层协定的封装，它会调用容器取得响应，再把响应通过Channel写出。
工作流程如下所示：
Processor
Processor 用来实现 HTTP 协定，Processor 接管来自 EndPoint 的 Socket，读取字节流解析成 Tomcat Request 和 Response 对象，并通过 Adapter 将其提交到容器解决，Processor 是对应用层协定的形象。
从图中咱们看到，EndPoint 接管到 Socket 连贯后，生成一个 SocketProcessor 工作提交到线程池去解决，SocketProcessor 的 Run 办法会调用 HttpProcessor 组件去解析应用层协定，Processor 通过解析生成 Request 对象后，会调用 Adapter 的 Service 办法，办法外部通过 以下代码将申请传递到容器中。
// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);Adapter 组件
因为协定的不同，Tomcat 定义了本人的 Request 类来寄存申请信息，这里其实体现了面向对象的思维。然而这个 Request 不是规范的 ServletRequest，所以不能间接应用 Tomcat 定义 Request 作为参数间接容器。
Tomcat 设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典使用，连接器调用 CoyoteAdapter 的 Sevice 办法，传入的是 Tomcat Request 对象，CoyoteAdapter负责将 Tomcat Request 转成 ServletRequest，再调用容器的 Service办法。
容器
连接器负责内部交换，容器负责外部解决。具体来说就是，连接器解决 Socket 通信和应用层协定的解析，失去 Servlet申请；而容器则负责解决 Servlet申请。
容器：顾名思义就是拿来装货色的，所以 Tomcat 容器就是拿来装载 Servlet。
Tomcat 设计了 4 种容器，别离是 Engine、Host、Context和 Wrapper。Server 代表 Tomcat 实例。
要留神的是这 4 种容器不是平行关系，属于父子关系，如下图所示：
你可能会问，为啥要设计这么多层次的容器，这不是减少复杂度么？其实这背地的思考是，Tomcat 通过一种分层的架构，使得 Servlet 容器具备很好的灵活性。因为这里正好合乎一个 Host 多个 Context，一个 Context 也蕴含多个 Servlet，而每个组件都须要对立生命周期治理，所以组合模式设计这些容器
Wrapper 示意一个 Servlet，Context 示意一个 Web 应用程序，而一个 Web 程序可能有多个 Servlet；Host 示意一个虚拟主机，或者说一个站点，一个 Tomcat 能够配置多个站点（Host）；一个站点（Host）能够部署多个 Web 利用；Engine 代表 引擎，用于治理多个站点（Host），一个 Service 只能有 一个 Engine。
可通过 Tomcat 配置文件加深对其档次关系了解。
<Server port="8005" shutdown="SHUTDOWN"> // 顶层组件，可蕴含多个 Service，代表一个 Tomcat 实例
<Service name="Catalina"> // 顶层组件，蕴含一个 Engine，多个连接器
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> // 连接器
// 容器组件：一个 Engine 解决 Service 所有申请，蕴含多个 Host
<Engine name="Catalina" defaultHost="localhost">
// 容器组件：解决指定 Host 下的客户端申请，可蕴含多个 Context
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
// 容器组件：解决特定 Context Web 利用的所有客户端申请
<Context></Context>
</Host>
</Engine>
</Service>
</Server>如何治理这些容器？咱们发现容器之间具备父子关系，造成一个树形构造，是不是想到了设计模式中的 组合模式。
Tomcat 就是用组合模式来治理这些容器的。具体实现办法是，所有容器组件都实现了 Container接口，因而组合模式能够使得用户对单容器对象和组合容器对象的应用具备一致性 。这里单容器对象指的是最底层的 Wrapper，组合容器对象指的是下面的 Context、Host 或者 Engine。Container 接口定义如下：
public interface Container extends Lifecycle {public void setName(String name);
public Container getParent();
public void setParent(Container container);
public void addChild(Container child);
public void removeChild(Container child);
public Container findChild(String name);
}咱们看到了 getParent、SetParent、addChild 和 removeChild等办法，这里正好验证了咱们说的组合模式。咱们还看到 Container接口拓展了 Lifecycle，Tomcat 就是通过 Lifecycle 对立治理所有容器的组件的生命周期。通过组合模式治理所有容器，拓展 Lifecycle 实现对每个组件的生命周期治理，Lifecycle 次要蕴含的办法init()、start()、stop() 和 destroy()。
申请定位 Servlet 的过程
一个申请是如何定位到让哪个 Wrapper 的 Servlet 解决的？答案是，Tomcat 是用 Mapper 组件来实现这个工作的。
Mapper 组件的性能就是将用户申请的 URL 定位到一个 Servlet，它的工作原理是：Mapper组件里保留了 Web 利用的配置信息，其实就是 容器组件与拜访门路的映射关系 ，比方 Host 容器里配置的域名、Context容器里的 Web利用门路，以及 Wrapper容器里 Servlet 映射的门路，你能够设想这些配置信息就是一个多层次的 Map。
当一个申请到来时，Mapper 组件通过解析申请 URL 里的域名和门路，再到本人保留的 Map 里去查找，就能定位到一个 Servlet。请你留神，一个申请 URL 最初只会定位到一个 Wrapper容器，也就是一个 Servlet。
如果有用户拜访一个 URL，比方图中的http://user.shopping.com:8080/order/buy，Tomcat 如何将这个 URL 定位到一个 Servlet 呢？
- 首先依据协定和端口号确定 Service 和 Engine。Tomcat 默认的 HTTP 连接器监听 8080 端口、默认的 AJP 连接器监听 8009 端口。下面例子中的 URL 拜访的是 8080 端口，因而这个申请会被 HTTP 连接器接管，而一个连接器是属于一个 Service 组件的，这样 Service 组件就确定了。咱们还晓得一个 Service 组件里除了有多个连接器，还有一个容器组件，具体来说就是一个 Engine 容器，因而 Service 确定了也就意味着 Engine 也确定了。
- 依据域名选定 Host。 Service 和 Engine 确定后，Mapper 组件通过 URL 中的域名去查找相应的 Host 容器，比方例子中的 URL 拜访的域名是
user.shopping.com，因而 Mapper 会找到 Host2 这个容器。 - 依据 URL 门路找到 Context 组件。 Host 确定当前，Mapper 依据 URL 的门路来匹配相应的 Web 利用的门路，比方例子中拜访的是 /order，因而找到了 Context4 这个 Context 容器。
- 依据 URL 门路找到 Wrapper（Servlet）。 Context 确定后，Mapper 再依据 web.xml 中配置的 Servlet 映射门路来找到具体的 Wrapper 和 Servlet。
连接器中的 Adapter 会调用容器的 Service 办法来执行 Servlet，最先拿到申请的是 Engine 容器，Engine 容器对申请做一些解决后，会把申请传给本人子容器 Host 持续解决，顺次类推，最初这个申请会传给 Wrapper 容器，Wrapper 会调用最终的 Servlet 来解决。那么这个调用过程具体是怎么实现的呢？答案是应用 Pipeline-Valve 管道。
Pipeline-Valve 是责任链模式，责任链模式是指在一个申请解决的过程中有很多解决者顺次对申请进行解决，每个解决者负责做本人相应的解决，解决完之后将再调用下一个解决者持续解决，Valve 示意一个解决点（也就是一个解决阀门），因而 invoke办法就是来解决申请的。
public interface Valve {public Valve getNext();
public void setNext(Valve valve);
public void invoke(Request request, Response response)
}持续看 Pipeline 接口
public interface Pipeline {public void addValve(Valve valve);
public Valve getBasic();
public void setBasic(Valve valve);
public Valve getFirst();}Pipeline中有 addValve办法。Pipeline 中保护了 Valve链表，Valve能够插入到 Pipeline中，对申请做某些解决。咱们还发现 Pipeline 中没有 invoke 办法，因为整个调用链的触发是 Valve 来实现的，Valve实现本人的解决后，调用 getNext.invoke() 来触发下一个 Valve 调用。
其实每个容器都有一个 Pipeline 对象，只有触发了这个 Pipeline 的第一个 Valve，这个容器里 Pipeline中的 Valve 就都会被调用到。然而，不同容器的 Pipeline 是怎么链式触发的呢，比方 Engine 中 Pipeline 须要调用上层容器 Host 中的 Pipeline。
这是因为 Pipeline中还有个 getBasic办法。这个 BasicValve处于 Valve链表的末端，它是 Pipeline中必不可少的一个 Valve，负责调用上层容器的 Pipeline 里的第一个 Valve。
整个过程分是通过连接器中的 CoyoteAdapter 触发，它会调用 Engine 的第一个 Valve：
@Override
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res) {
// 省略其余代码
// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
...
}Wrapper 容器的最初一个 Valve 会创立一个 Filter 链，并调用 doFilter() 办法，最终会调到 Servlet的 service办法。
后面咱们不是讲到了 Filter，仿佛也有类似的性能，那 Valve 和 Filter有什么区别吗？它们的区别是：
Valve是Tomcat的公有机制，与 Tomcat 的基础架构API是紧耦合的。Servlet API是私有的规范，所有的 Web 容器包含 Jetty 都反对 Filter 机制。- 另一个重要的区别是
Valve工作在 Web 容器级别，拦挡所有利用的申请；而Servlet Filter工作在利用级别，只能拦挡某个Web利用的所有申请。如果想做整个Web容器的拦截器，必须通过Valve来实现。
Lifecycle 生命周期
后面咱们看到 Container容器 继承了 Lifecycle 生命周期。如果想让一个零碎可能对外提供服务，咱们须要创立、组装并启动这些组件；在服务进行的时候，咱们还须要开释资源，销毁这些组件，因而这是一个动静的过程。也就是说，Tomcat 须要动静地治理这些组件的生命周期。
如何对立治理组件的创立、初始化、启动、进行和销毁？如何做到代码逻辑清晰？如何不便地增加或者删除组件？如何做到组件启动和进行不脱漏、不反复？
一键式启停：LifeCycle 接口
设计就是要找到零碎的变动点和不变点。这里的不变点就是每个组件都要经验创立、初始化、启动这几个过程，这些状态以及状态的转化是不变的。而变动点是每个具体组件的初始化办法，也就是启动办法是不一样的。
因而，Tomcat 把不变点形象进去成为一个接口，这个接口跟生命周期无关，叫作 LifeCycle。LifeCycle 接口里定义这么几个办法：init()、start()、stop() 和 destroy()，每个具体的组件（也就是容器）去实现这些办法。
在父组件的 init() 办法里须要创立子组件并调用子组件的 init() 办法。同样，在父组件的 start()办法里也须要调用子组件的 start() 办法，因而调用者能够无差别的调用各组件的 init() 办法和 start() 办法，这就是 组合模式 的应用，并且只有调用最顶层组件，也就是 Server 组件的 init()和start() 办法，整个 Tomcat 就被启动起来了。所以 Tomcat 采取组合模式治理容器，容器继承 LifeCycle 接口，这样就能够向针对单个对象一样一键治理各个容器的生命周期，整个 Tomcat 就启动起来。
可扩展性：LifeCycle 事件
咱们再来思考另一个问题，那就是零碎的可扩展性。因为各个组件init() 和 start() 办法的具体实现是复杂多变的，比方在 Host 容器的启动办法里须要扫描 webapps 目录下的 Web 利用，创立相应的 Context 容器，如果未来须要减少新的逻辑，间接批改start() 办法？这样会违反开闭准则，那如何解决这个问题呢？开闭准则说的是为了扩大零碎的性能，你不能间接批改零碎中已有的类，然而你能够定义新的类。
组件的 init() 和 start() 调用是由它的父组件的状态变动触发的，下层组件的初始化会触发子组件的初始化，下层组件的启动会触发子组件的启动，因而咱们把组件的生命周期定义成一个个状态，把状态的转变看作是一个事件。而事件是有监听器的，在监听器里能够实现一些逻辑，并且监听器也能够不便的增加和删除 ，这就是典型的 观察者模式。
以下就是 Lyfecycle 接口的定义:
重用性：LifeCycleBase 形象基类
再次看到形象模板设计模式。
有了接口，咱们就要用类去实现接口。一般来说实现类不止一个，不同的类在实现接口时往往会有一些雷同的逻辑，如果让各个子类都去实现一遍，就会有反复代码。那子类如何重用这部分逻辑呢？其实就是定义一个基类来实现独特的逻辑，而后让各个子类去继承它，就达到了重用的目标。
Tomcat 定义一个基类 LifeCycleBase 来实现 LifeCycle 接口，把一些公共的逻辑放到基类中去，比方生命状态的转变与保护、生命事件的触发以及监听器的增加和删除等，而子类就负责实现本人的初始化、启动和进行等办法。
public abstract class LifecycleBase implements Lifecycle{
// 持有所有的观察者
private final List<LifecycleListener> lifecycleListeners = new CopyOnWriteArrayList<>();
/**
* 公布事件
*
* @param type Event type
* @param data Data associated with event.
*/
protected void fireLifecycleEvent(String type, Object data) {LifecycleEvent event = new LifecycleEvent(this, type, data);
for (LifecycleListener listener : lifecycleListeners) {listener.lifecycleEvent(event);
}
}
// 模板办法定义整个启动流程，启动所有容器
@Override
public final synchronized void init() throws LifecycleException {
//1. 状态查看
if (!state.equals(LifecycleState.NEW)) {invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
//2. 触发 INITIALIZING 事件的监听器
setStateInternal(LifecycleState.INITIALIZING, null, false);
// 3. 调用具体子类的初始化办法
initInternal();
// 4. 触发 INITIALIZED 事件的监听器
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {ExceptionUtils.handleThrowable(t);
setStateInternal(LifecycleState.FAILED, null, false);
throw new LifecycleException(sm.getString("lifecycleBase.initFail",toString()), t);
}
}
}Tomcat 为了实现一键式启停以及优雅的生命周期治理，并思考到了可扩展性和可重用性，将面向对象思维和设计模式施展到了极致，Containaer接口保护了容器的父子关系，Lifecycle 组合模式实现组件的生命周期保护，生命周期每个组件有变与不变的点，使用模板办法模式。别离使用了 组合模式、观察者模式、骨架抽象类和模板办法。
如果你须要保护一堆具备父子关系的实体，能够思考应用组合模式。
观察者模式听起来“高大上”，其实就是当一个事件产生后，须要执行一连串更新操作。实现了低耦合、非侵入式的告诉与更新机制。
Container 继承了 LifeCycle，StandardEngine、StandardHost、StandardContext 和 StandardWrapper 是相应容器组件的具体实现类，因为它们都是容器，所以继承了 ContainerBase 形象基类，而 ContainerBase 实现了 Container 接口，也继承了 LifeCycleBase 类，它们的生命周期治理接口和性能接口是离开的，这也合乎设计中 接口拆散的准则。
Tomcat 为何突破双亲委派机制
双亲委派
咱们晓得 JVM的类加载器加载 Class 的时候基于双亲委派机制，也就是会将加载交给本人的父加载器加载，如果 父加载器为空则查找Bootstrap 是否加载过，当无奈加载的时候才让本人加载。JDK 提供一个抽象类 ClassLoader，这个抽象类中定义了三个要害办法。对外应用loadClass(String name) 用于子类重写突破双亲委派：loadClass(String name, boolean resolve)
public Class<?> loadClass(String name) throws ClassNotFoundException {return loadClass(name, false);
}
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{synchronized (getClassLoadingLock(name)) {
// 查找该 class 是否曾经被加载过
Class<?> c = findLoadedClass(name);
// 如果没有加载过
if (c == null) {
// 委托给父加载器去加载，递归调用
if (parent != null) {c = parent.loadClass(name, false);
} else {
// 如果父加载器为空，查找 Bootstrap 是否加载过
c = findBootstrapClassOrNull(name);
}
// 若果仍然加载不到，则调用本人的 findClass 去加载
if (c == null) {c = findClass(name);
}
}
if (resolve) {resolveClass(c);
}
return c;
}
}
protected Class<?> findClass(String name){
//1. 依据传入的类名 name，到在特定目录上来寻找类文件，把.class 文件读入内存
...
//2. 调用 defineClass 将字节数组转成 Class 对象
return defineClass(buf, off, len)；}
// 将字节码数组解析成一个 Class 对象，用 native 办法实现
protected final Class<?> defineClass(byte[] b, int off, int len){...}JDK 中有 3 个类加载器，另外你也能够自定义类加载器，它们的关系如下图所示。
BootstrapClassLoader是启动类加载器，由 C 语言实现，用来加载JVM启动时所须要的外围类，比方rt.jar、resources.jar等。ExtClassLoader是扩大类加载器，用来加载\jre\lib\ext目录下 JAR 包。AppClassLoader是零碎类加载器，用来加载classpath下的类，应用程序默认用它来加载类。- 自定义类加载器，用来加载自定义门路下的类。
这些类加载器的工作原理是一样的，区别是它们的加载门路不同，也就是说 findClass这个办法查找的门路不同。双亲委托机制是为了保障一个 Java 类在 JVM 中是惟一的，如果你不小心写了一个与 JRE 外围类同名的类，比方 Object类，双亲委托机制能保障加载的是 JRE里的那个 Object类，而不是你写的 Object类。这是因为 AppClassLoader在加载你的 Object 类时，会委托给 ExtClassLoader去加载，而 ExtClassLoader又会委托给 BootstrapClassLoader，BootstrapClassLoader发现自己曾经加载过了 Object类，会间接返回，不会去加载你写的 Object类。咱们最多只能 获取到 ExtClassLoader这里留神下。
Tomcat 热加载
Tomcat 实质是通过一个后盾线程做周期性的工作，定期检测类文件的变动，如果有变动就从新加载类。咱们来看 ContainerBackgroundProcessor具体是如何实现的。
protected class ContainerBackgroundProcessor implements Runnable {
@Override
public void run() {
// 请留神这里传入的参数是 "宿主类" 的实例
processChildren(ContainerBase.this);
}
protected void processChildren(Container container) {
try {
//1. 调用以后容器的 backgroundProcess 办法。container.backgroundProcess();
//2. 遍历所有的子容器，递归调用 processChildren，// 这样以后容器的子孙都会被解决
Container[] children = container.findChildren();
for (int i = 0; i < children.length; i++) {
// 这里请你留神，容器基类有个变量叫做 backgroundProcessorDelay，如果大于 0，表明子容器有本人的后盾线程，无需父容器来调用它的 processChildren 办法。if (children[i].getBackgroundProcessorDelay() <= 0) {processChildren(children[i]);
}
}
} catch (Throwable t) {...}Tomcat 的热加载就是在 Context 容器实现，次要是调用了 Context 容器的 reload 办法。抛开细节从宏观上看次要实现以下工作：
- 进行和销毁 Context 容器及其所有子容器，子容器其实就是 Wrapper，也就是说 Wrapper 外面 Servlet 实例也被销毁了。
- 进行和销毁 Context 容器关联的 Listener 和 Filter。
- 进行和销毁 Context 下的 Pipeline 和各种 Valve。
- 进行和销毁 Context 的类加载器，以及类加载器加载的类文件资源。
- 启动 Context 容器，在这个过程中会从新创立后面四步被销毁的资源。
在这个过程中，类加载器施展着关键作用。一个 Context 容器对应一个类加载器，类加载器在销毁的过程中会把它加载的所有类也全副销毁。Context 容器在启动过程中，会创立一个新的类加载器来加载新的类文件。
Tomcat 的类加载器
Tomcat 的自定义类加载器 WebAppClassLoader突破了双亲委托机制，它 首先本人尝试去加载某个类，如果找不到再代理给父类加载器 ，其目标是优先加载 Web 利用本人定义的类。具体实现就是重写 ClassLoader 的两个办法：findClass和 loadClass。
findClass 办法
org.apache.catalina.loader.WebappClassLoaderBase#findClass; 为了不便了解和浏览，我去掉了一些细节：
public Class<?> findClass(String name) throws ClassNotFoundException {
...
Class<?> clazz = null;
try {
//1. 先在 Web 利用目录下查找类
clazz = findClassInternal(name);
} catch (RuntimeException e) {throw e;}
if (clazz == null) {
try {
//2. 如果在本地目录没有找到，交给父加载器去查找
clazz = super.findClass(name);
} catch (RuntimeException e) {throw e;}
//3. 如果父类也没找到，抛出 ClassNotFoundException
if (clazz == null) {throw new ClassNotFoundException(name);
}
return clazz;
}- 先在 Web 利用本地目录下查找要加载的类。
- 如果没有找到，交给父加载器去查找，它的父加载器就是下面提到的零碎类加载器
AppClassLoader。 - 如何父加载器也没找到这个类，抛出
ClassNotFound异样。
loadClass 办法
再来看 Tomcat 类加载器的 loadClass办法的实现，同样我也去掉了一些细节：
public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {
Class<?> clazz = null;
//1. 先在本地 cache 查找该类是否曾经加载过
clazz = findLoadedClass0(name);
if (clazz != null) {if (resolve)
resolveClass(clazz);
return clazz;
}
//2. 从零碎类加载器的 cache 中查找是否加载过
clazz = findLoadedClass(name);
if (clazz != null) {if (resolve)
resolveClass(clazz);
return clazz;
}
// 3. 尝试用 ExtClassLoader 类加载器类加载，为什么？ClassLoader javaseLoader = getJavaseClassLoader();
try {clazz = javaseLoader.loadClass(name);
if (clazz != null) {if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {// Ignore}
// 4. 尝试在本地目录搜寻 class 并加载
try {clazz = findClass(name);
if (clazz != null) {if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {// Ignore}
// 5. 尝试用零碎类加载器 (也就是 AppClassLoader) 来加载
try {clazz = Class.forName(name, false, parent);
if (clazz != null) {if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {// Ignore}
}
//6. 上述过程都加载失败，抛出异样
throw new ClassNotFoundException(name);
}次要有六个步骤：
- 先在本地 Cache 查找该类是否曾经加载过，也就是说 Tomcat 的类加载器是否曾经加载过这个类。
- 如果 Tomcat 类加载器没有加载过这个类，再看看零碎类加载器是否加载过。
- 如果都没有，就让 ExtClassLoader 去加载，这一步比拟要害，目标 避免 Web 利用本人的类笼罩 JRE 的外围类 。因为 Tomcat 须要突破双亲委托机制，如果 Web 利用里自定义了一个叫 Object 的类，如果先加载这个 Object 类，就会笼罩 JRE 外面的那个 Object 类，这就是为什么 Tomcat 的类加载器会优先尝试用
ExtClassLoader去加载，因为ExtClassLoader会委托给BootstrapClassLoader去加载，BootstrapClassLoader发现自己曾经加载了 Object 类，间接返回给 Tomcat 的类加载器，这样 Tomcat 的类加载器就不会去加载 Web 利用下的 Object 类了，也就防止了笼罩 JRE 外围类的问题。 - 如果
ExtClassLoader加载器加载失败，也就是说JRE外围类中没有这类，那么就在本地 Web 利用目录下查找并加载。 - 如果本地目录下没有这个类，阐明不是 Web 利用本人定义的类，那么由零碎类加载器去加载。这里请你留神，Web 利用是通过
Class.forName调用交给零碎类加载器的，因为Class.forName的默认加载器就是零碎类加载器。 - 如果上述加载过程全副失败，抛出
ClassNotFound异样。
Tomcat 类加载器档次
Tomcat 作为 Servlet容器，它负责加载咱们的 Servlet类，此外它还负责加载 Servlet所依赖的 JAR 包。并且 Tomcat自身也是也是一个 Java 程序，因而它须要加载本人的类和依赖的 JAR 包。首先让咱们思考这一下这几个问题：
- 如果咱们在 Tomcat 中运行了两个 Web 应用程序，两个 Web 利用中有同名的
Servlet，然而性能不同，Tomcat 须要同时加载和治理这两个同名的Servlet类，保障它们不会抵触，因而 Web 利用之间的类须要隔离。 - 如果两个 Web 利用都依赖同一个第三方的 JAR 包，比方
Spring，那Spring的 JAR 包被加载到内存后，Tomcat要保障这两个 Web 利用可能共享，也就是说Spring的 JAR 包只被加载一次，否则随着依赖的第三方 JAR 包增多，JVM的内存会收缩。 - 跟 JVM 一样，咱们须要隔离 Tomcat 自身的类和 Web 利用的类。
1. WebAppClassLoader
Tomcat 的解决方案是自定义一个类加载器 WebAppClassLoader，并且给每个 Web 利用创立一个类加载器实例。咱们晓得，Context 容器组件对应一个 Web 利用，因而，每个 Context容器负责创立和保护一个 WebAppClassLoader加载器实例。这背地的原理是，不同的加载器实例加载的类被认为是不同的类，即便它们的类名雷同。这就相当于在 Java 虚拟机外部创立了一个个互相隔离的 Java 类空间，每一个 Web 利用都有本人的类空间，Web 利用之间通过各自的类加载器相互隔离。
2.SharedClassLoader
实质需要是两个 Web 利用之间怎么共享库类, 并且不能反复加载雷同的类。在双亲委托机制里，各个子加载器都能够通过父加载器去加载类，那么把须要共享的类放到父加载器的加载门路下不就行了吗。
因而 Tomcat 的设计者又加了一个类加载器 SharedClassLoader，作为 WebAppClassLoader的父加载器，专门来加载 Web 利用之间共享的类。如果 WebAppClassLoader本人没有加载到某个类，就会委托父加载器 SharedClassLoader去加载这个类，SharedClassLoader会在指定目录下加载共享类，之后返回给 WebAppClassLoader，这样共享的问题就解决了。
3. CatalinaClassloader
如何隔离 Tomcat 自身的类和 Web 利用的类？
要共享能够通过父子关系，要隔离那就须要兄弟关系了。兄弟关系就是指两个类加载器是平行的，它们可能领有同一个父加载器，基于此 Tomcat 又设计一个类加载器 CatalinaClassloader，专门来加载 Tomcat 本身的类。
这样设计有个问题，那 Tomcat 和各 Web 利用之间须要共享一些类时该怎么办呢？
老办法，还是再减少一个 CommonClassLoader，作为 CatalinaClassloader和 SharedClassLoader的父加载器。CommonClassLoader能加载的类都能够被 CatalinaClassLoader和 SharedClassLoader应用
整体架构设计解析播种总结
通过后面对 Tomcat 整体架构的学习，晓得了 Tomcat 有哪些外围组件，组件之间的关系。以及 Tomcat 是怎么解决一个 HTTP 申请的。上面咱们通过一张简化的类图来回顾一下，从图上你能够看到各种组件的档次关系，图中的虚线示意一个申请在 Tomcat 中流转的过程。
连接器
Tomcat 的整体架构蕴含了两个外围组件连接器和容器。连接器负责对外交换，容器负责外部解决。连接器用 ProtocolHandler接口来封装通信协议和 I/O模型的差别，ProtocolHandler外部又分为 EndPoint和 Processor模块，EndPoint负责底层 Socket通信，Proccesor负责应用层协定解析。连接器通过适配器 Adapter调用容器。
对 Tomcat 整体架构的学习，咱们能够失去一些设计简单零碎的基本思路。首先要剖析需要，依据高内聚低耦合的准则确定子模块，而后找出子模块中的变动点和不变点，用接口和形象基类去封装不变点，在形象基类中定义模板办法，让子类自行实现形象办法，也就是具体子类去实现变动点。
容器
使用了 组合模式 治理容器、通过 观察者模式 公布启动事件达到解耦、开闭准则。骨架抽象类和模板办法形象变与不变，变动的交给子类实现，从而实现代码复用，以及灵便的拓展。应用责任链的形式解决申请，比方记录日志等。
类加载器
Tomcat 的自定义类加载器 WebAppClassLoader为了隔离 Web 利用突破了双亲委托机制，它 首先本人尝试去加载某个类，如果找不到再代理给父类加载器 ，其目标是优先加载 Web 利用本人定义的类。 避免 Web 利用本人的类笼罩 JRE 的外围类，应用 ExtClassLoader 去加载，这样即突破了双亲委派，又能平安加载。
如何浏览源码继续学习
学习是一个反人类的过程，是比拟苦楚的。尤其学习咱们罕用的优良技术框架自身比拟宏大，设计比较复杂，在学习初期很容易遇到“挫折感”，debug 跳来跳去陷入恐怖细节之中无法自拔，往往就会放弃。
找到适宜本人的学习办法十分重要，同样要害的是要放弃学习的趣味和能源，并且失去学习反馈成果。
学习优良源码，咱们播种的就是架构设计能力，遇到简单需要咱们学习到能够利用正当模式与组件形象设计了可拓展性强的代码能力。
如何浏览
比方我最后在学习 Spring 框架的时候，一开始就钻进某个模块啃起来。然而因为 Spring 太宏大，模块之间也有分割，基本不明确为啥要这么写，只感觉为啥设计这么“绕”。
谬误形式
- 陷入细节，不看全局：我还没弄清楚森林长啥样，就盯着叶子看，看不到全貌和整体设计思路。所以浏览源码学习的时候不要一开始就进入细节，而是宏观对待整体架构设计思维，模块之间的关系。
- 还没学会用就钻研如何设计：首先基本上框架都使用了设计模式，咱们最起码也要理解罕用的设计模式，即便是“背”，也得了然于胸。在学习一门技术，我举荐先看官网文档，看看有哪些模块、整体设计思维。而后下载示例跑一遍，最初才是看源码。
- 看源码深究细节：到了看具体某个模块源码的时候也要下意识的不要去深刻细节，重要的是学习设计思路，而不是具体一个办法实现逻辑。除非本人要基于源码做二次开发。
正确形式
- 定焦准则：抓主线（抓住一个外围流程去剖析，不要漫无目的的到处浏览）。
- 宏观思维：从全局的视角去对待，上帝视角理出次要外围架构设计，先森林后树叶。切勿不要试图去搞明确每一行代码。
- 断点：正当使用调用栈（察看调用过程上下文）。
带着指标去学
比方某些知识点是面试的热点，那学习指标就是彻底了解和把握它，当被问到相干问题时，你的答复可能使得面试官对你另眼相看，有时候往往凭着某一个亮点就能影响最初的录用后果。
又或者接到一个略微简单的需要，学习从优良源码中借鉴设计思路与优化技巧。
最初就是入手实际，将所学使用在工作我的项目中。只有入手实际才会让咱们对技术有最直观的感触。有时候咱们听他人讲教训和实践，感觉仿佛懂了，然而过一段时间便又遗记了。
理论场景使用
简略的剖析了 Tomcat 整体架构设计，从【连接器】到【容器】，并且别离细说了一些组件的设计思维以及设计模式。接下来就是如何学以致用，借鉴优雅的设计使用到理论工作开发中。学习，从模拟开始。
责任链模式
在工作中，有这么一个需要，用户能够输出一些信息并能够抉择查验该企业的【工商信息】、【司法信息】、【中登状况】等如下如所示的一个或者多个模块，而且模块之间还有一些公共的货色是要各个模块复用。
这里就像一个申请，会被多个模块去解决。所以每个查问模块咱们能够形象为 解决阀门 ，应用一个 List 将这些 阀门保存起来，这样新增模块咱们只须要新增一个 阀门 即可，实现了 开闭准则 ， 同时将一堆查验的代码解耦到不同的具体阀门中 ，应用抽象类提取“ 不变的”性能。
具体示例代码如下所示：
首先形象咱们的解决阀门，NetCheckDTO是申请信息
/**
* 责任链模式：解决每个模块阀门
*/
public interface Valve {
/**
* 调用
* @param netCheckDTO
*/
void invoke(NetCheckDTO netCheckDTO);
}定义形象基类，复用代码。
public abstract class AbstractCheckValve implements Valve {public final AnalysisReportLogDO getLatestHistoryData(NetCheckDTO netCheckDTO, NetCheckDataTypeEnum checkDataTypeEnum){// 获取历史记录，省略代码逻辑}
// 获取查验数据源配置
public final String getModuleSource(String querySource, ModuleEnum moduleEnum){// 省略代码逻辑}
}定义具体每个模块解决的业务逻辑，比方【百度负面新闻】对应的解决
@Slf4j
@Service
public class BaiduNegativeValve extends AbstractCheckValve {
@Override
public void invoke(NetCheckDTO netCheckDTO) {}}最初就是治理用户抉择要查验的模块，咱们通过 List 保留。用于触发所须要的查验模块
@Slf4j
@Service
public class NetCheckService {
// 注入所有的阀门
@Autowired
private Map<String, Valve> valveMap;
/**
* 发送查验申请
*
* @param netCheckDTO
*/
@Async("asyncExecutor")
public void sendCheckRequest(NetCheckDTO netCheckDTO) {
// 用于保留客户抉择解决的模块阀门
List<Valve> valves = new ArrayList<>();
CheckModuleConfigDTO checkModuleConfig = netCheckDTO.getCheckModuleConfig();
// 将用户抉择查验的模块增加到 阀门链条中
if (checkModuleConfig.getBaiduNegative()) {valves.add(valveMap.get("baiduNegativeValve"));
}
// 省略局部代码.......
if (CollectionUtils.isEmpty(valves)) {log.info("网查查验模块为空，没有须要查验的工作");
return;
}
// 触发解决
valves.forEach(valve -> valve.invoke(netCheckDTO));
}
}模板办法模式
需要是这样的，可依据客户录入的财报 excel 数据或者企业名称执行财报剖析。
对于非上市的则解析 excel -> 校验数据是否非法 -> 执行计算。
上市企业：判断名称是否存在，不存在则发送邮件并停止计算 -> 从数据库拉取财报数据，初始化查验日志、生成一条报告记录，触发计算 -> 依据失败与胜利批改工作状态。
重要的”变“与”不变“，
- 不变 的是整个流程是 初始化查验日志、初始化一条报告 、 后期校验数据（若是上市公司校验不通过还须要构建邮件数据并发送）、从不同起源拉取财报数据并且适配通用数据、而后触发计算，工作异样与胜利都须要批改状态。
- 变动 的是上市与非上市校验规定不一样，获取财报数据形式不一样，两种形式的财报数据须要适配
整个算法流程是固定的模板，然而须要将 算法外部变动的局部 具体实现提早到不同子类实现，这正是模板办法模式的最佳场景。
public abstract class AbstractAnalysisTemplate {
/**
* 提交财报剖析模板办法，定义骨架流程
* @param reportAnalysisRequest
* @return
*/
public final FinancialAnalysisResultDTO doProcess(FinancialReportAnalysisRequest reportAnalysisRequest) {FinancialAnalysisResultDTO analysisDTO = new FinancialAnalysisResultDTO();
// 形象办法：提交查验的非法校验
boolean prepareValidate = prepareValidate(reportAnalysisRequest, analysisDTO);
log.info("prepareValidate 校验后果 = {}", prepareValidate);
if (!prepareValidate) {
// 形象办法：构建告诉邮件所须要的数据
buildEmailData(analysisDTO);
log.info("构建邮件信息，data = {}", JSON.toJSONString(analysisDTO));
return analysisDTO;
}
String reportNo = FINANCIAL_REPORT_NO_PREFIX + reportAnalysisRequest.getUserId() + SerialNumGenerator.getFixLenthSerialNumber();
// 生成剖析日志
initFinancialAnalysisLog(reportAnalysisRequest, reportNo);
// 生成剖析记录
initAnalysisReport(reportAnalysisRequest, reportNo);
try {
// 形象办法：拉取财报数据，不同子类实现
FinancialDataDTO financialData = pullFinancialData(reportAnalysisRequest);
log.info("拉取财报数据实现, 筹备执行计算");
// 测算指标
financialCalcContext.calc(reportAnalysisRequest, financialData, reportNo);
// 设置剖析日志为胜利
successCalc(reportNo);
} catch (Exception e) {log.error("财报计算子工作出现异常", e);
// 设置剖析日志失败
failCalc(reportNo);
throw e;
}
return analysisDTO;
}
}最初新建两个子类继承该模板，并实现形象办法。这样就将上市与非上市两种类型的解决逻辑解耦，同时又复用了代码。
策略模式
需要是这样，要做一个万能辨认银行流水的 excel 接口，假如规范流水蕴含【交易工夫、支出、收入、交易余额、付款人账号、付款人名字、收款人名称、收款人账号】等字段。当初咱们解析进去每个必要字段所在 excel 表头的下标。然而流水有多种状况：
- 一种就是蕴含所有规范字段。
- 支出、收入下标是同一列，通过正负来辨别支出与收入。
- 支出与收入是同一列，有一个交易类型的字段来辨别。
- 非凡银行的非凡解决。
也就是咱们要 依据解析对应的下标找到对应的解决逻辑算法，咱们可能在一个办法外面写超多 if else 的代码，整个流水解决都偶合在一起，如果将来再来一种新的流水类型，还要持续改老代码。最初可能呈现“又臭又长，难以保护”的代码复杂度。
这个时候咱们能够用到 策略模式 ， 将不同模板的流水应用不同的处理器解决，依据模板找到对应的策略算法去解决。即便将来再加一种类型，咱们只有新加一种处理器即可，高内聚低耦合，且可拓展。
定义处理器接口，不同处理器去实现解决逻辑。将所有的处理器注入到 BankFlowDataHandler 的 data_processor_map 中，依据不同的场景取出对曾经的处理器解决流水。
public interface DataProcessor {
/**
* 解决流水数据
* @param bankFlowTemplateDO 流水下标数据
* @param row
* @return
*/
BankTransactionFlowDO doProcess(BankFlowTemplateDO bankFlowTemplateDO, List<String> row);
/**
* 是否反对解决该模板, 不同类型的流水策略依据模板数据判断是否反对解析
* @return
*/
boolean isSupport(BankFlowTemplateDO bankFlowTemplateDO);
}
// 处理器的上下文
@Service
@Slf4j
public class BankFlowDataContext {
// 将所有处理器注入到 map 中
@Autowired
private List<DataProcessor> processors;
// 找对对应的处理器解决流水
public void process() {DataProcessor processor = getProcessor(bankFlowTemplateDO);
for(DataProcessor processor：processors) {if (processor.isSupport(bankFlowTemplateDO)) {
// row 就是一行流水数据
processor.doProcess(bankFlowTemplateDO, row);
break;
}
}
}
}定义默认处理器，解决失常模板，新增模板只有新增处理器实现 DataProcessor即可。
/**
* 默认处理器：正对标准流水模板
*
*/
@Component("defaultDataProcessor")
@Slf4j
public class DefaultDataProcessor implements DataProcessor {
@Override
public BankTransactionFlowDO doProcess(BankFlowTemplateDO bankFlowTemplateDO) {
// 省略解决逻辑细节
return bankTransactionFlowDO;
}
@Override
public String strategy(BankFlowTemplateDO bankFlowTemplateDO) {
// 省略判断是否反对解析该流水
boolean isDefault = true;
return isDefault;
}
}通过策略模式，咱们将不同解决逻辑调配到不同的解决类中，这样齐全解耦，便于拓展。
应用内嵌 Tomcat 形式调试源代码：GitHub: https://github.com/UniqueDong…
完满分割线，因为篇幅限度对于如何借鉴 Tomcat 的设计思维使用到理论开发中的综合例子就放到下回解说了。本篇干货满满，倡议珍藏当前多多回味，也心愿读者「点赞」「分享」「在看」三连就是最大的激励。
后盾回复“加群”进入专属技术群一起成长
