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

Python RESTful API设计终极指南:从理论到企业级实战

Python RESTful API设计终极指南:从理论到企业级实战

目录 摘要 1 引言:为什么RESTful API设计如此重要 1.1 RESTful API的核心价值定位 1.2 RESTful API演进路线图 2 RESTful API设计核心技术原理 2.1 资源设计哲学与实践 2.1.1 资源识别与建模 2.1.2 资源关系建模 2.2 统一接口原则深度解析 2.2.1 HTTP方法语义化使用 2.2.2 状态码语义化设计 2.3 HATEOAS超媒体驱动设计 2.3.1 HATEOAS原理与实现 2.3.2 HATEOAS客户端工作流程

By Ne0inhk
Python 列表内存存储本质:存储差异原因与优化建议

Python 列表内存存储本质:存储差异原因与优化建议

文章目录 * 1. 问题引入:列表存储的内存 "膨胀" * 2. 理论存储与实际存储的差异 * 2.1 64位整数的存储差异 * 2.2 短字符串的存储差异 * 3. 列表的内存存储本质 * 3.1 相同元素列表内存少的核心原因:对象复用 * 3.1.1 小整数的缓存复用机制 * 3.1.2 字符串的驻留(Intern)机制 * 3.2 不同元素列表内存高的原因:对象重复创建 * 3.2.1 不同整数的内存开销 * 3.2.2 不同字符串的内存开销 * 4. 内存占用对比分析 * 5. 优化建议:利用对象复用减少内存开销 * 6. 总结

By Ne0inhk
C++可变参数队列与压栈顺序:从模板语法到汇编调用约定的深度解析

C++可变参数队列与压栈顺序:从模板语法到汇编调用约定的深度解析

C++可变参数队列与压栈顺序:从模板语法到汇编调用约定的深度解析 本文聚焦一个具体而关键的技术主题:C++ 可变参数模板(Variadic Templates)。我们将从现代 C++ 的优雅写法出发,深入剖析其在 x86-64 架构下的真实行为,特别澄清一个长期被误解的核心问题——可变参数是否“从右向左压栈”?它们在寄存器和栈中究竟是如何排布的? 如果你正在实现一个类型安全的消息队列、日志系统或任务调度器,并希望理解 enqueue(1, "hello", 3.14) 这行代码在 CPU 层面到底发生了什么,那么这篇文章就是为你量身打造的。 一、引言:可变参数 ≠ va_list —— 一场范式革命 很多初学者将 C++ 的可变参数模板与 C 语言的 va_list 混为一谈。这是重大误区,甚至会导致错误的性能假设和安全漏洞。 1.1

By Ne0inhk