【Spring】DispatcherServlet解析

DispatcherServlet 深度解析：Spring MVC 的"中央调度员"

一、核心作用：前端控制器的典范实现

DispatcherServlet是 Spring MVC 框架的前端控制器（Front Controller），扮演所有 HTTP 请求的统一入口和调度中枢。它不直接处理业务逻辑，而是像"交响乐指挥家"一样协调各个组件完成请求处理全流程。

三大核心职责

1. 请求路由：解析 HTTP 请求，通过HandlerMapping确定对应的处理器（Controller 方法）
2. 流程协调：组织HandlerAdapter、ViewResolver、HandlerInterceptor等组件按既定流程协作
3. 异常处理：统一捕获并处理整个请求处理链中的异常，确保健壮的异常响应机制

架构位置

作为连接客户端与应用程序的唯一桥梁，DispatcherServlet与 Spring IoC 容器无缝集成，可访问容器中所有 Bean。这种设计使得请求处理组件也能享受依赖注入、AOP 等 Spring 核心能力。

二、应用实践：从配置到优化

1. 基础配置方式

传统 web.xml 配置：

<servlet><servlet-name>dispatcher</servlet-name><servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class><init-param><param-name>contextConfigLocation</param-name><param-value>/WEB-INF/spring-mvc.xml</param-value></init-param><load-on-startup>1</load-on-startup></servlet><servlet-mapping><servlet-name>dispatcher</servlet-name><url-pattern>/</url-pattern><!-- 关键配置 --></servlet-mapping>

Spring Boot 注解配置（自动装配）：

@SpringBootApplicationpublicclassApplication{publicstaticvoidmain(String[]args){SpringApplication.run(Application.class,args);}}// 默认自动配置DispatcherServlet，映射路径为"/"

2. 路径映射的陷阱：/vs/*

这是最容易踩的坑：

• /：推荐使用。会覆盖 DefaultServlet，需手动配置静态资源处理，但符合 RESTful 规范
• /*：致命错误。会拦截包括 JSP 在内的所有请求，导致 JSP 被二次处理而无法正常渲染

正确配置静态资源：

@ConfigurationpublicclassWebConfigimplementsWebMvcConfigurer{@OverridepublicvoidaddResourceHandlers(ResourceHandlerRegistryregistry){registry.addResourceHandler("/static/**").addResourceLocations("classpath:/static/");}}

3. 实际应用场景

• 传统 MVC 应用：配合 JSP/Thymeleaf 进行服务端页面渲染
• RESTful API 服务：配合@RestController和MappingJackson2HttpMessageConverter直接返回 JSON
• 文件上传：通过MultipartResolver组件统一处理multipart/form-data请求
• 多语言支持：集成LocaleResolver实现国际化视图解析

三、注意事项与避坑指南

1. 初始化失败排查

DispatcherServlet在容器启动时初始化WebApplicationContext，如果配置错误会导致应用无法启动。常见原因：

• 循环依赖：Controller 中注入自身或导致循环引用的 Bean
• 组件缺失：未配置任何HandlerMapping或HandlerAdapter（Spring Boot 可自动装配）
• 配置文件路径错误：contextConfigLocation指向不存在的 XML 文件

2. 拦截器执行顺序问题

拦截器链执行顺序直接影响业务逻辑，特别是preHandle()返回false时直接中断请求：

// 注册顺序 = 执行顺序registry.addInterceptor(authInterceptor()).order(1);registry.addInterceptor(logInterceptor()).order(2);

执行流程：

preHandle() → Controller → postHandle() → View渲染 → afterCompletion()

若preHandle()返回false，后续所有步骤（包括其他拦截器）全部跳过。

3. 线程安全问题

DispatcherServlet本身是单例的，但处理每个请求时会将HttpServletRequest和HttpServletResponse封装在ServletWebRequest中，保证线程安全。需注意：

• 避免在 Controller 中使用实例变量存储请求级数据
• 拦截器中谨慎使用实例变量，应通过request.setAttribute()传递数据

4. 性能优化要点

• 异步处理：对于长耗时请求，使用Callable或DeferredResult释放 Tomcat 线程
• 缓存组件：HandlerMapping和HandlerAdapter的映射结果会被缓存，避免重复查找
• 精简组件：移除不必要的ViewResolver和HttpMessageConverter加速启动

四、设计考量：为何如此设计？

1. 前端控制器模式的价值

传统 Servlet 开发的痛点：

• 每个 URL 对应一个 Servlet，导致类爆炸
• 重复代码（权限校验、日志、编码转换）散落在各处
• 难以统一管理和扩展

DispatcherServlet 的解决方案：

• 统一入口：所有请求集中处理，全局流程可控
• 职责分离：业务逻辑与请求分发彻底解耦
• 标准化流程：强制实施"查找处理器→执行→渲染视图"的标准生命周期

2. 策略模式的高度可扩展性

DispatcherServlet通过策略接口实现热插拔组件：

这种设计使得 Spring MVC 既能支持传统的@Controller，也能无缝适配 WebFlux 的函数式编程模型，保证框架的演进不破坏现有代码。

3. 与 Servlet 规范的完美兼容

DispatcherServlet继承自FrameworkServlet，后者重写了HttpServlet.service()方法：

// 添加对 PATCH 方法的支持@Overrideprotectedvoidservice(HttpServletRequestrequest,HttpServletResponseresponse)throwsServletException,IOException{HttpMethodhttpMethod=HttpMethod.resolve(request.getMethod());if(httpMethod==HttpMethod.PATCH||httpMethod==null){processRequest(request,response);// 统一入口}else{super.service(request,response);// 委托父类处理 GET/POST 等}}

这种设计既遵循 Servlet 规范，又能在规范之外扩展功能（如 PATCH 方法），保证在所有 Servlet 容器（Tomcat/Jetty/Undertow）上可移植。

4. 集中式横切关注点管理

所有共性功能（权限、日志、跨域、限流）都可通过以下方式统一管理，避免代码侵入：

• HandlerInterceptor：请求级拦截
• Filter：Servlet 级过滤
• ControllerAdvice：全局异常处理和数据绑定

这种架构极大提升了代码复用性和可维护性，是 Spring MVC 在企业级应用中长盛不衰的关键。

五、总结：设计哲学

DispatcherServlet的设计体现了 Spring 框架一贯的理念：让复杂的问题变得简单，让简单的问题变得可扩展。它通过"集中式控制 + 策略化组件"的架构，在 Servlet API 的灵活性与企业级开发的规范性之间找到了完美平衡。

对于开发者而言，深入理解DispatcherServlet意味着掌握了 Spring MVC 的"总纲"，后续学习各种组件（如参数解析、返回值处理、异常解析）都是在这个总纲下的具体展开。这也是为何它成为面试必考、排查必懂、扩展必会的核心类。