nec*_*cer 8 java servlets thread-local java-ee servlet-filters
servlet规范(参见我之前的问题)保证相同的线程将执行所有过滤器和相关的Servlet.鉴于此,HttpServletRequest.setAttribute如果可以选择使用a ThreadLocal(假设您正确清理),我认为没有使用传递数据的任何用途.我觉得使用有两个好处ThreadLocal:类型安全和更好的性能,因为没有使用字符串键或映射(除非可能通过(非字符串)线程ID进入线程集合).
有人可以确认我是否正确,所以我可以继续放弃setAttribute？
\n\n\nThreadLocal 是否优于 HttpServletRequest.setAttribute(\xe2\x80\x9ckey\xe2\x80\x9d, \xe2\x80\x9cvalue\xe2\x80\x9d) ？
\n
取决于具体的功能需求。
\n\n例如，JSF 将其存储FacesContext在ThreadLocal. 这使您能够访问所有 JSF 工件，包括“原始”工件HttpServletRequest以及HttpServletResponse由 JSF 执行的代码中的任何位置。FacesServlet，例如托管 bean。大多数其他基于 Java 的 MVC 框架都遵循相同的示例。
根据你的评论，
\n\n\n\n\n我主要需要将 User 和 EntityManager 对象从用户和数据库过滤器传输到 Servlet。我还发现，这些在代码中经常意外地需要，并且我很想在 Servlet 之外使用它们（即在 doGet 调用的嵌套代码中）。我觉得可能有更好的方法来更深入的代码 - 建议？
\n
至于User我假设这是一个会话属性的示例，我宁愿遵循与 JSF 相同的方法。创建一个自定义包装类，ThreadLocal<Context>其中Context保存对当前的引用HttpServletRequest，也许还可以HttpServletResponse这样您可以在代码中的任何位置访问它们。如有必要，提供方便的方法，以User直接从Context。
至于EntityManager示例，您可以遵循相同的方法，但我个人不会将其放在同一个 ThreadLocal<Context>中，而是放在不同的方法中。或者，更好的方法是从服务层的 JNDI 获取它，这将允许您对事务进行更细粒度的控制。无论如何，请绝对确保正确处理提交/关闭。从容器接管持久性和事务管理应该非常小心。我真的会重新考虑对使用现有且设计良好的 API/框架（如 EJB/JPA）的厌恶，否则您将面临完全浪费时间重新发明所有已经标准化的 API 和内容的风险。