Расширение java ThreadLocal для сброса значений во всех потоках

Взаимодействие с объектами в потоке ThreadLocal через потоки

Я скажу, что это плохая идея. ThreadLocal является специальным классом, который предлагает преимущества скорости и эффективности потоков при правильном использовании. Попытка общаться по потокам с помощью ThreadLocal ставит перед собой цель использовать класс в первую очередь.

Если вам нужен доступ к объекту по нескольким потокам, для этого используются инструменты, в частности потокобезопасные коллекции в java.util.collect.concurrent ConcurrentHashMap, который можно использовать для репликации 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 flags
for(AtomicBoolean b : map.values()) {
    b.set(true);
}

Более четкий, более сжатый и избегает разведения ThreadLocal в какой-то ужасный монстр Франкенштейна того, кем он когда-то был.

Уведомление потоков о том, что их данные устарели

Мне просто нужен способ оповестить все эти потоки о том, что их переменная ThreadLocal устарела.

Если ваша цель - просто уведомить другие потоки, что что-то изменилось, вам вообще не нужен ThreadLocal. Просто используйте одиночный AtomicBoolean и поделитесь им со всеми вашими задачами, как и ваш ThreadLocal<AtomicBoolean>. Поскольку имя подразумевает обновления для AtomicBoolean, это атомарные и видимые поперечные потоки. Еще лучше было бы использовать реальную помощь синхронизации, например CyclicBarrier или Phaser, но для простых случаев использования нет вреда при использовании AtomicBoolean.

Создание обновляемого "ThreadLocal"

Все сказанное, если вы действительно хотите реализовать глобально обновляемый 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 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 и несет все те же накладные расходы, что и использование одного напрямую, но скрытое в реализации ThreadLocal, которое пользователи обычно ожидают быстрого и поточно-безопасный. Я реализовал его для демонстрационных целей, но я действительно не могу рекомендовать его использовать в любых настройках.

Это не будет хорошей идеей делать это, поскольку вся точка локального хранилища потоков - это нулевая локальность значения, которое она содержит, то есть вы можете быть уверены, что ни одна другая нить, кроме вашего собственного потока, не сможет коснуться Значение. Если другие потоки могут касаться локального значения вашего потока, это больше не будет "потоковым локальным", и это нарушит контракт модели памяти локального хранилища потоков.

Либо вы должны использовать что-то другое, чем ThreadLocal (например, a ConcurrentHashMap), чтобы сохранить это значение, или вам нужно найти способ запланировать обновление соответствующих потоков.

Вы можете использовать google guava map maker для создания статического окончательного ConcurrentWeakReferenceIdentityHashmap со следующим типом: Map<Thread, Map<String, Object>>, где вторая карта - это ConcurrentHashMap. Таким образом, вы бы приблизились к ThreadLocal, за исключением того, что вы можете выполнять итерацию по карте.