sorted() 和 list.sort() 卡 CPU 是因 Timsort 默认单线程，16 核下仅用 1 核，百万数据时 CPU 占满而其余核空转；耗时呈 O(n log n) 非线性增长，cProfile 显示其占比常超 90%。
sorted() 和 list.sort() 为什么卡住 CPU？
因为它们默认单线程运行 Timsort，哪怕你有 16 核 CPU，sorted() 也只用 1 个核。数据量一过百万，CPU 占用率常飙到 100%，但其他核空转——这不是代码写错，是设计使然。
常见错误现象：
- 用
cProfile看到sorted或list.sort的tottime占总耗时 90% 以上 - 数据量从 10 万增到 100 万，耗时不是线性增长，而是接近 10 倍（Timsort 的 O(n log n) 在单核下暴露为实际瓶颈）
- 任务管理器里 Python 进程 CPU 使用率长期 100%，但系统整体负载低
多进程分块排序怎么写才不翻车？
核心思路是：切块 → 并行排序 → 归并。但直接用 multiprocessing.Pool.map 排每个子块，再用 heapq.merge 合并，容易踩三个坑：
- 块太小（如每块 1 万），进程启动/通信开销反超收益；建议块大小 ≥ 50 万，总块数控制在 CPU 核数的 1–2 倍
- 传入子块时用
copy.deepcopy或重复序列化，导致内存暴涨；应确保子块是浅拷贝或原生 list 切片 -
heapq.merge要求所有输入已排序且可迭代，但若某子块排序失败（比如 key 函数抛异常），整个归并会中断且错误定位难
健壮写法示例：
立即学习“Python免费学习笔记（深入）”；
from multiprocessing import Pool
import heapq
<p>def sort_chunk(chunk):
try:
return sorted(chunk, key=lambda x: x['score']) # 显式指定 key，避免隐式 <strong>lt</strong>
except Exception as e:
raise RuntimeError(f"sort_chunk failed on {len(chunk)} items: {e}")</p><p>def parallel_sort(data, chunk_size=500000, processes=None):
chunks = [data[i:i + chunk_size] for i in range(0, len(data), chunk_size)]
with Pool(processes=processes) as pool:
sorted_chunks = pool.map(sort_chunk, chunks)
return list(heapq.merge(*sorted_chunks, key=lambda x: x['score']))</p>key 函数慢，比排序本身还拖后腿
很多“排序慢”问题其实出在 key 上：sorted(data, key=os.path.getmtime) 每次比较都触发一次系统调用，key=lambda x: x.compute_heavy() 每次调用都重算——这会让 O(n log n) 实际变成 O(n² log n)。
- 预计算 key：用
[(key_func(x), x) for x in data]提前算好，再按元组首项排序 - 缓存纯函数：对确定性计算加
@lru_cache，但注意 key 参数必须可哈希（不能是 dict/list） - 避免正则和字符串切片嵌套在 key 里：正则对象提至外层复用，
str.startswith()比str[0:3] == 'abc'更快且安全
什么时候不该用并行排序？
并行不是银弹。以下情况反而更慢或不可行：
- 数据无法全量载入内存（比如 20GB 文件）——此时该用外部排序或数据库，而非 Python 多进程
- 元素是不可序列化的对象（如含文件句柄、lambda、模块引用），
multiprocessing会 pickle 失败 - 排序后只取 top-K（如前 100 名），用
heapq.nlargest(100, data, key=...)比全量排序快一个数量级 - 原始列表很小（ 排序收益，老老实实
list.sort()
真正关键的判断点是：你手上的数据能不能一次性进内存，以及你是否真的需要全局有序——很多时候，分块有序 + 按需归并，比强求一个完整 sorted 列表更务实。
