Код, который вы привели:
import threading
data = []
def worker():
for i in range(1000):
data.append(i)
threads = [threading.Thread(target=worker) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()

— простая многопоточная программа, но при её анализе надо учитывать несколько важных моментов.

1) Согласованность данных и гонки (data races)

В CPython отдельная операция list.append() фактически выполняется атомарно из‑за GIL (Global Interpreter Lock). Это значит, что отдельные append'ы не «порубятся» на мелкие шаги и не приведут к повреждению структуры list (в большинстве реализаций append не приведёт к краху интерпретатора).Тем не менее это не даёт гарантий на более сложные композиции операций. Если вы делаете несколько операций, которые вместе создают инвариант (например, проверить длину и затем использовать индекс), то между этими операциями может вмешаться другой поток и нарушить инвариант — поэтому нужен явный механизм синхронизации.В вашем примере в результате вы, скорее всего, получите список длины 4000 (4 × 1000) с нефиксированным порядком элементов (интерливинг). Это нормально, но порядок — недетерминирован.Не стоит полагаться на поведение конкретной реализации CPython: другие реализации (PyPy, Jython, IronPython) могут иметь другие семантики и/или отсутствие GIL, и в общем случае правильнее защищать совместный доступ явно.

2) Влияние GIL

GIL сериализует выполнение байткода Python: в CPython в любой момент выполняется байткод только одного потока. Для барьера это значит:
Потоку, выполняющему CPU‑интенсивный Python‑код, сложно получить линейный выигрыш от нескольких потоков — они будут «переключаться», а не исполняться параллельно на разных ядрах.Для I/O‑операций (ввод/вывод), где операции блочат и часто освобождают GIL (системные вызовы, чтение/запись сокетов, файлов, ожидание), многопоточность в Python даёт ощутимый выигрыш.Некоторые C‑расширения (NumPy, библиотечные вызовы) освобождают GIL при тяжёлых вычислениях, так что параллелизм возможен и там.

3) Как безопасно синхронизировать

threading.Lock (или RLock) — самый простой способ защищать критические секции:
lock = threading.Lock()
def worker():
for i in range(1000):
with lock:
data.append(i)
Это делает append последовательным, но снижает параллелизм и производительность.queue.Queue — потокобезопасная очередь для передачи данных между потоками. Часто предпочтительнее, чем общий список + Lock:
import queue
q = queue.Queue()
def worker():
for i in range(1000):
q.put(i)concurrent.futures.ThreadPoolExecutor — удобный API для работы со пулами потоков и возврата результатов (синхронизацию выполняет библиотека).Более продвинутые примитивы: Condition, Semaphore, Event — для координации потоков, ожидания условий и т. п.Для счётчиков используйте synchronized структуры или lock; в стандартной библиотеке нет «атомного инкремента» для Python‑переменных.Если хотите агрегировать результаты без блокировок — пусть каждый поток пишет в свой локальный буфер (список), а в конце один поток объединит их (merge). Это часто гораздо быстрее.

4) Проблемы при неправильной синхронизации

Гонки, потеря инвариантов (несогласованность), непредсказуемый порядок.Возможность дедлока при неправильном использовании нескольких замков.Снижение производительности при чрезмерном использовании глобальных замков (контенция).В CPython возможна ложная уверенность в безопасности из‑за GIL — это опасно при переносимости кода или при использовании C‑расширений.

5) Альтернативные модели параллелизма

Для I/O‑bound задач:
Многопоточность (threading, ThreadPoolExecutor) — хороша и проста.Асинхронность (asyncio, trio, curio) — эффективна по памяти и без GIL‑проблем (всегда один поток, но много корутин); особенно хорошо при больших количеств соединений/событий.Комбинации: несколько потоков каждый запускает цикл asyncio (редко нужно).Для CPU‑bound задач:
multiprocessing / concurrent.futures.ProcessPoolExecutor — каждый процесс имеет свой интерпретатор и память, обходит GIL; межпроцессное взаимодействие дороже (сериализация/IPC), но даёт настоящий параллелизм на ядрах.Параллелизм на уровне C/Си‑расширений: если использовать библиотеки, которые освобождают GIL (NumPy, SciPy, Cython с nogil, чистые C), можно получить многопоточную скорость.Векторизация и алгоритмическая оптимизация часто эффективнее «простого» распараллеливания в Python.Для данных с большим объёмом: распределённые системы (Dask, Ray, Spark) — масштабирование за пределы одного хоста.

6) Практические рекомендации применительно к вашему примеру

Если вам важно просто собрать элементы из нескольких рабочих потоков:
Лучше использовать queue.Queue() или ThreadPoolExecutor с возвращаемыми результатами.Или пусть каждый поток пишет в свой список, затем объедините списки в конце (без блокировок).Если задача CPU‑интенсивна (внутри worker много вычислений на Python), используйте multiprocessing/ProcessPoolExecutor или перенос тяжёлой работы в C‑расширение/NumPy.Избегайте ненужных глобальных замков и старайтесь уменьшать область критической секции.Не полагайтесь на «атомарность append» как на общий способ обеспечения безопасности — это имплементационная деталь CPython.

Короткие примеры

Lock:
lock = threading.Lock()
def worker():
for i in range(1000):
with lock:
data.append(i)

Queue:
import queue
q = queue.Queue()
def worker():
for i in range(1000):
q.put(i)

главный поток: собрать все элементы

while not q.empty(): item = q.get()

Каждый поток свой буфер + merge:
results = [[] for _ in range(4)]
def worker(idx):
local = results[idx]
for i in range(1000):
local.append(i)

потом: data = sum(results, []) или itertools.chain.from_iterable

CPU: ProcessPoolExecutor
from concurrent.futures import ProcessPoolExecutor
with ProcessPoolExecutor() as ex:
res = list(ex.map(heavy_cpu_task, inputs))

Если нужно — могу показать конкретные примеры кода для вашего случая (с Lock / Queue / multiprocessing) и сравнить по производительности.