一，servlet容器对url的匹配过程：
当 一个请求发送到servlet容器的时候，容器先会将请求的url减去tomcat的上下文路径（配置的访问系统的基础路径例如intellij idea配置的http://localhost:8080）
作为servlet的映射url，比如我访问的是 http://localhost:8080/hello，按照上图，容器会将http://localhost/去掉， 剩下的hello部分拿来做servlet的映射匹配。这个映射匹配过程是有顺序的，而且当有一个servlet匹配成功以后，就不会去理会剩下 的servlet了（filter不同，后文会提到）。其匹配规则和顺序如下：
1. 精确匹配。例子：比如servletA 的url-pattern为 /test，servletB的url-pattern为 /* ，这个时候，如果我访问的url为http://localhost/test ，这个时候容器就会先进行精确路径匹配，发现/test正好被servletA精确匹配，那么就去调用servletA，也不会去理会其他的 servlet了。
2. 路径匹配：以“/”字符开头，并以“/*”结尾的字符串用于路径匹配：如：
3. 扩展名匹配：以“*.”开头的字符串被用于扩展名匹配
4.缺省匹配：
二、匹配顺序
- 精确匹配，servlet1：<url-pattern>/world</url-pattern>，servle2：<url-pattern>/*</url-pattern>。当一个请求http://localhost:8080/world来的时候，servle1匹配到，不再用servlet2匹配,
- 路径匹配，serlvet1：<url-pattern>/a/b/*</url-pattern>，servlet2:<url-pattern>/a/b/c/*</url-pattern>;如果请求是http://localhost:8080/a/b/c,那么匹配到servlet1
- 扩展名匹配，servlet1：<url-pattern>/*</url-pattern>，servlet-mapping2：<url-pattern>*.jsp</url-pattern>。当一个请求http://localhost:8080/a.jsp来的时候，servlet1匹配到，不再用servlet2匹配不到
- 缺省匹配，以上都找不到servlet，就用默认的servlet，配置为<url-pattern>/</url-pattern>
三、需要注意的问题
1 路径匹配和扩展名匹配无法同时设置
匹配方法只有三种，要么是路径匹配（以“/”字符开头，并以“/*”结尾），要么是扩展名匹配（以“*.”开头），要么是精确匹配，三种匹配方法不能进行组合，不要想当然使用通配符或正则规则。
如<url-pattern>/*.jsp</url-pattern>是非法的
另外注意：<url-pattern>/aa/*/bb</url-pattern>是精确匹配，合法，这里的*不是通配的含义
2 "/*"和"/"含义并不相同
- “/*”属于路径匹配，并且可以匹配所有request，由于路径匹配的优先级仅次于精确匹配，所以“/*”会覆盖所有的扩展名匹配，很多404错误均由此引起，所以这是一种特别恶劣的匹配模式，一般只用于filter的url-pattern
- “/”是servlet中特殊的匹配模式，切该模式有且仅有一个实例，优先级最低，不会覆盖其他任何url-pattern，只是会替换servlet容器的内建default servlet ，该模式同样会匹配所有request。
- 配置“/”后，一种可能的现象是myServlet会拦截诸如http://localhost:8080/appDemo/user/addUser.action、http://localhost:8080/appDemo/user/updateUser的格式的请求，但是并不会拦截http://localhost:8080/appDemo/user/users.jsp、http://localhost:8080/appDemo/index.jsp，这是因为servlet容器有内置的“*.jsp”匹配器，而扩展名匹配的优先级高于缺省匹配，所以才会有上述现象,只输入servlet上下文，会调用servlet容器的内建default servlet（而不是自己写的缺省匹配）。
Tomcat在%CATALINA_HOME%confweb.xml文件中配置了默认的Servlet，配置代码如下
<filter>的<url-pattern>只能使用“/*”，不能使用“/”，因为tomcat关于加载filter的配置代码没有关于“/”的