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

Нет. multiprocessing.Queue передаёт не сам объект, а его сериализованное представление: отправитель сериализует объект, а получатель создаёт отдельную копию. Поэтому изменения списка получателем не изменят исходный список у отправителя.

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

Процессы Python имеют независимые адресные пространства. Такой подход обеспечивает изоляцию и позволяет обходить ограничение GIL для CPU-bound вычислений, но не даёт процессам автоматически видеть изменения обычных объектов друг друга.

multiprocessing.Queue появился как безопасный IPC-механизм для обмена сообщениями между процессами. Он скрывает детали передачи данных через канал и использует сериализацию объектов Python.

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

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

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

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

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

Минимальный пример механизма:

from multiprocessing import Process, Queue

def worker(queue):
    received = queue.get()
    received.append("worker")

if __name__ == "__main__":
    queue = Queue()
    values = ["main"]
    process = Process(target=worker, args=(queue,))
    process.start()
    queue.put(values)
    process.join()
    print(values)  # ['main']

Изменение received происходит только в памяти дочернего процесса. Даже использование метода запуска fork не меняет этот вывод: после передачи через очередь объект всё равно проходит через сериализацию и создаётся заново у получателя.

Очередь хорошо подходит для обмена сообщениями, результатами и командами. Она не подходит для частых крупных передач без учёта стоимости сериализации и копирования. Для общего изменяемого состояния применяют multiprocessing.shared_memory, массивы из multiprocessing или прокси-объекты multiprocessing.Manager, но у каждого варианта есть цена: необходимость синхронизации, ограничения типов, накладные расходы или более сложное управление временем жизни.

Следует также учитывать, что сериализация может быть невозможна для некоторых объектов, например локальных функций, открытых файлов и многих объектов с нативными ресурсами. Кроме того, десериализация недоверенных данных через pickle небезопасна.

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

В CPU-bound-сервисе главный процесс отправляет задания с большими списками чисел через ProcessPoolExecutor. Рабочий процесс получает список и дописывает в него промежуточные результаты, после чего разработчик ожидает увидеть дополненный список в главном процессе.

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

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

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

Сохраняется ли объект общей ссылкой при использовании fork?

Нет. fork первоначально создаёт процесс с виртуальной копией адресного пространства родителя благодаря copy-on-write. После записи страницы памяти становятся независимыми, а передача объекта через Queue всё равно выполняется сериализацией и последующей десериализацией.

Можно ли использовать multiprocessing.Queue для передачи любого объекта Python?

Нет. Объект должен быть сериализуемым выбранным механизмом. Локальные функции, некоторые дескрипторы, открытые соединения и объекты с нативным состоянием часто нельзя корректно передать. Даже если объект сериализуется, восстановленный экземпляр может не сохранить внешние ресурсы или идентичность.

Что выбрать для частого обмена большими массивами между процессами?

Очередь удобна для небольших сообщений, но копирование и сериализация больших массивов могут доминировать по времени. Для крупных числовых данных обычно рассматривают shared memory или специализированные структуры общего доступа, а синхронизацию выполняют отдельными примитивами. Это уменьшает копирование, но усложняет контроль конкурентной записи, согласованность и освобождение памяти.