Tomcat源码分析之 doGet方法(二)

简介: Tomcat源码分析之 doGet方法(二)

在第一讲我们介绍了当一个请求到达 Servlet 时,首先将 ServletRequest ServletResponse 转化为 HttpServletRequest HttpServletResponse,然后获得 HTTP 请求的方法类型,最后根据不同的方法类型调用不同的方法。如了解更多,请阅读Tomcat源码分析之 doGet方法(一)

 

第一讲我们重点搞明白了当一个请求到达 Servlet 后发生的所有事情,那么这个请求在到达 Servlet 之前发生了什么呢?

 

在请求到达 Servlet 之前发生了很多很多事情,这也是我们本系列博客要探讨的主题。我们本讲主要探讨的是在到达 Servlet 前,该请求会经过一系列的过滤器 FilterTomcat 的过滤器机制是如何实现的呢?

 

1 目标

深入理解Tomcat的过滤器机制,理解ApplicationFilterChain 内部实现原理。

 

2 分析方法

根据上一讲的堆栈信息,结合 Intellij Idea 的堆栈视图、断点、单步调试等手段分析源码。

4. at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)

5.at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

6.at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)

7.at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

8.at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)


3 分析流程


image.png

 

从上图可以看出在请求到达 Servlet 之前,会经过一系列的过滤器Filter1 Filter2 ... FilterN,我们本讲需要探讨的就是 Tomcat 是如何实现这一机制的。

 


3.1 过滤器机制简单实现

 如果是我们自己实现这种过滤器机制该怎么实现呢?

 

我们首先来看一种简单的实现方式。

// 代码 1
Filter[] filters;
for (Filter filter : filters){
    filter.doFilter(req, resp);
}
servlet.service(req, resp);

最简单的实现方式莫过于上面的代码,定义一个过滤器数组,然后依次遍历这个数组中的每一个过滤器并执行,最后请求到达 Servlet,调用 service 方法。

 

这种方式确实能够实现上图描述的过程,但是却有一个严重的问题。

 

当一个请求到达某个过滤器的时候,如果这个请求不符合过滤器的要求,那么这个请求将不再传递到下一个过滤器。

 

而上面的代码则是无论什么情况下,都会将所有的过滤器都执行一遍,因此无法处理上面提到的特殊情况。

 

3.2 过滤器机制改进版本

 

通过对上述问题的仔细分析,我们发现,每一个过滤器都可以自行决定是否将请求传递到下一个过滤器,满足某种特定要求就传递到下一个过滤器,不满足要求时则不再传递,而直接到达 Servlet

 

如何实现这种机制呢?

 

首先我们换一种方式来实现上述的代码1

// 代码2
Filter[]filters;
int n = filters.length;
int pos = 0;
while( pos < n){
    Filter filter = filters[pos++];
    filter.doFilter(req, resp);
}

定义一个过滤器索引 pos 来表示当前的过滤器位置,然后通过 while 循环来遍历。这个代码应该很简单,只不过是 for 循环变成了 while 循环而已。

 

这不是换汤不换药吗?没有什么变化啊。

 

现在请大家思考,是否可以不使用任何的循环结构来完成这个数组的遍历操作呢?

 

不使用任何的循环结构也能遍历一个数组?这是搞笑吧,从来还没见过这种做法呢。

 

接下来我们就给大家介绍一种不使用任何循环结构就完成遍历的操作。

public class FilterChain {
    private int pos = 0; //当前过滤器下标
    private int n;     // 过滤器数组大小
    private Filter[] filters;
    public void doFilter(ServletRequestreq, ServletResponse resp){
        if(pos < n){
            Filter filter = filters[pos++];
            filter.doFilter(req, resp, this);
        }
        servlet.service(req, resp);
    }
    //其他代码省略
}

首先定义一个类FilterChain,这个类的属性代码已做注释和前面的代码2类似。

 

重点看 doFilter 方法,首先看当前的下标有没有超过数组大小,没有的话则获得当前过滤器,下标自增,然后执行该过滤器。

 

刚开始的时候 pos 0,所以得到了第一个过滤器并执行,后面就到了 servlet 方法,你这何曾遍历了整个数组?只是执行了第一个过滤器而已啊。

 

客官,别急。重点在下面:

 public class SampleFilter implements Filter {
    @Override
    public void doFilter(ServletRequestreq, ServletResponse resp, FilterChain filterChain) {
        System.out.println("do something!");
        filterChain.doFilter(req, resp);
    }
}

对于每一个 Filter 来说,在 doFilter 方法中,有一行代码非常关键,那就是filterChain.doFilter(req,resp),当执行完第一个过滤器的 doFilter 方法后,又重新回到了 filterChain 中,而此时 pos=1即指向第二个过滤器了。这就是设计精髓所在。

if(pos < n){ //经过第一个过滤器后,此时 pos 值为1
            Filter filter = filters[pos++];
            filter.doFilter(req, resp, this);
}

依次类推,当所有的过滤器都执行完后,此时 pos == n,便跳出了 if 语句执行 servlet 方法。

 

以上给大家介绍的就是一种不使用任何循环结构就可以完成遍历的设计思路,是不是非常有趣。它的核心设计思想就是使用一个下标来记录当前元素,然后每一个元素在执行完毕后,回到最初开始的地方。

 

利用这种设计思路,你可以改写之前你写过的很多循环结构。通过练习可以帮助自己更好的理解这种设计思想。

 

这种设计思路就可以很好的解决刚开始提出的问题,当请求不符合某个过滤器的要求时,不执行 filterChain doFilter 方法,就意味着不会回到 if 的判断条件,也就得不到下一个过滤器,自然就直接跳到 servlet 了。

 

3.3 Tomcat 过滤器机制源码分析


有了上面的基础,我们就会很容易理解 Tomcat 的过滤器机制实现思路了。Tomcat 过滤器的实现机制主要涉及到核心类 ApplicationFilterChain 和接口 Filter

 

Filter接口定义如下:

public interface Filter {
    public default void init(FilterConfigfilterConfig) throws ServletException {}
    public void doFilter(ServletRequestrequest, ServletResponse response,
            FilterChain chain) throws IOException,ServletException;
    public default void destroy() {}
}

 

过滤器机制的核心实现代码是:

private void internalDoFilter(ServletRequest request,
                             ServletResponse response)
    throws IOException, ServletException {
    // Call the next filter if there is one
    if (pos < n) {
        ApplicationFilterConfig filterConfig = filters[pos++];
            //..
            Filter filter =filterConfig.getFilter();
            filter.doFilter(request,response, this);
            //...
        return;
    }
    // We fell off the end of the chain --call the servlet instance
            servlet.service(request,response);
}

我们屏蔽了很多不相关的代码,只保留最核心的,目的就是帮助大家更好的了解原理。

 

了解了过滤器的核心机制后,接下来我们回到第一讲的执行栈。

 

从第一讲的测试案例中,我们并没有配置任何的过滤器,但是从上面的堆栈信息,我们却看到这个请求经过了一个名叫 WsFilter 的过滤器,这是为什么呢?欢迎留言。

6.atorg.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)


4 总结

 

本讲主要探讨了请求在到达 Servlet 之前会经过一系列的过滤器,从Tomcat 源码的角度深入剖析了过滤器的实现机制,其实现的核心类为ApplicationFilterChain 。

 

从第一讲和第二讲我们知道一个请求会经过一系列的过滤器,最后达到 Servlet,细心的你可能会问,那么这个请求在达到过滤器之前又发生了什么呢?

 

目录
相关文章
|
2月前
|
监控 Java 应用服务中间件
Spring Boot整合Tomcat底层源码分析
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置和起步依赖等特性,大大简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是其与Tomcat的整合。
82 1
|
4月前
|
监控 网络协议 应用服务中间件
【Tomcat源码分析】从零开始理解 HTTP 请求处理 (第一篇)
本文详细解析了Tomcat架构中复杂的`Connector`组件。作为客户端与服务器间沟通的桥梁,`Connector`负责接收请求、封装为`Request`和`Response`对象,并传递给`Container`处理。文章通过四个关键问题逐步剖析了`Connector`的工作原理,并深入探讨了其构造方法、`init()`与`start()`方法。通过分析`ProtocolHandler`、`Endpoint`等核心组件,揭示了`Connector`初始化及启动的全过程。本文适合希望深入了解Tomcat内部机制的读者。欢迎关注并点赞,持续更新中。如有问题,可搜索【码上遇见你】交流。
【Tomcat源码分析】从零开始理解 HTTP 请求处理 (第一篇)
|
4月前
|
人工智能 前端开发 Java
【Tomcat源码分析】启动过程深度解析 (二)
本文深入探讨了Tomcat启动Web应用的过程,重点解析了其加载ServletContextListener及Servlet的机制。文章从Bootstrap反射调用Catalina的start方法开始,逐步介绍了StandardServer、StandardService、StandardEngine、StandardHost、StandardContext和StandardWrapper的启动流程。每个组件通过Lifecycle接口协调启动,子容器逐层启动,直至整个服务器完全启动。此外,还详细分析了Pipeline及其Valve组件的作用,展示了Tomcat内部组件间的协作机制。
【Tomcat源码分析】启动过程深度解析 (二)
|
3月前
apache+tomcat配置多站点集群的方法
apache+tomcat配置多站点集群的方法
58 4
|
4月前
|
前端开发 Java 应用服务中间件
【Tomcat源码分析 】"深入探索:Tomcat 类加载机制揭秘"
本文详细介绍了Java类加载机制及其在Tomcat中的应用。首先回顾了Java默认的类加载器,包括启动类加载器、扩展类加载器和应用程序类加载器,并解释了双亲委派模型的工作原理及其重要性。接着,文章分析了Tomcat为何不能使用默认类加载机制,因为它需要解决多个应用程序共存时的类库版本冲突、资源共享、类库隔离及JSP文件热更新等问题。最后,详细展示了Tomcat独特的类加载器设计,包括Common、Catalina、Shared、WebApp和Jsp类加载器,确保了系统的稳定性和安全性。通过这种设计,Tomcat实现了不同应用程序间的类库隔离与共享,同时支持JSP文件的热插拔。
【Tomcat源码分析 】"深入探索:Tomcat 类加载机制揭秘"
|
4月前
|
设计模式 应用服务中间件 容器
【Tomcat源码分析】Pipeline 与 Valve 的秘密花园
本文深入剖析了Tomcat中的Pipeline和Valve组件。Valve作为请求处理链中的核心组件,通过接口定义了关键方法;ValveBase为其基类,提供了通用实现。Pipeline则作为Valve容器,通过首尾相连的Valve链完成业务处理。StandardPipeline实现了Pipeline接口,提供了详细的Valve管理逻辑。通过对代码的详细分析,揭示了模板方法模式和责任链模式的应用,展示了系统的扩展性和模块化设计。
【Tomcat源码分析】Pipeline 与 Valve 的秘密花园
|
4月前
|
设计模式 人工智能 安全
【Tomcat源码分析】生命周期机制 Lifecycle
Tomcat内部通过各种组件协同工作,构建了一个复杂的Web服务器架构。其中,`Lifecycle`机制作为核心,管理组件从创建到销毁的整个生命周期。本文详细解析了Lifecycle的工作原理及其方法,如初始化、启动、停止和销毁等关键步骤,并展示了LifecycleBase类如何通过状态机和模板模式实现这一过程。通过深入理解Lifecycle,我们可以更好地掌握组件生命周期管理,提升系统设计能力。欢迎关注【码上遇见你】获取更多信息,或搜索【AI贝塔】体验免费的Chat GPT。希望本章内容对你有所帮助。
|
5月前
|
网络协议 Java 应用服务中间件
Tomcat源码分析 (一)----- 手撕Java Web服务器需要准备哪些工作
本文探讨了后端开发中Web服务器的重要性,特别是Tomcat框架的地位与作用。通过解析Tomcat的内部机制,文章引导读者理解其复杂性,并提出了一种实践方式——手工构建简易Web服务器,以此加深对Web服务器运作原理的认识。文章还详细介绍了HTTP协议的工作流程,包括请求与响应的具体格式,并通过Socket编程在Java中的应用实例,展示了客户端与服务器间的数据交换过程。最后,通过一个简单的Java Web服务器实现案例,说明了如何处理HTTP请求及响应,强调虽然构建基本的Web服务器相对直接,但诸如Tomcat这样的成熟框架提供了更为丰富和必要的功能。
|
5月前
|
Ubuntu Java 应用服务中间件
在Ubuntu 16.04上安装Apache Tomcat 8的方法
在Ubuntu 16.04上安装Apache Tomcat 8的方法
75 0