Краткий ответ

При повторном выполнении задачи тем же рабочим потоком новое задание может увидеть значение, оставшееся от предыдущего. Кроме того, значение может удерживаться пулом потоков значительно дольше ожидаемого срока жизни задачи, поэтому для временных данных ThreadLocal необходимо очищать через remove() в блоке finally.

Исторический контекст

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

Предположение о завершении потока безопасно для обычных одноразовых потоков: после завершения исчезает и связанное с ним состояние. Однако ExecutorService переиспользует рабочие потоки, поэтому граница задачи не совпадает с границей жизни потока.

Постановка проблемы

Если задача записала в ThreadLocal идентификатор пользователя, настройки запроса или диагностический контекст и не вызвала remove(), следующая задача на том же потоке может получить чужие данные. Это приводит к утечке контекста между запросами, ошибкам авторизации, некорректному логированию и трудно воспроизводимому поведению.

Есть и ресурсная проблема: рабочий поток пула может жить долго, а объект, записанный в ThreadLocal, будет удерживаться вместе с этим потоком. При большом числе или размере таких объектов это увеличивает потребление памяти.

Подробное решение

У каждого потока есть внутренняя таблица ThreadLocalMap, где хранятся значения ThreadLocal. Ключи в ней устроены как слабые ссылки, но сами значения не являются слабыми: пока запись не очищена, значение может оставаться достижимым через рабочий поток.

При повторном вызове get() на том же экземпляре ThreadLocal поток получает свое ранее сохранённое значение. Поэтому очистку следует выполнять безусловно после обработки задачи:

static final ThreadLocal<String> USER = new ThreadLocal<>();

void execute(String user) {
    USER.set(user);
    try {
        processRequest();
    } finally {
        USER.remove();
    }
}

Вызов remove() удаляет значение именно для текущего потока и предотвращает его передачу следующей задаче. Размещать очистку нужно в finally, чтобы она выполнялась также при исключении или досрочном выходе.

Слабая ссылка ключа не является заменой remove(). Если объект ThreadLocal станет недостижимым, ключ может быть удалён сборщиком мусора, но значение способно временно остаться в таблице до очистки устаревших записей. Кроме того, пока сам ThreadLocal используется повторно, слабая ссылка не исчезает.

ThreadLocal не следует применять как средство передачи данных между потоками: значение доступно только текущему потоку. Для явного контекста лучше использовать параметры методов, а для асинхронных цепочек — механизм, который явно поддерживает распространение контекста.

Ситуация из практики

В HTTP-сервисе фильтр записывал идентификатор пользователя в ThreadLocal, чтобы логгер автоматически добавлял его в сообщения. На сервере без пула ошибок не было заметно, но после перехода на ExecutorService один запрос иногда логировался с идентификатором предыдущего пользователя.

Вариант с созданием нового ThreadLocal для каждого запроса плох: он не устраняет удержание значений и усложняет контроль жизненного цикла. Вариант с очисткой только при успешном завершении также ненадёжен, потому что исключение оставляет контекст в потоке.

Выбранное решение — один управляемый ThreadLocal и вызов remove() в finally вокруг всей обработки запроса. Это отделило жизненный цикл контекста от жизненного цикла рабочего потока; после исправления данные между запросами не смешивались, а долгоживущие значения перестали удерживаться пулом.

Что кандидаты часто упускают

Почему повторное использование потока принципиально меняет поведение ThreadLocal?

ThreadLocal привязывает значение к потоку, а не к задаче и не к запросу. В пуле один поток последовательно исполняет множество задач, поэтому его локальное состояние автоматически переходит между ними, если приложение явно его не удаляет.
Достаточно ли того, что ключ ThreadLocal хранится как слабая ссылка?

Нет. Слабая ссылка помогает удалить ключ после потери внешних ссылок, но значение в записи таблицы хранится обычной сильной ссылкой. Такая запись может сохраняться до последующей внутренней очистки, а при долгоживущем потоке это создаёт риск удержания объектов.
Можно ли безопасно использовать ThreadLocal для неизменяемого контекста запроса в пуле?

Только если контекст устанавливается перед каждой задачей и гарантированно удаляется после неё. Неизменяемость снижает риск повреждения самого объекта, но не предотвращает утечку старого контекста в следующую задачу и не решает проблему удержания памяти.