Servlet这东西说起来有点“老”但如果你想搞明白Java Web到底是怎么跑起来的它还真躲不开。我带团队和面试新人的时候发现一个现象不少人上来就学Spring Boot写接口已经非常熟练但你把问题往回问一层——浏览器发出一个HTTP请求之后数据是怎么一步步走到你的Java方法里的很多人就答不上来了。Servlet恰恰就是那个被跳过的“底层”。这篇内容不打算做教科书式的功能罗列。我会从一个实际写过大量Servlet代码的人的角度帮你把Servlet的核心体系、生命周期、请求处理链路、从零搭建一个可运行的项目、以及那些在真实环境里一定会踩的坑一次性讲透。无论你是刚学Java Web的初学者还是用框架两年但没看过底层的开发者这篇文章都值得花二十分钟看完。1. Servlet的核心体系与设计思路1.1 Servlet到底解决了什么问题要理解Servlet的价值得先看它出现之前的Web开发是什么样子。早期的CGI公共网关接口时代服务器每收到一个HTTP请求就要为这个请求创建一个独立的操作系统进程。进程的创建、销毁、上下文切换都是重量级操作并发一高服务器的资源就迅速耗尽。Servlet的出现改变了这个局面。它跑在JVM进程内部容器比如Tomcat启动后Servlet类被加载并实例化一次之后所有请求都复用这同一个实例由容器从线程池中分配工作线程来处理每个请求。换句话说从“一个请求一个进程”变成了“一个请求一个线程”资源开销降低了一个数量级这也是Servlet能成为Java Web基石的最根本原因。另一个关键价值是它提供了统一的请求-响应抽象。HTTP报文是纯文本协议如果让你自己从Socket读取数据再解析请求行、请求头、请求体那写起来又繁琐又容易出错。Servlet规范里定义了HttpServletRequest和HttpServletResponse把报文内容封装成Java对象你只需要调用方法就能拿到参数、读取流、写出响应。开发者的关注点因此被大大简化不用关心Socket不用关心TCP不用手工拼HTTP响应报文只需要在Servlet里写业务逻辑。打个比方Servlet是处理具体业务的“员工”Tomcat这类容器是“前台行政后勤”它负责接电话网络监听、帮你把电话内容整理成工单Request对象、再把你的回复转达给对方Response对象。1.2 容器与Servlet的协作关系很多人把Tomcat和Servlet混为一谈其实它们的分工完全不同。Tomcat是Servlet容器它实现了Servlet规范负责管理Servlet的整个生命周期同时承担HTTP服务器的职责——监听端口、接受连接、解析协议、管理线程池。Servlet本身只是一个遵循规范编写的Java类它不知道网络连接的存在。两者通过一套标准接口通信这套接口就是Servlet API。容器从端口收到HTTP请求后解析请求数据创建一个Request对象和一个Response对象然后按照映射规则找到处理这个URL的Servlet调用它的service()方法把两个对象传进去。Servlet处理完业务逻辑后把结果写入Response对象容器再把Response对象中的内容包装成HTTP响应报文通过网络返回给客户端。这种分级设计带来的好处是可以遵循“约定优于配置”的思路——你不必关心容器是怎么实现的只要Servlet类写得符合规范换一个容器Tomcat、Jetty、Undertow照样能跑。这也是为什么Servlet规范存在了二十多年依然是Java Web世界的基石。2. Servlet的核心运行机制与生命周期2.1 生命周期那五个阶段Servlet的一生可以用五个节点概括加载、实例化、初始化、服务、销毁。看起来简单但每个节点的时机和执行次数都暗藏细节。加载和实例化一般发生在两个时间点容器启动时或者第一次请求到达时。 具体取决于配置的load-on-startup属性。在web.xml里给Servlet配一个正整数比如1容器启动时就会提前实例化它值越小启动优先级越高。如果不配置默认是首次请求时才创建实例。实例化完成后容器调用init(ServletConfig)做初始化。这个方法在整个生命周期中只执行一次。 init方法里适合做什么读取初始化参数、初始化数据库连接池、启动后台线程、加载配置文件等一次性工作。如果这里抛出ServletException说明初始化失败这个Servlet会被标记为不可用容器会销毁它。很多新手不知道这个特性把初始化逻辑写在构造方法里导致拿不到ServletConfig配置。规范要求你必须在init方法里调用super.init(config)否则后续拿不到配置对象。服务阶段是请求进来时执行对应service()方法。这里有一个必须刻进脑子的事实Servlet是单实例多线程的。容器会从线程池抽调线程多个线程同时执行同一个Servlet实例的service()方法通过它分发到doGet/doPost方法里。实例变量是所有线程共享的如果写代码不设防高并发下就会出现数据错乱。销毁阶段由容器调用发生在应用卸载或容器关闭时。通常只有一次。 你可以在destroy()里释放连接池、停止后台线程。但要注意容器不保证destroy一定在JVM退出前被调用比如进程被强杀的情况。所以重要的持久化动作不要写在这里数据落库这种操作应该在业务代码里同步完成。2.2 请求处理核心链路一次请求从浏览器发出到Servlet处理完中间经过的环节比大多数人想象的多。拆开看是这样的浏览器输入URL并访问DNS解析域名得到IP建立TCP连接发出HTTP请求报文。报文到达Tomcat时由连接器Coyote组件负责监听和读取字节流。连接器解析完请求行、Header、Body之后根据配置把数据封装成org.apache.catalina.connector.Request一个实现了HttpServletRequest接口的对象。接着请求进入容器内部管道Engine - Host - Context逐级匹配虚拟主机和Web应用最终定位到目标Servlet以及它所属的Filter链。这里有一点值得展开请求在到达Servlet之前会先经过当前应用的所有匹配的过滤器。Filter是Servlet规范里一个非常重要的扩展点。一个常见的用途是统一编码设置——在过滤器里对每个请求调用request.setCharacterEncoding(UTF-8)这样所有Servlet都不用再重复设置请求编码。另一个典型用途是登录校验判断Session是否存在如果未登录直接重定向到登录页不放行到Servlet。请求真正进入Servlet后容器调用Servlet的service(ServletRequest, ServletResponse)方法。这个方法是从GenericServlet继承下来的HttpServlet在实现时会对请求对象做向下转型然后根据HTTP方法类型自动分发到doGet、doPost、doPut、doDelete等方法。如果你在Servlet里重写了doGet但没有重写doPost而客户端用POST提交默认行为是返回405错误提示Method Not Allowed。2.3 关键API与高频方法速查HttpServletRequest和HttpServletResponse这两个对象是开发者每天打交道的核心API熟练者闭着眼也能写出来但新手经常混淆一些方法的使用场景。从请求对象拿数据最常见的是下面这些getParameter(name)取请求参数的聚合方法同时支持URL上的查询参数和POST表单中的body参数。注意它只适合读取普通文本不适合读取JSON请求体。getHeader(name)读取请求头。做鉴权时经常用来取Authorization头。getSession() / getSession(true)获取或创建当前会话。getRequestDispatcher(path)获取转发器。配合forward()可以把请求转发给另一个Servlet或JSP客户端看到的URL不会改变这是转发和重定向的一个核心区别。setAttribute / getAttribute在请求范围内传递数据。通常在Servlet里把数据处理结果放入request再转发给JSP渲染。从响应对象写数据核心是下面这些setContentType(text/html;charsetUTF-8)先设置Content-Type其中charset同时规定了响应体的编码方式直接影响浏览器如何解码。setCharacterEncoding(UTF-8)单独设置响应字符编码注意必须在getWriter()被调用之前执行。getWriter()返回PrintWriter适合输出文本内容。getOutputStream()返回ServletOutputStream适合输出二进制内容比如图片、文件下载。两者不能同时使用。sendRedirect(url)重定向浏览器会重新发起一个新请求URL会改变。ServletConfig和ServletContext也经常用到。ServletConfig是单个Servlet的配置对象对应web.xml中该Servlet下的 ServletContext是全局应用对象整个Web应用只有一份适合存放全局配置和应用级别的共享数据。比如一个数据源连接可以在ServletContextListener中初始化后放进ServletContext所有Servlet都能取到。3. 从零搭建一个可运行的Servlet项目3.1 环境准备与工程结构动手写代码之前先列一下需要的东西JDK 8或更高版本、IDEA或你顺手IDE、Maven、一个本地的Tomcat。我用的是Tomcat 9来配合Servlet 4.0规范你选Tomcat 10之前要注意它的Servlet API包名已经从javax.servlet迁移到了jakarta.servlet很多老教程的代码在不改导入包的情况下直接跑不起来这一点必须提前提醒。新建一个Maven项目group/artifact随意。在pom.xml里加Servlet API依赖但一定记得把scope设置为provideddependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependencyprovided的意思是编译时需要但打包部署时不包含。因为Tomcat自己带了Servlet API的实现你要是把Servlet依赖打成war包带进去运行时会和容器自带的类冲突典型情况是出现NoSuchMethodError或ClassCastException非常难排查。标准的Web应用目录结构长这样src/main/java # Java源代码 src/main/webapp/ # Web根目录 src/main/webapp/WEB-INF/ src/main/webapp/WEB-INF/web.xmlWEB-INF目录是Web应用的私有区域外部浏览器无法直接访问它下面的任何资源。web.xml是部署描述符Servlet 3.0之后它不是必须的了但加上它有些场景会很方便后面详细说。 还应该建立一个index页面如果要是部署后访问根路径需要一个默认欢迎页面通常在这里配。index.html可以写一个最简单的页面把地址指向后面的Servlet。3.2 写第一个能处理的Servlet写一个Servlet其实非常直接继承HttpServlet重写doGet或doPost。下面这个例子是一个返回JSON数据的接口package com.example.demo; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; WebServlet(/hello) public class HelloServlet extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType(application/json;charsetUTF-8); String json {\code\:0,\message\:\success\,\data\:\Hello Servlet\}; resp.getWriter().write(json); } }为什么要继承HttpServlet而不是直接实现Servlet接口因为Servlet接口里定义了一堆生命周期方法而这些方法在GenericServlet里大部分都有了默认空实现HttpServlet进一步帮你在service()中做好了doGet/doPost的分发。你如果直接实现Servlet接口就得自己从ServletRequest里判断请求方法然后手动分流纯属给自己找麻烦。注意一个细节doGet方法的签名上没有throws ServletException而doPost在HttpServlet里是这个异常。如果你的业务代码需要抛出ServletException可以自行在方法上声明不会影响容器调用。重写与否的关键是方法签名要与父类一致参数类型不能变。3.3 配置映射的两种方式写好了Servlet类接下来要告诉容器访问路径。上面代码里用了WebServlet(/hello)这行注解这是Servlet 3.0开始支持的写法容器启动时会自动扫描注解并注册Servlet。省事是省事但对路径的管理分散在各个类里。另一种方式是使用web.xml配置。假设我们要把HelloServlet映射到/cli路径web.xml这样写?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd version4.0 servlet servlet-namehello/servlet-name servlet-classcom.example.demo.HelloServlet/servlet-class load-on-startup1/load-on-startup init-param param-nameadminPhone/param-name param-value13800000000/param-value /init-param /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-app用xml的好处是init-param、load-on-startup这些额外配置在注解方式下配置起来很别扭。注解虽然提供了initParams属性可以配置初始化参数但代码可读性明显不如xml直观。 你在真实项目里两者都会见到所以要都会看。url-pattern的匹配规则也要弄清楚。它有三种主流写法精确匹配比如/hello路径匹配比如/api/此时访问/api/anything都能命中扩展名匹配比如.do所有以.do结尾的URL都能命中。 有个容易坑人的点是“/”这个写法它匹配所有URL如果你是用来做过滤器一般没问题但如果你把Servlet映射到/它会拦截包括静态资源在内的所有请求导致很多行为变得奇怪。3.4 部署与验证在IDEA里跑Servlet项目最直接的方式是配置Tomcat运行环境。进入Run菜单选择Edit Configurations点加号找到Tomcat Server选Local。在Deployment标签页里点加号选择Artifact把项目的war包或war exploded加进去。两者区别是war包是完整打包的压缩包需要容器解压war exploded是展开目录启动更快开发调试时能实现热更新。配置好之后注意Application context这个值。如果你设置为/访问路径就是http://localhost:8080/hello如果你设置为/servlet-demo那路径就变成http://localhost:8080/servlet-demo/hello。很多新手第一次部署后访问404多半就是这里少加了context-path。启动后控制台看到“Server startup in xxx ms”说明容器起来了。浏览器访问对应地址页面返回JSON字符串第一个Servlet就算跑通了。这个完整流程虽然简单但它是理解后面所有Java Web框架的起点——Spring MVC的核心入口本质上就是一个大ServletDispatcherServlet只是它在内部做了更强大的路由分发和依赖注入。4. 常见问题与实战排查4.1 中文乱码问题详解乱码是Servlet开发中遇到最多的坑没有之一。它不是一个问题是三个不同环节的问题。请求编码。 如果客户端以POST方式提交表单请求体里的中文参数要能被正确读取必须在你读取第一个参数之前调用request.setCharacterEncoding(UTF-8)优先级最高的位置是Servlet代码的第一行或者在Filter里统一设置这点前面提过。如果你已经调用过getParameter再设置编码是无效的因为参数已经按旧编码解析过了。GET请求的编码又不一样。Tomcat 8开始默认对URI使用UTF-8解码所以一般问题不大但如果你用老版本的容器URL里的中文参数会变成乱码。老版本上你可以修改server.xml中Connector节点的URIEncoding属性改成UTF-8。不过现在的Tomcat基本不用动这个配置除非谁还在维护老古董版本。响应编码。 输出中文乱码通常是因为响应没用UTF-8。正确做法是在拿Writer之前同时设置resp.setContentType(text/html;charsetUTF-8); resp.setCharacterEncoding(UTF-8);setContentType中的charset会影响Content-Type响应头setCharacterEncoding负责实际编码。其实只要setContentType里包含了charset容器就会用它来编码但为了保险起见显式双写也不多余。 还有一个更隐蔽的坑你的页面声明了UTF-8但服务端输出时用了ISO-8859-1浏览器按页面声明的UTF-8解码结果就是“锟斤拷”那种乱码。排查思路是从浏览器Network面板看响应头里的charset再对照实际页面输出验收。4.2 HTTP状态码错误排查你部署Servlet时最常遇到的几个状态码基本都能对应到特定原因。404 Not Found意味着请求的URL在服务器上找不到匹配项。排查顺序是先看地址栏的context-path对不对再看servlet的url-pattern映射是否匹配最后看应用是否成功部署。IDEA里最常见的迷之404是修改了url-pattern后没有重新部署war包Tomcat还在跑旧代码。405 Method Not Allowed说明URL找到了Servlet但该Servlet没有处理当前请求类型的方法。比如URL映射到了Servlet但客户端发的是POST而Servlet只重写了doGet。记住HttpServlet的默认行为就是这样对不支持的请求方法返回405。500 Internal Server Error是最通用的服务器内部错误。打开IDEA控制台或Tomcat的logs目录找到最新日志文件重点看Caused by后面的堆栈。大多数情况下是空指针、类型转换、或者初始化异常。要注意的是如果你在web.xml里没配error-page容器会显示一个默认的500错误页真正的异常信息在服务器日志里不在浏览器页面上所以不要只盯着页面看。4.3 Servlet线程安全问题深度解析线程安全是Servlet进阶路上绕不过去的坎。前面说了Servlet是单实例多线程的这意味着所有实例变量的值都会在多个线程之间共享。看下面这个例子WebServlet(/counter) public class CounterServlet extends HttpServlet { private int count 0; Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { count; resp.getWriter().write(count count); } }这代码单线程跑没问题但并发下count的累加会丢失。两个线程同时读到count10各自加1后写回11结果应该是12却变成了11。这里可以用AtomicInteger解决但更重要的是理解问题的本质类字段是共享的方法内局部变量是每个线程各有一份的。再举一个开发中几乎必踩的坑在Servlet里使用SimpleDateFormat。这东西不是线程安全的多个线程同时格式化同一实例会得到错误数据。解决办法是用ThreadLocal保存SimpleDateFormat实例或者在Java 8之后直接用新的时间APILocalDate/LocalDateTime配合DateTimeFormatter它就是线程安全的。还有一个经验法则Servlet代码尽量写成“无状态”的。能用局部变量解决的问题不要用字段必须共享的字段要么是只读的配置数据要么使用线程安全集合或原子类。锁定一段业务代码也行但不要锁太久否则高并发下性能直接崩掉。4.4 Session机制与状态保持实战HTTP协议本身是无状态的每个请求都可以看成是独立的。Session机制就是靠Cookie来让服务端能认出“这是同一个用户”。第一次请求时容器调用req.getSession()会创建一个会话同时通过响应头Set-Cookie设置一个名为JSESSIONID的Cookie给浏览器。后续每个请求浏览器会自动带上这个Cookie容器据此找到之前的Session对象。实战中最常见的Session相关问题是“会话莫名其妙丢失”。排查要点有这几个一是检查Cookie是否正常生成以及路径是否正确。默认情况下JSESSIONID的Cookie路径是当前Web应用的context-path也就是说一个应用设置的Session Cookie不会被另一个应用读取这是符合预期的。二是部分部署环境使用域名不加端口方式访问JSESSIONID的Cookie如果设置了Secure或SameSite属性某些情况下可能导致跨域携带失败。三是浏览器禁用了Cookie那Session基本是不可用的这种情况下很多框架会退化成URL重写来传递Session ID。Session超时时间默认一般是30分钟可以在web.xml里调整session-config session-timeout60/session-timeout /session-config单位为分钟。这个配置是分钟还是秒曾经有人问过我规范写得很清楚是分钟。还有一个在集群部署时躲不开的问题Session共享。默认每个Tomcat节点的Session各自为政用户在节点A登录了下一次请求被负载均衡转发到节点B节点B不认识这个Session用户就被判定为未登录。常见的解决方案是Spring Session外加Redis存储把Session数据集中到一个Redis集群里所有节点都从Redis读写Session。理解了这个背景再看Spring Session的使用就会通透很多。4.5 一些容易忽略的实战细节上面这些大的问题上手之后还有些零碎的小细节值得知道。比如重定向和转发的区别。转发是服务器内部的跳转整个过程只有一次请求浏览器地址栏URL不变。重定向是服务器给浏览器返回一个302状态码和新的Location地址浏览器再发起第二次请求地址栏会变化。服务端代码里转发能用request.getRequestDispatcher(target).forward()重定向用response.sendRedirect(target)。原则是数据要从Servlet带过去给下一个页面展示用转发支付跳转这类需要用户看到地址变化的用重定向。再比如请求体比较大的场景。表单编码为multipart/form-data时Servlet 3.0之后可以直接用request.getPart()获取上传的文件部分而不需要引入第三方组件。相关配置是把MultipartConfig放到Servlet上。不过真实项目里处理上传一般还是用框架提供的功能或者直接走对象存储的上传URL因为大文件直接经过应用服务器效率不高而且会占用连接和线程资源。4.6 如何快速定位线上问题最后分享几个定位线上Servlet问题的经验。很多时候报错发生在生产环境而不是本地排查步骤可以先沿着日志走。Tomcat的logs目录下面会有几个文件localhost.log记录应用启动和报错信息catalina.out记录容器本身的运行日志access log记录每一次请求的访问情况。如果你配置了access log并开了请求耗时记录你可以精确到每一次请求的处理时长判断是某个接口变慢了还是整体都慢了。对接口返回的内容不对但本地又复现不出来可以优先考虑是不是环境差异导致的。比如本地JDK版本和生产不一致比如本地容器是Tomcat 9而线上是Jetty这些差异虽然小但偶尔会在某些边界条件下爆发。还有一个排查方向是请求头的变化比如上线了新的反代设备它有没有改写Host头、有没有在转发时去掉某些请求头字段这些都会影响Servlet侧读取到的数据。我发现一个非常实际的做法在Servlet入口处加一行日志打印请求URL、参数、客户端IP、耗时看到整个请求生命周期。踩过几次坑之后你就发现很多问题的答案其实就藏在日志里关键是你要知道去哪看、看什么。写在最后的体会如果你认真从头看到了这里你实际上已经具备了自己手写Servlet应用的能力。坦率讲Servlet这个技术确实不够时髦很多新人一上来就学Spring Boot完全没有碰过Servlet。但我个人体会是Servlet问题搞明白了Spring MVC里的DispatcherServlet、HandlerMapping、拦截器理解起来都会顺利得多因为框架本质上就是Servlet外面的华丽包装。最后再分享一个小建议找时间自己从零建一个Servlet项目不要用任何框架手动写一个带登录、Session判断、几个前端页面的小Demo。你亲手处理过这些底层细节之后再看任何Java Web框架的文档很多都会觉得原来如此。这份动手经验带来的收益远比多看几篇框架教程要大。