std::execution::par 不适用于空间查询，因其无法剪枝、引发写竞争且破坏缓存局部性；高效方案是 r-tree 预剪枝 + 分块任务调度 + 线程池，需规避锁、内存分配和 numa 迁移问题。
直接结论：用 std::execution::par 调用 STL 算法做空间查询过滤，通常不如手写分块 + 线程池 + 空间索引（如 R-tree）的组合快，甚至可能更慢——尤其当查询涉及几何计算、IO 或共享锁时。
为什么 std::sort 或 std::find_if 的并行策略不适用于空间查询
空间查询（比如“找出所有与给定矩形相交的点”）本质不是纯内存遍历，它往往包含：
- 每次迭代需调用几何函数（如
intersects()、distance_sq()），而这些函数无法被编译器自动向量化 - 结果集需要动态增长（如
std::vector::push_back()），多个线程同时写入会触发内部锁或 reallocation 竞争 - 原始数据若未按空间局部性排列（如非 Morton order、非 R-tree 叶节点顺序），并行遍历会严重破坏缓存行利用率
-
std::execution::par对容器无感知——它不会帮你跳过明显不相关的区域（例如用包围盒快速裁剪），只是暴力分段扫描
真正有效的并行空间查询结构：R-tree + 分块任务调度
你得把“空间划分”和“线程划分”对齐。典型做法是：
- 预构建内存内 R-tree（用
boost::geometry::index::rtree或libspatialindex），叶子节点对应小批量空间对象 - 查询时先走树遍历得到候选叶子节点列表（单线程、轻量、有剪枝）
- 再将这些叶子节点分发给线程池，每个线程独立处理一批叶子内的精确几何判断
- 用
std::vector<:shared_ptr>>></:shared_ptr>或无锁队列收集结果，避免写竞争
示例关键片段：
// 假设 rtree 已建好，query_box 是查询范围
std::vector<size_t> candidate_leaf_ids;
rtree.query(bgi::satisfies([&](const auto& item) {
return bgi::intersects(item.bounds(), query_box);
}), std::back_inserter(candidate_leaf_ids));
// 分发到线程池（非 std::thread 直接创建，避免开销）
for (size_t i = 0; i
<h3>容易踩的坑：锁、内存、亲和性</h3>
<p>即使结构正确，以下三点仍会让并行查询退化成串行：</p>
<ul>
<li>在几何判断中用了全局 <code>std::mutex</code>（比如日志、统计计数器），所有线程排队等锁——改用 <code>thread_local</code> 计数器 + 最终归并</li>
<li>每个线程都 new 临时缓冲区（如用于三角剖分的中间数组），触发频繁 malloc 竞争——改用预分配的 arena 或 <code>thread_local static std::vector<t></t></code>
</li>
<li>线程在 NUMA 节点间随机迁移，导致访问远端内存（尤其是大 R-tree 数据页）——用 <code>pthread_setaffinity_np()</code> 绑定线程到靠近内存的 CPU 核心</li>
</ul>
<p>最常被忽略的一点：空间查询的加速比不取决于核心数，而取决于「可并行裁剪的叶子节点数量」。如果一次查询只命中 1–2 个叶子，加再多线程也白搭——这时候该优化的是索引结构或查询粒度，而不是并发模型。</p></size_t>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
