扩展 java 的 ThreadLocal 以允许在所有线程中重置值

看完之后这个问题 https://stackoverflow.com/questions/2795447/is-there-no-way-to-iterate-over-or-copy-all-the-values-of-a-java-threadlocal，我想我想包装ThreadLocal来添加重置行为。

我想要有一个类似于 ThreadLocal 的东西，我可以从任何线程调用一个方法来将所有值设置回相同的值。到目前为止我有这个：

public class ThreadLocalFlag {

    private ThreadLocal<Boolean> flag;
    private List<Boolean> allValues = new ArrayList<Boolean>();

    public ThreadLocalFlag() {
        flag = new ThreadLocal<Boolean>() {
            @Override protected Boolean initialValue() {
                Boolean value = false;
                allValues.add(value);
                return value;
            }
        };
    }

    public boolean get() {
        return flag.get();
    }

    public void set(Boolean value) {
        flag.set(value);
    }

    public void setAll(Boolean value) {
        for (Boolean tlValue : allValues) {
            tlValue = value;
        }
    }
}

我担心原语的自动装箱可能意味着如果我尝试设置它们，我存储在列表中的副本将不会引用 ThreadLocal 引用的相同变量。我还没有测试过这段代码，对于像这样棘手的事情，我正在寻找一些专家的建议，然后再继续沿着这条路走下去。

有人会问“你为什么要这样做？”。我正在一个框架中工作，其中有其他线程回调到我的代码中，但我没有对它们的引用。我想定期更新他们使用的 ThreadLocal 变量中的值，因此执行该更新需要使用该变量的线程进行更新。我只需要一种方法来通知所有这些线程它们的 ThreadLocal 变量已过时。

我很高兴最近对这个三年前的问题有了新的批评，尽管我觉得它的语气有点不专业。我提供的解决方案在那段时间在生产中没有发生任何事故。然而，肯定有更好的方法来实现引发这个问题的目标，我邀请批评者提供一个明显更好的答案。为此，我将尝试更清楚地说明我试图解决的问题。

正如我之前提到的，我使用的框架中有多个线程正在使用我的代码，超出了我的控制范围。该框架是 QuickFIX/J，我正在实施应用接口 http://www.quickfixj.org/quickfixj/javadoc/1.5.3/quickfix/Application.html。该接口定义了用于处理 FIX 消息的钩子，在我的使用中，框架被配置为多线程，以便可以同时处理与应用程序的每个 FIX 连接。

但是，QuickFIX/J 框架仅为所有线程使用该接口的单个​​实现实例。我无法控制线程的启动方式，每个线程都使用不同的配置详细信息和其他状态来服务不同的连接。让某些经常访问但很少更新的状态存在于各种不同的环境中是很自然的。ThreadLocal一旦框架启动线程，就会加载它们的初始值。

在组织的其他地方，我们拥有库代码，允许我们注册回调以通知运行时更改的配置详细信息。我想注册该回调，当我收到它时，我想让所有线程知道是时候重新加载这些值了ThreadLocals，因为它们可能已经改变。该回调来自我无法控制的线程，就像 QuickFIX/J 线程一样。

我的解决方案如下使用ThreadLocalFlag（一个包裹着的ThreadLocal<AtomicBoolean>）只是为了向其他线程发出信号，表明可能是时候更新它们的值了。回调调用setAll(true)，并且 QuickFIX/J 线程调用set(false)当他们开始更新时。我淡化了并发问题ArrayList因为添加列表的唯一时间是在启动期间，并且我的用例小于列表的默认大小。

我想可以使用其他线程间通信技术来完成相同的任务，但对于它正在做的事情来说，这似乎更实用。我欢迎其他解决方案。

跨线程与 ThreadLocal 中的对象交互

我首先要说的是，这是一个坏主意。ThreadLocal is a 特殊班 https://stackoverflow.com/a/15653015/113632提供速度和线程安全的优势如果使用正确的话。尝试与 a 跨线程通信ThreadLocal首先就违背了使用该类的目的。

如果您需要跨多个线程访问对象，则可以使用为此目的设计的工具，特别是线程安全集合java.util.collect.concurrent https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html例如ConcurrentHashMap http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html，您可以用它来复制ThreadLocal通过使用Thread对象作为键，如下所示：

ConcurrentHashMap<Thread, AtomicBoolean> map = new ConcurrentHashMap<>();

// pass map to threads, let them do work, using Thread.currentThread() as the key

// Update all known thread's flags
for(AtomicBoolean b : map.values()) {
    b.set(true);
}

更清晰，更简洁，避免使用ThreadLocal在某种程度上它根本不是设计的目的。

通知线程其数据已过时

我只需要一种方法来通知所有这些线程它们的 ThreadLocal 变量已过时。

如果您的目标只是通知其他线程某些内容已更改，则不需要ThreadLocal根本不。只需使用一个AtomicBoolean并与您的所有任务共享它，就像您共享您的任务一样ThreadLocal<AtomicBoolean>。顾名思义，更新为AtomicBoolean是原子且可见的跨线程。更好的是使用真正的同步辅助工具，例如CyclicBarrier https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CyclicBarrier.html or Phaser https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Phaser.html，但对于简单的用例来说，仅使用AtomicBoolean.

创建一个可更新的“ThreadLocal"

综上所述，如果你really想要实现一个全局可更新的ThreadLocal你的实现被破坏了。事实上，您没有遇到问题只是巧合，未来的重构很可能会引入难以诊断的错误或崩溃。那个它“工作顺利“仅意味着您的测试不完整。

• 首先也是最重要的，一个ArrayList不是线程安全的。当多个线程可能与它交互时，您根本无法使用它（没有外部同步），即使它们会在不同的时间这样做。您现在没有看到任何问题只是巧合。
• 将对象存储为List阻止我们删除陈旧的值。如果你打电话ThreadLocal.set()它将追加到您的列表中，而不删除以前的值，如果您预计一旦线程终止这些对象将变得无法访问，这会导致内存泄漏和潜在的意外副作用，通常是这样的情况ThreadLocal实例。您的用例巧合地避免了这个问题，但仍然不需要使用List.

这是一个实现IterableThreadLocal它安全地存储和更新所有现有的实例ThreadLocal的值，适用于您选择使用的任何类型：

import java.util.Iterator;
import java.util.concurrent.ConcurrentMap;

import com.google.common.collect.MapMaker;

/**
 * Class extends ThreadLocal to enable user to iterate over all objects
 * held by the ThreadLocal instance.  Note that this is inherently not
 * thread-safe, and violates both the contract of ThreadLocal and much
 * of the benefit of using a ThreadLocal object.  This class incurs all
 * the overhead of a ConcurrentHashMap, perhaps you would prefer to
 * simply use a ConcurrentHashMap directly instead?
 * 
 * If you do really want to use this class, be wary of its iterator.
 * While it is as threadsafe as ConcurrentHashMap's iterator, it cannot
 * guarantee that all existing objects in the ThreadLocal are available
 * to the iterator, and it cannot prevent you from doing dangerous
 * things with the returned values.  If the returned values are not
 * properly thread-safe, you will introduce issues.
 */
public class IterableThreadLocal<T> extends ThreadLocal<T>
                                    implements Iterable<T> {
    private final ConcurrentMap<Thread,T> map;

    public IterableThreadLocal() {
        map = new MapMaker().weakKeys().makeMap();
    }

    @Override
    public T get() {
        T val = super.get();
        map.putIfAbsent(Thread.currentThread(), val);
        return val;
    }

    @Override
    public void set(T value) {
        map.put(Thread.currentThread(), value);
        super.set(value);
    }

    /**
     * Note that this method fundamentally violates the contract of
     * ThreadLocal, and exposes all objects to the calling thread.
     * Use with extreme caution, and preferably only when you know
     * no other threads will be modifying / using their ThreadLocal
     * references anymore.
     */
    @Override
    public Iterator<T> iterator() {
        return map.values().iterator();
    }
}

正如您希望看到的那样，这只不过是一个包装器ConcurrentHashMap，并产生与直接使用相同的开销，但隐藏在 a 的实现中ThreadLocal，用户通常期望它是快速且线程安全的。我出于演示目的实现了它，但我真的不建议在任何设置中使用它。