科技 · 實用指南
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 版本、系統、佇列類型、建立者、producer、consumer 與最後成功的 put、get、task_done；不要把 qsize 當可靠證據。
2. 畫出 writer–feeder–pipe–reader 等待圖
Queue.put 的物件稍後由背景 feeder 序列化並寫入管線。管線滿且 reader 不消費時，feeder 會阻塞，而 producer 結束時通常又等待排空。
列出所有讀寫端、關閉者、sentinel 發送者與必須繼續讀取的程序。管線容量有限，不能作為正確性假設。
3. 依所有權契約修正順序
結果佇列應在 worker 存活時持續消費，不要先 join 所有 producer 才讀取。停止新工作、傳送明確 sentinel、排空必要結果、關閉寫端，再依等待圖 join feeder 與程序。
JoinableQueue 每個成功 get 必須恰好對應一次 task_done，包括例外路徑；join 不能擋住應減少未完成計數的 consumer。
4. 把 cancel_join_thread 與 terminate 視為遺失決策
cancel_join_thread 可讓程序不等 feeder 排空就退出，因此可能遺失緩衝資料，只能在明確允許且已測試丟棄時使用。
terminate 或 kill 也可能中斷佇列內部狀態與傳輸中字節；採用前先定義哪些記錄可重播、去重或放棄。
5. 同時證明乾淨退出與完整交付
以足以超過一般管線容量的資料測試，逐筆核對 produced 與 consumed ID，並使用部署啟動方式。成功還要求記錄完整、feeder 消失、退出碼正確且沒有損壞警告。
暫停 reader 做負向測試：系統應呈現有界背壓或可控逾時，不能靜默遺失；若允許遺失，必須獨立斷言與報告。
