使用ThreadLocal作为Web应用程序中数据的上下文是一个好主意吗？
答案 0 :(得分：6)
这就是它的目的。但要注意在上下文末尾删除ThreadLocal，否则可能会在内存泄漏中运行，或者至少将未使用的数据保留太久。
ThreadLocals也非常快，您可以将其视为HashMap<Thread,Object>，始终使用Thread.getCurrentThread()进行查询。
答案 1 :(得分：6)
这取决于数据的范围。 ThreadLocal将特定于请求线程，而不是特定于用户的会话（每个请求，可以使用不同的请求处理线程）。因此，在请求处理完成时删除数据非常重要（这样当相同的线程为其请求提供服务时，它不会渗透到其他用户的会话中）。
答案 2 :(得分：2)
如果您正在使用单个线程完成请求/响应对，那么根据我的经验，它可以正常工作。然而，随着ajax和高性能容器的兴起，“事件驱动”的webapps正在流行。这些事件驱动的模型允许将请求线程返回到它们的线程池，例如，在I / O事件期间，使线程没有被占用等待外部服务调用返回。结果，单个逻辑请求可以由多个不同的线程服务。事件驱动的体系结构与服务器端的NIO相结合可以提高吞吐量。
话虽如此，如果您的应用程序没有这种架构，那对我来说似乎是合理的。
如果您不熟悉此型号，请查看Tomcat 6的“彗星”和Jetty 6的Continuations。这些是特定于供应商的异步I / O挂起官方Servlet 3.0支持的实现。请注意，Tomcat 7声称现在完全符合3.0标准。
答案 3 :(得分：1)
ThreadLocal与非线程程序中的静态/全局程序非常相似。也就是说，使用ThreadLocal是令人厌恶的。
答案 4 :(得分：1)
总的来说，我会说不。使用框架为您做到这一点。
在Web应用程序的Web层中，使用会话上下文（或其他特定于顶层框架的上下文）来存储数据和状态而不是请求范围。
如果您引入业务层，它当然不应该依赖于特定的Web上下文。 spring和Java EE提供安全性，事务和持久性的解决方案作为上下文。
如果你手动触摸它，你应该非常小心;它可能导致清理问题，内存泄漏和奇怪的错误......