应优先用 atomic 或 reduction 替代 critical：atomic 适用于标量简单操作，reduction 适用于满足结合律/交换律的归约；critical 仅用于必须顺序访问共享资源且无法轻量替代的场景，使用时需命名避免锁竞争，并严禁嵌套。
用 critical 之前先确认真需要它
critical 是最“重”的同步手段之一，每次进入都要争抢全局锁，线程可能阻塞、上下文切换、缓存失效。很多场景其实根本不需要——比如只读共享变量、或变量本身是线程局部的。常见误用是把整个循环体包进 #pragma omp critical，结果并行变串行，性能反降。真正该用 critical 的典型场景只有：多个线程必须顺序访问同一共享资源（如写日志、更新全局计数器、修改链表头指针），且无法用更轻量方式替代。
critical 和 atomic 怎么选
如果只是对一个标量做简单操作（++、+=、=），优先用 atomic。它底层常映射为 CPU 原子指令（如 xadd），无锁、无调度开销、不阻塞其他线程。而 critical 适合任意复杂语句块，比如调用函数、多步逻辑、涉及多个变量的更新。
-
atomic只支持基本类型和有限运算（int,long, 指针等；不支持float的+=在旧编译器上可能报错） -
critical不限制语句内容，但必须确保块内不调用可能再次进入critical的函数（否则死锁） - 若需保护的是一组相关变量（如
sum和count同时更新），atomic无法覆盖，只能用critical或reduction
别忘了 reduction 这个更优解
对累加、求最大值、逻辑与等归约操作，reduction 是首选。它自动为每个线程分配私有副本，最后在合并阶段无竞争地汇总，性能远高于 critical 或 atomic。它不适用于任意逻辑，但覆盖了绝大多数并行循环中的共享写需求。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 写法是
#pragma omp parallel for reduction(+:sum)，其中+可换成max、min、&&等 -
reduction要求操作满足结合律和交换律，sum += a[i]符合，但sum = sum * a[i] + b[i]这类复合表达式不行 - 变量
sum必须在并行区域外声明，且不能在循环体内被其他非reduction方式写入
critical 的命名与嵌套风险
默认 critical 使用隐式全局锁，所有未命名的 critical 区域共用一把锁。这意味着两个看似无关的临界区（比如分别更新 log_file 和 error_count）会互相阻塞。解决办法是显式命名：#pragma omp critical(write_log) 和 #pragma omp critical(update_counter)，它们使用独立锁，互不干扰。
立即学习“C++免费学习笔记（深入）”；
- 命名后，不同名字的
critical可以并发执行 - 同一个名字的
critical块之间仍互斥，哪怕跨不同并行区域 - 绝对不要在
critical块里再调用另一个同名或无名的critical，极易死锁
实际写代码时，最容易被忽略的是：critical 解决的是“顺序”，不是“可见性”。它保证只有一个线程执行，但不保证其他线程能立即看到你刚写入的值——除非变量本身是 volatile 或配合内存栅栏（不过 OpenMP 2.0+ 的 critical 已隐含 acquire/release 语义，一般够用）。
