科技 · 实用指南
Python multiprocessing.Queue 在 join 时卡住？先画出 feeder 与排空顺序
先区分进程、feeder 线程和未完成任务三种等待，再调整关停顺序，避免把卡死变成静默丢数据。
子进程即使已执行完目标函数，也可能因 Queue feeder 正在把缓冲数据写入无人读取的管道而无法退出。可见的 join 只是等待链末端。
先确认具体是哪一种 join，画清 writer、feeder、pipe 与 reader 的所有权，再按证据调整排空和关闭顺序。
1. 先确认究竟是哪一种 join 卡住
先抓取线程或进程栈，再终止任何东西。Process.join 等子进程退出，Queue.join_thread 等 close 后 feeder 退出，JoinableQueue.join 等每个任务的 task_done。它们名字相似，但等待条件完全不同。
记录启动方式、Python 版本、系统、队列类型、创建者、生产者、消费者，以及最后成功的 put、get 和 task_done；不要把 qsize 当作可靠证据。
2. 画出 writer–feeder–pipe–reader 等待图
Queue.put 的对象随后由后台 feeder 序列化并写进管道。管道满且 reader 不消费时，feeder 会阻塞，生产进程在退出时又通常要等它排空。
列出所有读写端、关闭者、哨兵发送者与必须继续读取的进程。管道容量有限，不能成为正确性假设。
3. 按所有权契约修正顺序
结果队列应在 worker 存活时持续消费，不要先 join 全部生产者再开始读取。停止新工作、发送有明确定义的哨兵、排空必需结果、关闭写端，再按等待图 join feeder 与进程。
JoinableQueue 的每个成功 get 必须恰好对应一次 task_done，包括异常路径；join 不能挡住本应减少未完成计数的消费者。
4. 把 cancel_join_thread 与 terminate 视为丢失决策
cancel_join_thread 会允许进程不等 feeder 排空就退出，可能丢失缓冲数据，只能在明确允许丢弃并有测试时使用。
terminate 或 kill 也可能打断队列内部状态和飞行中字节；采用前先定义可重放、去重或放弃哪些记录。
5. 同时证明干净退出与完整交付
用足以超过常见管道容量的数据测试，逐个核对 produced 与 consumed ID，并使用部署环境的启动方式。成功不仅是“程序退出”，还要记录完整、feeder 消失、退出码正确且无损坏警告。
再暂停 reader 做负向测试：系统应暴露有界背压或可控超时，不能静默丢记录；若允许丢失，应单独断言并报告。
