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

Для этого используют threading.local. Объект один, но его атрибуты хранятся раздельно для каждого потока: запись, выполненная одним потоком, не видна другому.

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

Потокам часто требовалось хранить служебное состояние запроса, соединения или логирования без добавления специального параметра во множество вызовов. Thread-local storage решает эту задачу, предоставляя каждому потоку собственное пространство атрибутов.

В Python такой механизм представлен классом threading.local. Он особенно полезен в синхронных приложениях, где параллельная работа организована через пул потоков.

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

Обычная глобальная переменная доступна всем потокам. Если каждый поток записывает в неё идентификатор своего запроса, значения будут перезаписывать друг друга, что приведёт к ошибкам авторизации, неправильным логам или смешиванию данных разных запросов.

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

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

При обращении к атрибуту объекта threading.local Python учитывает текущий поток. Поэтому два потока могут записать атрибут с одинаковым именем, но получат разные значения.

import threading

state = threading.local()

def worker(name):
    state.request_id = name
    print(threading.current_thread().name, state.request_id)

threads = [threading.Thread(target=worker, args=(name,))
           for name in ('A', 'B')]
for thread in threads:
    thread.start()
for thread in threads:
    thread.join()

Каждый поток видит собственный state.request_id. Сам объект state может быть общим, но его атрибуты логически разделены по потокам.

Это не механизм синхронизации. threading.local не защищает общие объекты, не предотвращает гонки и не делает операции атомарными. Если значение должно быть общим для потоков, нужны подходящие средства синхронизации, например Lock, очередь или безопасная архитектура обмена сообщениями.

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

Для asyncio threading.local обычно недостаточен: множество корутин часто выполняется в одном потоке и увидит одно и то же состояние. Для изоляции контекста между корутинами применяют contextvars.ContextVar, а threading.local оставляют для изоляции именно между потоками.

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

Синхронный веб-сервис обрабатывает запросы пулом потоков и хранит в локальном состоянии идентификатор текущего запроса для логгера. Вариант с глобальной переменной прост, но небезопасен: параллельные запросы перезаписывают идентификатор. Вариант с передачей идентификатора через все функции надёжен, но увеличивает связанность и количество параметров.

Выбран threading.local, поскольку граница изоляции совпадает с моделью выполнения сервиса: один запрос обрабатывается одним потоком. После завершения обработки идентификатор очищается, чтобы повторное использование потока в пуле не привело к утечке контекста в следующий запрос.

Если сервис позднее перейдёт на asyncio, решение нужно пересмотреть и заменить локальное состояние потока на ContextVar. Иначе разные корутины одного потока могут получить чужой контекст.

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

Можно ли считать threading.local глобальной переменной?

Ссылка на объект действительно может быть глобальной, но пространство его атрибутов не является общим: оно выбирается по текущему потоку. Поэтому корректнее считать threading.local глобальным дескриптором доступа к раздельному состоянию, а не обычным общим хранилищем.

Что произойдёт при использовании threading.local в пуле потоков?

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

Чем threading.local отличается от ContextVar в асинхронной программе?

threading.local разделяет состояние по потокам, а ContextVar — по контекстам выполнения, которые переключаются вместе с корутинами. Если несколько корутин работают в одном потоке, threading.local не изолирует их друг от друга, тогда как ContextVar предназначен именно для такого контекстно-локального состояния.