C++ 多线程同步之原子操作(atomic)实战

C++ 多线程同步之原子操作(atomic)实战

C++ 多线程同步之原子操作(atomic)实战

在这里插入图片描述

💡 学习目标:掌握 C++ 标准库中原子操作的使用方法,理解原子操作与互斥锁的区别,能够在轻量级同步场景中高效解决数据竞争问题。
💡 学习重点std::atomic 模板的常用接口、原子操作的特性、原子类型与普通类型的性能对比、原子操作的典型应用场景。

50.1 原子操作的引入背景

在 48 章我们学习了互斥锁,它通过阻塞线程的方式实现临界区保护。
但互斥锁存在上下文切换开销,在一些简单的同步场景中显得过于笨重。
比如对单个变量的自增、自减、赋值等操作,我们需要一种更轻量级的同步方案——原子操作。

⚠️ 注意事项:原子操作仅适用于单个变量的简单同步,无法替代互斥锁实现复杂临界区的保护。

举个例子,使用互斥锁保护变量自增:

#include<iostream>#include<thread>#include<mutex>usingnamespace std;int count =0; mutex mtx;voidincrement(){for(int i =0; i <100000;++i){ lock_guard<mutex>lock(mtx); count++;}}intmain(){ thread t1(increment); thread t2(increment); t1.join(); t2.join(); cout <<"最终 count 值:"<< count << endl;return0;}

这段代码虽然能保证线程安全,但每次加锁解锁都会带来额外开销。
原子操作可以在无锁的情况下实现同样的效果,且效率更高。

50.2 C++ 标准库中的原子操作

C++11 标准库在 <atomic> 头文件中提供了 std::atomic 模板类。
它可以将普通类型包装成原子类型,支持原子化的读、写、修改操作。

50.2.1 std::atomic 的核心特性

  1. 无锁同步:原子操作通过 CPU 指令级别的支持实现同步,不需要操作系统介入上下文切换。
  2. 不可分割性:原子操作的执行过程不会被其他线程打断,要么完全执行,要么完全不执行。
  3. 模板化设计std::atomic 是模板类,可以包装大多数基本数据类型,如 intboollong 等。

50.2.2 常用原子操作接口

std::atomic<int> 为例,常用接口如下:

  • 赋值与读取:支持直接用 = 赋值,用 load() 读取值,默认是顺序一致的内存序。
  • 自增自减fetch_add()(原子自增)、fetch_sub()(原子自减),返回操作前的值。
  • 复合操作exchange()(原子交换值)、compare_exchange_weak()(比较并交换)。
  • 简化操作:支持 ++--+=-= 等重载运算符,使用更便捷。

核心结论:原子操作的重载运算符(如 ++)是对 fetch_add() 的封装,使用起来和普通变量几乎一致。

50.3 原子操作实战:替代互斥锁解决简单同步问题

我们使用 std::atomic<int> 改造 50.1 节的例子,实现无锁同步:

#include<iostream>#include<thread>#include<atomic>usingnamespace std; atomic<int>count(0);// 定义原子类型变量voidincrement(){for(int i =0; i <100000;++i){ count++;// 原子自增操作,无需加锁}}intmain(){ thread t1(increment); thread t2(increment); t1.join(); t2.join(); cout <<"最终 count 值:"<< count << endl;return0;}

运行该程序,最终 count 的值稳定等于 200000
和互斥锁版本相比,这段代码不仅更简洁,而且执行效率更高。

50.3.1 原子操作的内存序(可选进阶知识点)

std::atomic 的操作可以指定内存序,用来平衡性能和同步强度。
常用的内存序有三种:

  1. memory_order_seq_cst:顺序一致内存序,最强的同步保证,也是默认值。
  2. memory_order_acquire/release:适用于生产者-消费者模型,保证操作的先后顺序。
  3. memory_order_relaxed:松散内存序,仅保证操作的原子性,不保证顺序,性能最优。

示例:使用松散内存序优化自增操作

voidincrement(){for(int i =0; i <100000;++i){ count.fetch_add(1, memory_order_relaxed);}}

在只需要保证原子性的场景下,松散内存序可以显著提升性能。

50.4 原子操作 vs 互斥锁:适用场景对比

特性原子操作互斥锁
同步粒度仅支持单个变量的原子操作支持任意复杂的临界区代码
性能开销低(CPU 指令级,无上下文切换)高(可能触发上下文切换)
使用复杂度低(类似普通变量,无需手动加解锁)高(需手动管理锁的生命周期)
死锁风险有(不当使用会导致死锁)

💡 选型技巧

  • 简单变量同步(如计数器、标志位)→ 优先使用原子操作
  • 复杂临界区(如多变量操作、函数调用)→ 必须使用互斥锁

50.5 实战案例 1:原子标志位实现线程退出控制

原子布尔类型 std::atomic<bool> 常用于实现线程的安全退出控制:

#include<iostream>#include<thread>#include<atomic>#include<chrono>usingnamespace std; atomic<bool>is_running(true);// 原子标志位voidworker(){while(is_running.load()){// 原子读取标志位 cout <<"线程正在运行..."<< endl; this_thread::sleep_for(chrono::milliseconds(500));} cout <<"线程安全退出"<< endl;}intmain(){ thread t(worker); this_thread::sleep_for(chrono::seconds(2)); is_running =false;// 原子赋值,通知线程退出 t.join(); cout <<"主线程结束"<< endl;return0;}

运行效果:线程运行 2 秒后,检测到标志位变为 false,安全退出。
这个场景用原子操作比互斥锁更轻量、更高效。

50.6 实战案例 2:原子计数器实现多线程任务统计

使用原子操作实现多线程任务完成情况的统计,无需加锁:

#include<iostream>#include<thread>#include<atomic>#include<vector>usingnamespace std;constint TASK_COUNT =10; atomic<int>completed_tasks(0);// 已完成任务数voidtask(int id){ cout <<"任务"<< id <<"开始执行"<< endl; this_thread::sleep_for(chrono::milliseconds(300)); completed_tasks++;// 原子自增,统计完成数 cout <<"任务"<< id <<"执行完毕"<< endl;}intmain(){ vector<thread> threads;for(int i =1; i <= TASK_COUNT;++i){ threads.emplace_back(task, i);}for(auto& t : threads){ t.join();} cout <<"所有任务执行完毕,总计完成:"<< completed_tasks <<"个"<< endl;return0;}

运行该程序,最终输出的完成任务数一定等于 10
这个案例充分体现了原子操作在简单统计场景下的优势。

50.7 原子操作的常见误区

  1. 忽略内存序的影响
    在多线程通信场景下,随意使用松散内存序可能导致程序行为异常。
    新手建议优先使用默认的顺序一致内存序,熟悉后再优化。
  2. 认为原子操作一定比互斥锁快
    在高竞争场景下,原子操作的自旋等待可能导致 CPU 占用过高。
    此时互斥锁的阻塞机制反而更高效。

误用原子操作保护复杂逻辑
原子操作只能保证单个操作的原子性,不能保护多个原子操作的组合。
例如:

// 错误示例:这两个原子操作的组合不是原子的if(count <100){ count++;}

这个逻辑可能被多个线程打断,需要互斥锁来保护。

50.8 本章小结

  1. 原子操作是轻量级同步方案,通过 CPU 指令级支持实现无锁同步,适用于单个变量的同步场景。
  2. std::atomic 是 C++ 标准库的原子类型模板,支持自增、自减、交换等常用原子操作。
  3. 原子操作和互斥锁各有适用场景:简单变量用原子操作,复杂临界区用互斥锁。
  4. 原子操作的内存序可以平衡性能和同步强度,新手建议先使用默认的顺序一致内存序。

Read more

【杂谈】-AGI的皇帝新衣:OpenAI商业模式能否抵御开源模型冲击?

【杂谈】-AGI的皇帝新衣:OpenAI商业模式能否抵御开源模型冲击?

AGI的皇帝新衣:OpenAI商业模式能否抵御开源模型冲击? 文章目录 * AGI的皇帝新衣:OpenAI商业模式能否抵御开源模型冲击? * 01 资本迷局:循环交易构筑的脆弱根基 * 02 效率革命:开源模型的双重突破 * 03 场景变革:边缘智能与中心化模型的根本冲突 * 04 安全困局:AGI叙事遭遇现实壁垒 * 05 理想落差:AGI愿景与商业现实的鸿沟 当DeepSeek等开源模型以百分之一的成本实现近似性能,当AI应用向边缘计算与垂直场景渗透,OpenAI押注万亿美元的AGI蓝图正浮现裂痕。 在ChatGPT引爆全球AI热潮两年后,一场静默的革命正在重塑行业格局。2025年,中国开源模型DeepSeek V3.2以极低训练成本,在多项基准测试中追平耗资巨大的GPT-5;月球暗面公司的Kimi K2 Thinking通过混合专家架构创新,仅用460万美元即实现同等性能。这些数字背后,折射出OpenAI闭源帝国面临的根本性挑战。 01 资本迷局:循环交易构筑的脆弱根基 OpenAI构建了一套精密的资本运作体系。其与英伟达、A

By Ne0inhk
Git 提交信息的规范化简写格式

Git 提交信息的规范化简写格式

你想了解的是 Git 提交信息的规范化简写格式(也常被称为 Conventional Commits 规范),除了 feat、fix、refactor 之外,还有很多不同类型的前缀可以让提交信息更清晰、更有语义。 完整的规范提交前缀及含义 以下是业界通用的 Conventional Commits 规范中常用的前缀,按使用场景分类,每个前缀都有明确的语义: 前缀中文含义使用场景举例feat新增功能feat: 新增商品详情页分享功能fix修复 Bugfix: 修复移动端下拉刷新数据重复的问题refactor代码重构(无功能变更)refactor: 重构订单列表组件,优化代码结构docs文档修改docs: 更新 README 中的接口使用说明style代码格式调整(无逻辑变更)style: 格式化代码缩进,修正变量命名规范test测试相关test: 为用户登录接口添加单元测试chore琐碎工作(构建/工具等)chore: 升级依赖包 axios 到 1.6.0 版本perf性能优化perf: 优化商品列表查询 SQL,提升接口响应速度build构建相关(

By Ne0inhk
Qwen3.5开源矩阵震撼发布!从0.8B到397B,不同规模模型性能、显存、速度深度对比与选型指南来了!

Qwen3.5开源矩阵震撼发布!从0.8B到397B,不同规模模型性能、显存、速度深度对比与选型指南来了!

截至今天2026年3月3日,Qwen3.5已形成从0.8B到397B的完整开源矩阵,分为轻量稠密(0.8B/2B/4B/9B/27B)、中型MoE(35B-A3B/122B-A10B)、旗舰MoE(397B-A17B)三大梯队。不同尺度在性能、显存、速度、场景上差异显著,下面是完整对比与选型指南,仅供参考。 一、Qwen3.5全尺度核心参数总览(2026.3最新) 1.轻量稠密系列(Dense,个人/边缘/轻量服务) 名称总参数激活参数架构上下文显存****FP164bit****量化显存定位Qwen3.5-0.8B0.8B0.8BDense32K1.6GB0.4GB极致轻量、端侧/实时交互Qwen3.5-2B2B2BDense32K4GB1GB移动端/IoT、低延迟对话Qwen3.5-4B4B4BDense64K8GB2GB轻量Agent、多模态基座Qwen3.

By Ne0inhk