不能直接用 sort.Sort 处理大数组并发排序，因其单 goroutine 原地排序、阻塞主线程、不并发安全；正确做法是分块→并发排序→heap 归并，注意预分配、避免逃逸与 GC 压力。
为什么不能直接用 sort.Sort 处理大数组并发排序？
因为 sort.Sort 是单 goroutine、原地排序，对百万级以上切片会阻塞主线程，且无法利用多核。更关键的是：它不保证并发安全——多个 goroutine 同时调用同一个 sort.Sort 实例（比如共享的 sort.Interface 实现）可能因内部状态冲突导致 panic 或结果错乱。真实场景中，你往往需要「把一个超大 []int 拆成 N 块，并发排好，再归并」，而不是让多个 goroutine 去争抢同一块内存。
如何分块 + 并发排序 + 安全归并？
核心是三步解耦：分块无共享、排序各自独立、归并用 heap 驱动。重点不是“写个并发函数”，而是避免隐式共享和边界越界。
- 分块时用
make([]int, 0, chunkSize)显式控制容量，避免底层数组意外复用 - 每个 goroutine 接收独立切片副本（非指针），排序过程完全隔离
- 归并阶段用
heap.Init构建最小堆，每个元素包装为{value int, srcIndex int}，其中srcIndex标识来自第几个已排序子块，避免反复切片拷贝 - 注意归并循环中每次从某子块取一个元素后，要检查该子块是否已空，否则
index out of range
示例关键片段：
// 假设 sortedChunks = [][]int{...}，每个子块已升序
h := &minHeap{}
heap.Init(h)
for i, chunk := range sortedChunks {
if len(chunk) > 0 {
heap.Push(h, &item{value: chunk[0], chunkIdx: i, elemIdx: 0})
}
}
// 归并主循环中：
for h.Len() > 0 {
it := heap.Pop(h).(*item)
result = append(result, it.value)
if it.elemIdx+1 < len(sortedChunks[it.chunkIdx]) {
heap.Push(h, &item{
value: sortedChunks[it.chunkIdx][it.elemIdx+1],
chunkIdx: it.chunkIdx,
elemIdx: it.elemIdx + 1,
})
}
}
sync.Pool 要不要用在归并中间对象上？
要看吞吐量级和对象生命周期。如果单次排序平均产生 >10k 个 *item，且 GC 压力明显（pprof 显示 runtime.mallocgc 占比高），才值得引入 sync.Pool。否则池化反而增加锁开销和内存驻留——因为 *item 很小（3 个 int 字段），Go 的小对象分配器本身就很高效。
立即学习“go语言免费学习笔记（深入）”；
- 若启用，
sync.Pool的New函数必须返回零值对象，不能带缓存字段 - 每次
Get后必须显式重置字段（如it.value = 0; it.chunkIdx = -1），否则残留值会导致归并错误 - 归并完成后立即
Put，不要跨 goroutine 生命周期持有
实测吞吐瓶颈通常卡在哪？
不是 CPU，也不是排序算法本身，而是内存带宽和 GC 触发频率。尤其当输入是千万级 []*MyStruct 且结构体较大时，分块复制、归并时频繁 append 扩容、heap.Push 的指针存储都会放大内存压力。
- 优先用
[]int或[]uint64测试基线，确认 pipeline 无误后再换复杂类型 - 归并结果切片提前
make([]int, 0, totalLen)预分配，避免多次扩容 - 禁用 GC（
debug.SetGCPercent(-1)）做压测对比，若吞吐翻倍，说明当前瓶颈就是 GC，需优化对象逃逸或复用
真正难调的从来不是“怎么并发”，而是“哪一行悄悄让变量逃逸到堆上”或者“哪个 append 在后台偷偷 copy 了 2MB 内存”。
