从Tomcat迁移到Netty：filter中塞入的ThreadLocal值却无法获取值了

当我们从基于Servlet的服务器（例如Tomcat）迁移到事件驱动的服务器（例如Netty）时，可能会遇到一些预料之外的问题。今天我们将深入探讨其中一个问题，这个问题涉及到ThreadLocal的使用。我们会通过代码示例来阐述这个问题，以及如何解决。

问题描述

让我们从一个常见的场景开始，我们在基于Tomcat的应用中使用Filter来设置ThreadLocal的值：

public class UserFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        User user = getUserFromRequest(req);
        UserContext.set(user);
        chain.doFilter(req, res);
    }
}

在这个示例中，我们从请求中获取User对象，然后将其存储在ThreadLocal中，以供后续的请求处理逻辑使用。在Tomcat中，这种模式是有效的，因为整个请求从开始到结束都是由同一个线程处理的。

然而，当我们将应用迁移到Netty时，情况就不一样了。Netty使用事件驱动的模型，IO操作（比如读取请求数据）和业务逻辑处理是在不同的线程中进行的。这就意味着，如果Filter在IO线程中执行，那么在后续的业务逻辑处理线程中就无法获取到在Filter中设置的ThreadLocal值。

解决方案

要解决这个问题，我们可以将设置ThreadLocal值的逻辑从Filter移动到Interceptor中。这是因为Interceptor是在Spring的上下文中运行的，因此它始终在和业务处理逻辑相同的线程中执行。

以下是一个改进的示例：

public class UserInterceptor implements HandlerInterceptor {
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        User user = getUserFromRequest(request);
        UserContext.set(user);
        return true;
    }
}

在这个改进的示例中，我们将设置User的逻辑移到了Spring的Interceptor中。由于Interceptor是在处理请求的业务线程中执行的，因此我们可以确保在后续的业务逻辑中能够获取到ThreadLocal的值。

总结

在迁移到新的服务器框架时，理解线程模型和请求处理流程是至关重要的。这不仅可以帮助我们避免意料之外的问题，也可以让我们更好地利用新框架的功能和性能。在这个例子中，通过理解和适应新框架的线程模型，我们成功地解决了一个关于ThreadLocal使用的问题。希望这个例子可以帮助那些正在考虑或已经开始从Servlet服务器迁移到事件驱动服务器的开发者。