std::execution::par_unseq是大规模std::sort最有效的提速策略，但需满足数据量大、无副作用、编译器与标准库支持三重条件；盲目使用par或par_unseq反而更慢。
直接结论：别用 std::thread 手动分块，优先用 std::execution::par_unseq 或线程池封装的 parallel_for；手动分块时，必须对齐数据边界、避免跨块读写、显式控制线程数上限。
std::execution::par_unseq 能不能直接用于大数据分块？
能，但有前提：目标容器必须支持随机访问（std::vector、std::array、裸指针），且操作无副作用、无共享状态。它底层自动分块并调度到线程池，比手写 std::thread 更安全高效。
- 适用场景：纯计算型任务，比如对数组每个元素做
sqrt()、transform、reduce - 不适用场景：需要按逻辑语义分组（如按 key 分桶）、涉及文件 I/O、或需控制每块大小（比如固定 128MB）
- 常见错误：在 lambda 中捕获局部
std::ofstream或修改全局std::map，触发数据竞争 - 示例：
std::transform(std::execution::par_unseq, vec.begin(), vec.end(), vec.begin(), [](int x) { return x * x; });
手动分块时怎么算 chunk_size 和起止索引？
核心是避免整除误差导致最后一块越界或遗漏。不要用 n / num_threads 硬切，要用 (i * n + num_threads - 1) / num_threads 或更稳妥的迭代方式。
- 推荐写法：
size_t start = i * (n + num_threads - 1) / num_threads;，size_t end = std::min(n, (i + 1) * (n + num_threads - 1) / num_threads); - 更清晰的做法：预生成每个线程的
[begin, end)区间 vector，再用std::for_each并行处理每个区间 - 陷阱：用
int算大数组索引（>2GB 时溢出），必须用size_t或ptrdiff_t - 性能影响：chunk_size 太小 → 线程调度开销占比高；太大 → 负载不均（尤其数据分布不均时）
多线程读文件分块为什么容易卡死或丢数据？
因为 fseek/fsetpos 不是线程安全的，且文件指针是进程级共享资源。多个线程同时操作同一 FILE* 必崩。
立即学习“C++免费学习笔记（深入）”；
- 正确做法：每个线程单独
fopen，用fseek定位到对应 offset 后读取 —— 但要注意文件是否被其他进程截断 - 更优方案：先
mmap整个文件，再按偏移切分指针段，零拷贝访问（char* base + offset） - 关键细节：确保 offset 对齐到记录边界（比如 CSV 行首），否则解析错位；用
memchr扫描换行符比逐字节判断快 - 错误现象：
read() returns 0却没到 EOF、某几块数据重复出现、errno = ESPIPE
线程数设多少才不拖慢整体性能？
不是越多越好。超过物理核心数后，上下文切换开销会吃掉吞吐增益，尤其当任务含 I/O 或内存带宽瓶颈时。
- 纯 CPU 计算：设为
std::thread::hardware_concurrency()（通常等于逻辑核数） - 含磁盘读取：SSD 建议 ≤ 4 线程，HDD 建议 ≤ 2；再多线程只会加剧寻道延迟
- 含网络或锁竞争：观察
perf stat -e task-clock,context-switches,instructions，若 context-switches / second > 10k，大概率过载 - 容易被忽略的点：某些云环境（如 AWS t3 实例）会限制并发线程数，硬设 64 线程可能被 OS throttle
真正难的不是“怎么起线程”，而是确定哪一段内存/文件/记录该由哪个线程负责，且保证不重不漏、不跨边界、不争资源。分块逻辑写错，比线程本身更容易引发隐蔽 bug。
