java - 使用 ThreadLocal 对象存储 Web 请求元数据是一种不好的做法吗？

Question

我正在开发一个分为几个模块的 j2ee webapp。我有一些元数据，例如我想从应用程序的任何位置访问的用户名和首选项，并且可能还会收集类似于日志记录信息但特定于请求的数据并将其存储在这些元数据中，以便我可以选择将其发回作为用户的调试信息。

除了从上层表示类到下层 daos 或使用 AOP 的每个方法中传递通用上下文对象之外，想到的唯一解决方案是使用与 session BTW 非常相似的线程本地“上下文”对象，并添加一个过滤器，用于根据正在进行的请求绑定(bind)它并在响应时解除绑定(bind)。

但是这样的事情感觉有点老套，因为它打破了几种模式，并且在测试和调试时可能会使事情变得复杂，所以我想问一下，根据您的经验，这样进行是否可以？

Answer 1

ThreadLocal 是一种弥补不良设计和/或架构的技巧。这是一个糟糕的做法:

1. 它是一个或多个全局变量的池，任何语言的全局变量都是不好的做法(有一整套与全局变量相关的问题 - 在网上搜索)
2. 如果处理不当，在任何管理其线程的 J2EE 容器中都可能导致内存泄漏。

更糟糕的做法是在各个层中使用 ThreadLocal。从一层到另一层的数据应使用传输对象(一种标准模式)传递。

很难找到使用 ThreadLocal 的充分理由。也许如果您需要在两层之间传递一些值，而两层之间有第三层/中间层，而您没有办法对该中间层进行更改。但如果是这样的话，我会寻找一个更好的中间层。
在任何情况下，如果您将值存储在代码中的一个特定点并在另一个点检索它，那么它可能是可以原谅的，否则您永远不知道任何执行方法可能对 ThreadLocal 中的值产生什么影响。