Servlet 与 Filter 执行原理

Servlet 的两个 Map

当请求到达后，web 容器是如何查找 Servlet 的呢？其底层的执行原理是什么呢？

当 Servlet 实例被创建好后，会将该 Servlet 实例的引用存放到一个 Map 集合中。该 Map集合的 key 为 URI，而 value 则为 Servlet 实例的引用，即 Map<String, Servlet>。当 Web 容器从用户请求中分离出 URI 后，会首先到这个 Map 中查找是否存在其所对应的 value。若存在，则直接调用其 service()方法。若不存在，则需要创建该 Servlet 实例。

若请求的 Servlet 实例不存在，Web 容器又是根据什么创建这个 Servlet 实例的呢？在Web 容器的内存中，还存在一个 Map 集合。该 Map 集合的 key 为 URI，而 value 则为 web.xml中配置的与之对应的 Servlet 的全限定性类名，即 Map<String, String>。

当 Web 容器从用户请求中分离出 URI后，到第一个 Map中又没有找到其所对应的 Servlet实例，则会马上查找这第二个 Map，从中找到其所对应的类名，再根据反射机制，创建这个 Servlet 实例。然后再将这个创建好的 Servlet 的引用放入到第一个 Map 中。

Filter 的一个 Map 一个数组

像存放 Servlet 信息的两个 Map 一样，在服务器中同样存在用于存放 Filter 相关信息的Map。只不过 Map 只有一个，而非两个。为什么呢？因为 Filter 的创建时机不同于 Servlet，其是在服务器启动时由 web 容器自动创建的。

这个 Map 的 key 是 Filter 的。当然，若 Filter 没有设置而是使用了，则会将指定的 Servlet 的值放到 Map 中作为 key。Map 的value 为该 Filter 的引用。在应用被启动时，服务器会自动将所有的 Filter 实例创建，并将它们的引用放入到相应 Map 的 value 中。

在服务器中，对于每一个请求，还存在着一个数组，用于存放满足当前请求的所有 Filter及最终的目标资源。

当请求到达服务器后，服务器会解析出 URI，然后会先从 Filter 的 Map 中查找所有与该请求匹配的 Filter，每找到一个就将其引用存放到数组中，然后继承查找。直到将所有匹配的 Filter 全部找到并添加到数组中。

这个数组就是对于当前请求所要进行处理的一个“链”，包含多个 Filter。服务器将按照这个“链”的顺序对请求进行依次过滤处理。

注意，我们发现对于 Filter 的 Map 的查询过程与对于 Servlet 的 Map 的查询过程是不同的。对于 Servlet 的 Map 的查询过程是，只要找到一个匹配的 key，则将不再向后查找。而对于 Filter 的 Map 的查找，则是遍历所有 key，将所有匹配的元素都查找出来