使用 multiprocessing.Pool.starmap() 直接返回有序结果，避免手动管理队列导致的乱序问题；starmap 保证输出列表索引与输入参数顺序严格一致，是解决多进程下结果保序最简洁、可靠的方法。
使用 `multiprocessing.pool.starmap()` 直接返回有序结果，避免手动管理队列导致的乱序问题；`starmap` 保证输出列表索引与输入参数顺序严格一致，是解决多进程下结果保序最简洁、可靠的方法。
在 Python 多进程（multiprocessing）场景中，尤其是对大规模时间序列或空间有序数据（如用于 LOESS 平滑的 DataFrame）进行并行分块处理时，结果的物理顺序至关重要——一旦各子任务完成时间不一致，而你又依赖 Queue.get() 无序消费，最终拼接出的 DataFrame 就会严重错位，导致可视化失真或统计错误。
你当前代码的核心问题在于：
✅ 使用 Manager().Queue() 实现了跨进程通信，但 ❌ 未对入队/出队施加顺序约束；
✅ starmap 已按 i 递增顺序分发任务，但 ❌ result_queue.put() 在子进程中异步执行，完成快的先入队，导致出队顺序完全不可控；
✅ 手动 while not result_queue.empty(): ... 循环还存在竞态风险（empty() 不是原子操作，可能漏读）。
✅ 正确解法：放弃队列，信任 starmap 的天然保序性
pool.starmap(func, iterable) 的设计契约明确指出：返回值列表 results 中第 k 个元素，严格对应 iterable[k] 输入所触发的 func 调用结果。这意味着只要你的输入 [(..., i, ...) for i in range(N)] 按 i=0,1,2,... 排序，结果就天然有序。
因此，只需两处重构：
- 移除 Manager().Queue() 及所有队列操作；
- 让 process_data 直接 return 结果 DataFrame；
- 用 pd.concat() 按序合并 starmap 返回的列表。
from multiprocessing import Pool
import pandas as pd
def smooth_data_mp(data_frame):
num_processes = 8
chunk_size = 125000
fraction = 125 / chunk_size
n_chunks = len(data_frame) // chunk_size
if n_chunks == 0:
return data_frame.copy() # 防止空切片
with Pool(processes=num_processes) as pool:
# 输入按 i 升序排列 → 输出 results[0], results[1], ... 严格对应 chunk 0, 1, ...
results = pool.starmap(
process_data,
[(data_frame, i, chunk_size, fraction) for i in range(n_chunks)]
)
# 按索引顺序拼接（无需排序！）
return pd.concat(results, ignore_index=True)
def process_data(dataframe, i, chunk_size, fraction):
start_frame = chunk_size * i
end_frame = min(chunk_size * (i + 1), len(dataframe))
# 注意：此处应确保子集保留原始索引语义（如需后续对齐，可重置索引）
subset = dataframe.iloc[start_frame:end_frame].copy()
new_data_frame = calculate_loess_on_subset(subset, chunk_size, fraction, i)
return new_data_frame # 直接返回，不再入队⚠️ 关键注意事项
- ignore_index=True：pd.concat(..., ignore_index=True) 重置全局索引，避免因各 chunk 内部索引重复（如全为 0,1,2...）导致混淆；若需保留原始位置信息，可在 process_data 中为每块添加 chunk_id=i 列，后续按该列排序。
- 边界安全：原代码未处理 len(data_frame) % chunk_size != 0 的余数部分，建议补充最后一块处理逻辑（例如 range((len(data_frame) + chunk_size - 1) // chunk_size)）。
- 内存效率：starmap 会等待全部进程结束才返回结果列表，适合中等规模数据；若数据极大且需流式处理，才需考虑带序号的 Queue + 归并排序（但本例显然不需要）。
- 不要混用 Manager().Queue 和 starmap：二者设计目标冲突——starmap 是函数式同步抽象，Queue 是异步消息通道，强行共存只会增加复杂度和 bug 风险。
✅ 总结
多进程保序的黄金法则：优先使用 map/starmap 的返回值顺序，而非自行管理共享队列。
当输入参数本身携带顺序标识（如分块索引 i），starmap 就是最轻量、最可靠、最符合直觉的保序方案。删掉 Manager().Queue()，修改函数为 return，一行 pd.concat() 收尾——你的 LOESS 曲线将立刻恢复平滑与准确。
