最直接的方式是用C++20的std::semaphore进行资源计数控制：初始化为最大并发数，线程前acquire()、退出前release()；需C++20标准及对应编译器支持（GCC 11+/Clang 13+/MSVC 16.11+）。
用 std::semaphore 控制并发线程数（C++20）
最直接的方式是用 C++20 引入的 std::semaphore，它天然适合做「资源计数型」并发控制。初始化时设为最大允许并发数，每个线程启动前 acquire()，退出前 release()，就能硬性卡住同时运行的线程数。
注意：GCC 11+ 和 Clang 13+ 默认支持，但需编译时加 -std=c++20；MSVC 2019 16.11+ 支持，但早期版本可能需启用实验性并发库（/std:c++20 /experimental:module）。
示例：
std::semaphore sem{3}; // 最多 3 个线程并发
void worker(int id) {
sem.acquire(); // 阻塞直到有许可
std::cout << "Thread " << id << " running\n";
std::this_thread::sleep_for(1s);
std::cout << "Thread " << id << " done\n";
sem.release();
}
// 启动 10 个任务，但最多 3 个同时执行
for (int i = 0; i < 10; ++i) {
std::jthread(worker, i);
}
没有 C++20 怎么办？用 std::mutex + 计数器模拟
在 C++11/14/17 环境中，std::semaphore 不可用，得手动维护一个带锁的计数器。这不是“假并发控制”，只要逻辑正确，效果和信号量一致——关键在于 acquire/release 必须成对、无遗漏，且 release 必须在异常路径下也能执行。
立即学习“C++免费学习笔记（深入）”；
常见错误：忘记在 catch 块里 release，或把 release 放在函数末尾却没用 std::lock_guard 的 RAII 保证。
安全写法要点：
- 用
std::mutex保护共享计数器current_count和上限max_concurrent - acquire 逻辑必须循环等待（避免虚假唤醒），不能只
if (count - release 必须放在
finally类语义位置——推荐用 lambda +std::unique_lock的作用域自动析构
简化示例（省略异常处理细节）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::mutex mtx;
int current_count = 0;
const int max_concurrent = 3;
auto acquire = [&]() {
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, []{ return current_count < max_concurrent; });
++current_count;
};
auto release = [&]() {
std::unique_lock<std::mutex> lk(mtx);
--current_count;
lk.unlock();
cv.notify_one();
};
别用 std::thread::hardware_concurrency() 当最大并发数
std::thread::hardware_concurrency() 返回的是逻辑核心数（比如 8 核 16 线程），不是你该限制的“任务并发数”。它和 I/O 密集型任务的吞吐无关，也和 CPU 密集型任务的最佳并行度不等价——盲目设成这个值，常导致线程过多、上下文切换开销暴涨，或线程过少、资源闲置。
真正该设多少，取决于：
- 任务类型：CPU 密集型通常 ≤ 核心数；I/O 密集型可显著高于核心数（如 50~200），但要实测延迟与吞吐拐点
- 系统资源：内存、文件描述符、连接池大小等隐性瓶颈
- 外部依赖：调用的 API 是否限流？数据库连接是否复用？
建议从保守值起步（如 4 或 8），再根据 perf、htop、线程状态分布（pthread_getattr_np 或 /proc/[pid]/status 中的 Threads: 行）调优。
线程池比裸线程 + 限流更实用
如果你频繁创建/销毁线程，并靠信号量或互斥锁去“堵”并发，说明更适合上现成线程池——它内置队列、复用、优雅关闭，还自带并发控制参数。比如 boost::asio::thread_pool 的构造函数直接接受 int concurrency_hint；libuv、Intel TBB 的 task_arena 也提供类似机制。
自己手写线程池时，别只限制“正在执行”的线程数，还要考虑任务队列长度。否则高负载下任务堆积，内存涨、响应延迟不可控。典型反例：只用 semaphore 控制执行数，却不设队列上限，结果 10 万个待处理请求全挤在 std::queue 里吃光内存。
真正健壮的做法是双控：执行数上限 + 队列长度上限 + 拒绝策略（抛异常 / 返回失败 / 调用者同步执行）。
这比每次 new thread + semaphore 更贴近生产环境需求——毕竟线程创建本身就有开销，而池化后调度成本更低、缓存局部性更好。
