先声明一下这篇不是那种“背完就忘”的八股文。把Servlet工作原理讲透本质上是在理解Java Web最底层的请求处理模型。很多人在面试时能把生命周期背得滚瓜烂熟但被追问到“两个Servlet之间怎么共享数据”“容器是如何做到并发安全的”“转发和重定向本质区别到底是什么”就卡壳问题就出在只背了结论没吃透机制。这篇文章我从面试官最常追问的角度切入把Servlet从加载、实例化、请求处理到销毁的完整链路拆开讲同时把容器协作、线程模型、源码级细节一并梳理清楚适合准备Java后端面试的同学也适合想真正搞懂Web容器工作原理的开发者。1. 先把Servlet的本质看透它不是一个对象是一套契约1.1 从面试官的视角理解这道题面试官问“Servlet工作原理”表面上看是在考察你知不知道init、service、destroy三个方法的调用顺序实际上他想确认三件事第一你是否清楚Servlet在Web容器中的角色定位第二你是否理解请求从浏览器到Servlet再到浏览器的完整路径第三你是否具备从“使用框架”到“理解框架”的底层认知能力。我面试别人的时候通常会接下来追问一句“Spring MVC的DispatcherServlet也是Servlet吗它和普通的Servlet有什么区别”这个问题能筛掉一大批只会用注解开发的人。因为原理层面的东西一旦想明白框架在你眼里就不再神秘你会看到Spring MVC不过是在Servlet规范之上做了一层封装和路由分发。1.2 Servlet在Java Web体系中的位置Servlet是Java EE规范里定义的一套用于处理客户端请求的服务端组件接口它运行在Web容器中Web容器负责它的生命周期管理和网络通信。你可以把Web容器理解成一个标准的“酒店”Servlet就是住进酒店的“客人”客人不需要自己操心水电网络只需要实现酒店规定的服务流程前台自会把客人请求转交给对应的服务员。这层抽象的价值在于开发者只需要关注业务逻辑也就是“收到请求后做什么”而不用关心如何监听端口、如何解析HTTP协议、如何管理TCP连接。如果没有Servlet这套规范每个开发者都要自己处理底层socket通信那Java Web开发的复杂度将不可想象。注意Servlet本身是接口真正干活的类是由容器实例化的Servlet实现类。你写业务代码时继承HttpServlet本质上就是一个符合规范的实现类。2. 一次HTTP请求的完整旅程从浏览器到Servlet再到浏览器2.1 请求进入容器之前一个典型的请求链路是用户在浏览器输入URL并回车浏览器根据域名解析出IP地址与服务器建立TCP连接构造HTTP请求报文并发送。服务器端的Web容器监听在80或8080端口上一旦接收到数据马上开始解析HTTP协议把请求行、请求头、请求体提取出来。这个过程对Servlet是透明的。Tomcat里有一个叫CoyoteAdapter的组件专门负责把底层Socket数据解析成Request对象注意这里的Request是Tomcat内部实现的org.apache.coyote.Request还不是Servlet规范里的HttpServletRequest。解析完成之后容器会把这些数据封装成HttpServletRequest和HttpServletResponse这两个接口的实现类再交给Servlet处理。2.2 容器寻找目标Servlet的匹配原则容器怎么知道哪个Servlet来处理这个请求这就要靠URL映射规则。开发者通过注解WebServlet(/api/user)或者web.xml里的servlet-mapping配置声明了一个Servlet的访问路径。容器启动时会加载这些映射关系构建一个类似路由表的结构。请求到来时容器用请求的URI去匹配路由表。匹配规则有四种精确匹配、路径匹配/api/*、扩展名匹配*.do、默认匹配/。优先级从高到低分别是精确匹配大于路径匹配大于扩展名匹配大于默认匹配。这里有个坑很多人在配置时容易混淆/是默认Servlet匹配所有未匹配到的请求而/*是路径匹配会覆盖所有路径两者的行为完全不同。2.3 Servlet核心方法的调用次序Servlet接口定义了三个生命周期方法init、service、destroy加上getServletConfig和getServletInfo。容器管理的核心流程是这样的容器启动或首次请求到达时读取web.xml或注解配置通过反射实例化Servlet类。容器调用init(ServletConfig config)方法完成初始化把ServletConfig传给Servlet保存。每次请求到达容器都会调用Servlet的service(ServletRequest req, ServletResponse res)方法。HttpServlet这个抽象类在service方法内部对请求类型做了分发根据请求方法调用对应的doGet、doPost、doPut、doDelete等方法。容器关闭或Web应用重新加载时调用destroy()方法释放资源。这里有个细节值得注意init和destroy在Servlet的整个生命周期中只会被调用一次而service会被调用无数次。默认情况下Servlet是单实例的意味着一个Servlet类的实例同时处理所有请求后面讲线程模型时再展开。3. 生命周期与容器协作的核心机制3.1 初始化阶段到底发生了什么Servlet的初始化有两种时机一种是在Web容器启动时就初始化通过load-on-startup配置指定数值越小优先级越高另一种是懒加载在第一次请求到达时才实例化并初始化。默认情况下Tomcat容器会在启动阶段扫描所有注解配置的Servlet但如果Servlet没有标注WebServlet(loadOnStartup 1)则默认是首次访问时才创建实例。init方法里做的通常包括读取配置参数、初始化数据库连接池、启动后台线程、加载外部资源。这也是面试官喜欢追问的点“为什么init里不能直接操作HttpServletRequest”因为init方法在Servlet还没有接收任何请求时就被调用了此时请求对象尚不存在这一点要能脱口而出。再看ServletConfig它是init方法的参数包含Servlet名称、初始化参数、ServletContext引用。初始化参数可以通过WebServlet(initParams WebInitParam(name key, value value))来配置在代码中用getInitParameter(key)读取。ServletContext是Web应用的全局上下文对象整个应用只有一个实例。它能实现多个Servlet之间的数据共享可以通过setAttribute、getAttribute存放应用级数据也能获取Web应用资源的真实路径。ServletConfig和ServletContext的区别是面试高频题记住一句话ServletConfig是单个Servlet的私有配置ServletContext是整个应用的公共区域。3.2 service阶段的分发机制与重载陷阱HttpServlet.service方法的分发逻辑是面试题里最容易“翻车”的地方。很多人知道doGet和doPost但不清楚service是如何判断请求方法的更不知道可以重载service方法直接绕过doGet和doPost。3.3 容器何时销毁Servletdestroy方法的调用时机很容易被忽略。容器关闭、Web应用重新部署、热更新替换类文件时容器会调用destroy。这个方法需要注意两点第一destroy执行时容器会等待所有正在执行的service方法线程完成也就是说如果有一个耗时很长的请求正在处理中容器会阻塞等待第二destroy里应该释放所有资源但要注意线程安全问题因为此时可能还有其他线程在执行service。Tomcat在调用destroy之前会先将Servlet标记为不再接收请求然后等待service方法的线程池任务全部结束最后才会调用destroy。这个过程在源码中由StandardWrapper的unload方法控制。实际项目中如果Servlet里持有数据库连接池、线程池等资源destroy方法里不释放频繁热部署就会导致资源泄漏最终OOM。4. 线程模型与并发安全单实例多线程下的生存法则4.1 单实例多线程模型的底层逻辑Servlet的默认部署方式是单实例的试想如果每个请求都创建一个新的Servlet实例那么频繁的创建和销毁对象会带来很大的开销而且ServletConfig和成员变量的初始化也会被反复执行影响效率。容器的做法是在客户端第一次请求Servlet时加载Servlet类并创建实例随后将实例缓存到StandardWrapper中后续所有请求都复用这个实例。每个请求由一个工作线程处理多个线程同时调用同一个Servlet实例的service方法就形成了多线程并发访问。Tomcat默认使用线程池来处理请求核心线程数默认是10最大线程数是200队列容量是Integer.MAX_VALUE。这意味着请求会先进入队列排队线程池的工作线程依次从队列里取出任务执行。线程池参数对高并发场景影响很大在面试时如果能主动讲出Tomcat的线程池模型会是个加分项。4.2 成员变量并发问题的经典案例分析因为Servlet是单实例的实例成员变量是共享资源。任何实例变量都可能出现线程安全问题。举个例子如果在Servlet里定义了一个private int count 0;在doGet里执行count那么在高并发场景下这个count的值可能会出现“丢失更新”的情况因为count不是一个原子操作它包含读取、加一、写回三个步骤多个线程同时执行时可能互相覆盖结果。这就是典型的线程安全问题解决办法有几种尽量使用局部变量不定义可变的实例变量。必须共享数据时使用同步机制比如synchronized或Lock。使用线程安全的容器类比如ConcurrentHashMap。用ThreadLocal实现线程隔离。我在实际项目中就踩过这个坑。某个导出功能在Servlet里用了一个SimpleDateFormat作为成员变量结果线上出现偶发的时间格式解析异常。后来发现SimpleDateFormat本身不是线程安全的多个线程共享同一实例解析日期就会出问题。解决方法是改用ThreadLocalSimpleDateFormat或者直接使用Java 8的新日期API。4.3 虚拟线程与异步Servlet带来的新解这个知识点比较新但面试里越来越常被问到。Servlet 3.0开始支持异步处理允许service方法返回后请求仍然挂起由其他线程继续处理这种方式适用于长轮询、SSE推送等场景。实现方法是调用request.startAsync()获取AsyncContext在后续线程里调用asyncContext.complete()结束请求。到了JDK 21时代虚拟线程的出现让传统线程模型又一次被重新审视。Tomcat从10.1版本开始支持虚拟线程每个请求分配一个虚拟线程由于虚拟线程的创建成本极低可以支持海量并发请求。理解这一点有助于你在面试时展现出对技术演进的关注但别急着踩传统线程池虚拟线程在CPU密集场景下并不一定更优IO密集场景才是它的主场。5. 面试实战高频追问与答题要点拆解5.1 关于Filter和Listener的关联追问Servlet规范除了Servlet本身还有两部分内容几乎必问Filter是过滤器Listener是监听器。Filter在请求到达Servlet之前进行拦截可以在doFilter方法中执行校验、日志、编码处理等逻辑然后通过chain.doFilter放行请求。多个Filter形成过滤链顺序由web.xml中的配置顺序或WebFilter注解的filterName决定这一点容易被忽略。Listener则是观察者模式的体现监听Web应用中的事件。三种常见类型ServletContextListener监听应用启动/关闭HttpSessionListener监听Session创建/销毁ServletRequestListener监听请求创建/销毁。在Spring Boot框架中ContextLoaderListener就是ServletContextListener的实现类Spring容器的初始化就发生在contextInitialized回调中。面试时如果能主动说出这个类比会很有说服力。5.2 转发与重定向的本质区别转发forward和重定向sendRedirect也经常被拎出来单独考。转发是在服务器内部完成的浏览器只发起一次请求地址栏不会改变request对象是同一个对象参数可以在转发过程中通过request.setAttribute传递。重定向是服务器返回301或302状态码给浏览器浏览器根据Location响应头发起第二次请求地址栏会改变request对象是全新创建的无法共享之前的参数。从原理层面看转发发生在service方法内部的处理链中容器通过RequestDispatcher把请求转交给另一个Servlet继续处理重定向是直接给浏览器一个“去别的地方访问”的指令服务器不再处理后续逻辑。扩展一下RequestDispatcher不仅支持forward还有includeinclude是把目标Servlet的输出内容包含进当前响应这种用法在模板布局场景出现过。5.3 关于Session与Cookie的关联问题Session的底层实现是面试官喜欢深挖的。会话跟踪的核心机制是容器在第一次创建Session时生成一个唯一的Session ID通过Cookie名称为JSESSIONID发送给浏览器浏览器后续请求会自动携带该Cookie容器据此找到对应的Session对象。如果浏览器禁用了Cookie可以通过URL重写response.encodeURL将Session ID拼接在URL后面。Session的存储是内存还是分布式存储默认Tomcat存储在内存中重启丢失。大项目中往往需要通过SessionManager配置持久化方案比如Redis、Memcached。这里注意一个细节HttpSession也有生命周期默认30分钟不活动就会失效可以通过session.setMaxInactiveInterval调整也可以通过HttpSessionListener监听Session的创建和销毁在销毁时清理关联数据。5.4 关于容器类加载器的追问这一层已经属于比较深的问题了但如果你能答上来自信程度会完全不同。Tomcat的类加载机制不同于JDK的双亲委派它打破了双亲委派模型在部分方向上的限制。Tomcat为每个Web应用创建一个独立的WebAppClassLoader优先加载/WEB-INF/classes下的类其次是/WEB-INF/lib下的JAR包无法加载时才委托给父加载器。这种设计的目的是隔离不同Web应用的类避免多个应用依赖同一个第三方库的不同版本时产生冲突。如果要拿到的是JDK的类如java.lang.String则还是按照双亲委派模型向上查找。面试时可以提一个场景两个Web应用都使用了不同版本的某个JSON库放在各自的lib目录下互不影响这就是独立类加载器的价值。6. 源码级认知与真实项目中的典型问题6.1 读源码最该关注的几个关键类如果你打算往深度走我建议直接去读Tomcat源码不要只看博客。核心类有这么几个StandardWrapper封装Servlet的容器类负责实例化、初始化、调用和销毁Servlet。ApplicationFilterChain过滤链的执行逻辑chain.doFilter会依次调用过滤器最后调用Servlet的service。CoyoteAdapter协议适配器把Coyote请求转换成Servlet请求。Mapper负责URL到Host、Context、Wrapper的映射。ThreadPoolExecutorTomcat自定义的线程池实现。读的时候重点看两条线一条是请求的生命周期从CoyoteAdapter.service进去经过Mapper映射、FilterChain执行、Servlet.service返回一直到响应结束另一条是Servlet的装载流程从ContextConfig解析web.xml到StandardWrapper.loadServlet反射实例化。把这两条线串起来你对“Servlet工作原理”的理解深度已经不亚于大多数工作了三四年的程序员。6.2 真实项目里的几个典型问题我梳理一下实际项目中常见的和Servlet工作机理相关的故障你可以对照自查问题现象根本原因排查思路访问任何路径都返回404URL映射配置错误或WebServlet路径重复查看启动日志中的Mapping信息检查web.xml与注解是否冲突高并发下响应越来越慢线程池饥饿或Servlet存在同步锁等待用jstack导出线程栈观察线程状态与锁竞争热部署后内存溢出destroy未释放资源或监听器未移除检查重部署时的GC日志排查组件注册与反注册逻辑Cookie里的JSESSIONID一直变化Cookie设置了错误的作用域或没有设置HttpOnly检查Set-Cookie响应头确认Path和Domain属性中文乱码请求与响应编码不一致request.setCharacterEncoding(UTF-8)并在服务端配置URI编码jstack是排查并发问题的利器能直接看到线程当前阻塞在哪一行代码。有一次线上出现某接口响应时间大增用jstack一看发现大量线程阻塞在一个SimpleDateFormat的parse锁上这就是之前提到的线程安全问题。6.3 给候选人的终极建议如果面试问到Servlet不要只答生命周期三阶段。我建议按照这条链路组织回答先说明Servlet在Java Web中的地位再说请求完整旅程接着讲生命周期管理然后扩展到Filter、Listener、Session最后补充线程模型和容器类加载器。每个环节给出一两个细节比如“service分为请求分发和业务处理两个阶段”“load-on-startup的正整数值越小优先级越高”“Forward共用Request而Redirect不共用”等这样的回答深度和广度都有。很多人会忽略web.xml中的metadata-complete属性这是一个相对偏门的考点。当它设置为true时容器不扫描注解完全依赖web.xml中的配置不设置或为false时容器会同时扫描注解和配置。在Spring Boot内嵌Servlet容器时默认会开启注解扫描但如果你手动排除了扫描又忘了在配置文件中声明Servlet就会出现注解不生效的情况。这种边角细节能说出来会让面试官觉得你是真的踩过坑。我个人的一个经验是面试前用最简单的手写Servlet跑一遍请求流程不用Spring Boot新建一个普通的Web应用写一个Servlet配置映射在init、service、destroy方法里各打一行日志看控制台输出顺序。这个方法花不到十分钟但比背十篇博客都有用。因为你在日志里看到的那一瞬间那行init called的输出才是你对Servlet生命周期有了身体记忆的瞬间。