1. 问题现象与背景分析最近在排查一个线上问题时发现部分用户的登录状态会莫名其妙丢失。经过日志分析发现这些请求的Cookie在到达Tomcat服务端时就已经丢失了。这个问题在并发量较高时尤为明显而且很难稳定复现。注意Cookie丢失问题往往与环境强相关需要结合具体场景分析。本文讨论的是Tomcat容器层面的Cookie处理机制问题而非应用代码逻辑问题。在Tomcat 8.5及以上版本中Request对象会被回收重用通过对象池机制。如果在业务代码中通过ThreadLocal缓存了Request对象或者异步线程中引用了Request对象就可能出现Cookie丢失的情况。这是因为当Request对象被回收后其内部属性包括headers、cookies等会被清空。2. 核心原理深度解析2.1 Tomcat请求处理机制Tomcat对每个HTTP请求的处理流程大致如下从连接器Connector接收原始请求创建或从对象池获取Request/Response对象解析请求头包括Cookie交给Servlet容器处理处理完成后回收Request/Response对象关键点在于第2步和第5步 - Tomcat默认会重用Request对象以减少对象创建开销。这就引出了潜在的问题如果这个被重用的Request对象被其他线程引用就可能出现数据污染。2.2 Cookie解析过程当Tomcat接收到请求时会调用org.apache.coyote.Request#parseHeaders方法解析请求头。对于Cookie会专门调用parseCookies方法private void parseCookies() { if (headers.get(cookie) ! null) { ServerCookies serverCookies new ServerCookies(); CookieProcessor cookieProcessor getCookieProcessor(); cookieProcessor.parseCookieHeader(headers, serverCookies); this.cookies serverCookies; } }问题在于当Request对象被回收时this.cookies会被置为null但headers可能不会被清空。这就导致下次重用该Request对象时如果headers中仍有Cookie信息但未被重新解析就会出现Cookie丢失的假象。3. 典型问题场景与复现3.1 ThreadLocal缓存Request对象一个常见的错误模式是在拦截器或工具类中这样使用public class RequestHolder { private static final ThreadLocalHttpServletRequest requestHolder new ThreadLocal(); public static void set(HttpServletRequest request) { requestHolder.set(request); } public static HttpServletRequest get() { return requestHolder.get(); } }然后在Filter中public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { RequestHolder.set((HttpServletRequest)request); try { chain.doFilter(request, response); } finally { RequestHolder.remove(); } }这种模式的问题在于当Tomcat回收Request对象后ThreadLocal中缓存的引用仍然指向被回收的对象当下一个请求复用了这个Request对象时如果直接从ThreadLocal获取而没有重新解析Cookie就会得到错误的数据3.2 异步线程中引用Request对象另一个常见场景是在异步处理中引用Request对象GetMapping(/async) public String asyncHandle(HttpServletRequest request) { CompletableFuture.runAsync(() - { // 异步线程中访问request String cookie request.getHeader(Cookie); // 处理业务逻辑 }); return success; }这种用法的问题类似主线程处理完成后Request对象可能被Tomcat回收异步线程访问时Request对象可能已经被重置4. 解决方案与最佳实践4.1 立即解决方案对于已经出现问题的系统可以采取以下临时方案关闭Request对象重用不推荐生产环境使用 在server.xml中配置Connector ... processorCache-1 /这会禁用Processor缓存影响性能但可以避免对象重用问题。强制重新解析Cookie 在获取Cookie前调用request.getCookies(); // 这会触发重新解析4.2 根本解决方案避免缓存Request对象不要在ThreadLocal中存储Request对象不要在异步线程中直接使用Request对象提前提取所需信息GetMapping(/async-safe) public String safeAsyncHandle(HttpServletRequest request) { // 提前提取需要的Cookie值 String sessionId Arrays.stream(request.getCookies()) .filter(c - JSESSIONID.equals(c.getName())) .findFirst() .map(Cookie::getValue) .orElse(null); CompletableFuture.runAsync(() - { // 使用提取的值而非Request对象 processWithSessionId(sessionId); }); return success; }使用Request包装器 对于必须传递Request的场景可以使用不可变包装器public class ImmutableRequestWrapper extends HttpServletRequestWrapper { private final MapString, String headers; private final Cookie[] cookies; public ImmutableRequestWrapper(HttpServletRequest request) { super(request); this.headers Collections.unmodifiableMap(extractHeaders(request)); this.cookies request.getCookies() ! null ? Arrays.copyOf(request.getCookies(), request.getCookies().length) : new Cookie[0]; } // 重写相关方法返回缓存值 Override public Cookie[] getCookies() { return Arrays.copyOf(cookies, cookies.length); } }5. 深入排查与诊断技巧当遇到Cookie丢失问题时可以通过以下步骤排查确认问题范围是否所有Cookie都丢失还是特定Cookie是否特定浏览器/客户端出现问题是否只在并发情况下出现检查Tomcat版本catalina.sh version不同版本的Tomcat对Request对象的处理策略可能有差异。启用调试日志 在logging.properties中添加org.apache.coyote.level FINE org.apache.catalina.level FINE这会打印Request对象回收和重用的日志。使用诊断工具使用Arthas观察Request对象状态watch org.apache.catalina.connector.Request recycle {params,returnObj,throwExp} -x 3使用JDK Mission Control分析对象分配和回收情况6. 性能优化与最佳实践在解决Cookie丢失问题的同时还需要考虑性能影响CookieProcessor选择 Tomcat提供了两种Cookie处理器LegacyCookieProcessor兼容旧版行为Rfc6265CookieProcessor符合RFC 6265标准可以通过Context配置Context CookieProcessor classNameorg.apache.tomcat.util.http.Rfc6265CookieProcessor / /Context合理设置对象池大小 在server.xml中调整Connector ... processorCache200 /根据实际并发量调整太大浪费内存太小影响性能。减少Cookie大小避免在Cookie中存储过多数据考虑使用Session替代部分Cookie数据7. 相关配置参数参考以下是Tomcat中与Request处理和Cookie相关的关键配置参数参数默认值说明processorCache200Processor对象池大小-1表示禁用maxKeepAliveRequests100保持连接的最大请求数connectionTimeout20000连接超时时间(ms)maxCookieCount200单个请求最大Cookie数量maxHeaderCount100最大请求头数量maxParameterCount10000最大参数数量8. 常见问题解答Q1为什么只在生产环境出现这个问题A通常是因为生产环境的并发量更高Request对象重用更频繁更容易暴露问题。开发环境请求量小可能很难复现。Q2升级Tomcat版本能解决吗A不一定。这个问题与对象重用机制有关不同版本的表现可能不同但根本原因还是代码使用方式问题。Q3除了Cookie还会有其他数据丢失吗A是的。Request对象的所有属性都可能受到影响包括headers、parameters等。只是Cookie问题更容易被发现。Q4如何验证我的修复是否有效A可以使用压力测试工具如JMeter模拟高并发请求检查Cookie是否保持一致。也可以编写单元测试模拟Request重用场景。Q5Spring Boot应用中如何避免这个问题ASpring Boot的自动配置已经考虑了这些问题但如果你自定义了Tomcat配置或直接操作Request对象仍可能遇到。建议使用Spring提供的RequestContextHolder而非自己实现ThreadLocal缓存。