【发布时间】：2010-03-24 02:18:33
【问题描述】：
到目前为止，我们一直在使用 ThreadLocal 来承载一些数据，以免使 API 混乱。但是下面是一些我不喜欢使用本地线程的问题
1) 多年来，本地线程中携带的数据项有所增加 2）由于我们开始使用线程（用于一些轻量级处理），我们也将这些数据迁移到池中的线程并再次将它们复制回来
我正在考虑为这些使用内存数据库（我们不想将其添加到 API 中）。我想知道这种方法是否很好。有什么好处和坏处。
好的，这是一个简单的场景
- 用户登录并提交请求
- 系统为此整个请求建立上下文，其中包括 - 此请求的唯一 ID - 用户名 - 系统登录（用户可以登录多个系统） - 一些域事件供以后使用
- 请求通过多个逻辑层（表示层、业务域、 规则，集成）等
- 在集成层，我们从池中借用少量线程来并行拉取数据 多个合作伙伴。每个 pull 都需要一些之前存储在线程本地的数据，所以我们将这些数据迁移到池线程中
- 在收到伙伴的所有数据后，我们将子线程中积累的新线程本地数据迁移回主线程
- 在交互结束时，我们将 DOMAIN 事件保存到 DB
【问题讨论】：
-
我担心您使用 ThreadLocal。您是否担心并发问题？如果不是，那为什么要使用 ThreadLocal？如果是，那么您是否计划为每个正在运行的线程建立一个内存数据库？
-
数据项对于给定的请求是唯一的，我们不想到处传递这些数据......我们为每个事务（或请求）生成一个唯一的密钥，我可以集中存储数据（当前在 threadlocal 中）针对唯一键
-
现在很难回答这个问题，因为不清楚用例是什么。您可能需要添加一些说明性代码。
-
我的意思是，
ThreadLocal中的key本身就是Thread，对吧？然后你有另一个唯一的钥匙？？至于“传递数据”，通常会封装任何数据并传递对它的引用。似乎与混乱的 API 没有任何关系。我很困惑.. -
@Pangea：我认为内存数据库对此有点过分了。特别是如果数据是临时的。但这很难说，因为我真的不知道存储的数据类型。我建议您研究另一种存储解决方案。可能类似于位于中心位置的 ConcurrentHashMap。这样，如果您确实找到了解决此设计缺陷的方法，那么很容易消除。
标签： java thread-local