servlet 规范(参见我之前的问题)保证同一个线程将执行所有过滤器和关联的 Servlet。鉴于此，如果可以选择使用 ThreadLocal(假设您已正确清理)，我认为使用 HttpServletRequest.setAttribute 传递数据没有任何用处。我觉得使用 ThreadLocal 有两个好处:类型安全和更好的性能，因为没有使用字符串键或映射(除了可能通过(非字符串)线程 ID 进入线程集合)。
有人可以确认我是否正确，以便我可以继续放弃 setAttribute 吗？
最佳答案
Is ThreadLocal preferable to HttpServletRequest.setAttribute(“key”, “value”)?
视具体功能需求而定。
例如，JSF 存储 FacesContext在ThreadLocal .这使您能够访问所有 JSF 工件，包括“原始”HttpServletRequest和 HttpServletResponse FacesServlet 执行的代码中的任何位置，例如托管 bean。大多数其他基于 Java 的 MVC 框架都遵循相同的示例。
根据您的评论，
I primarily need to transport the User and EntityManager objects from the user and database Filters to the Servlet. I also find that these are frequently and unexpectedly needed in code further down the line and I am tempted to use them well beyond the Servlet (i. e. in nested code called by doGet). I feel there may be a better way for deeper code - suggestions?
至于User我假设这是一个 session 属性的示例，我宁愿遵循与 JSF 相同的方法。创建 ThreadLocal<Context> Context在哪里是您的自定义包装类持有对当前 HttpServletRequest 的引用吗？也许还有HttpServletResponse这样您就可以在代码的任何位置访问它们。如有必要，提供方便的方法来获取 User。直接来自 Context类。
至于EntityManager例如，您可以采用相同的方法，但我个人不会将其放在相同 ThreadLocal<Context> 中，而是一个不同的。或者，更好的是，直接从服务层中的 JNDI 获取它，这将允许您对事务进行更细粒度的控制。在任何情况下，请绝对确保您正确处理提交/关闭。从容器中接管持久性和事务管理应该格外小心。我真的会重新考虑对使用现有的和设计良好的 API/框架(如 EJB/JPA)的厌恶，否则你将冒着完全浪费时间的风险重新发明所有已经标准化的 API 和东西。
另见:
关于java - ThreadLocal 是否优于 HttpServletRequest.setAttribute ("key"， "value")？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10096483/