c++标准库不支持stm，所有实现均为第三方或编译器扩展（如已弃用的gcc __transaction_atomic）；真用stm需选libcds或手写乐观锁事务，但性能通常不如锁，仅适用于低争用、跨对象原子更新等特定场景。
STM 在 C++ 中没有标准库支持，得靠第三方库或手写
标准 C++（包括 C++20/C++23）不提供 std::transaction、atomic_block 或任何原生 STM 设施。你看到的“C++ STM”全是外部实现，要么是研究型库（如 libcds 的实验模块），要么是学术项目（如 tinystm、libitm），或者基于编译器扩展（GCC 的 __transaction_atomic，但已弃用且不跨平台）。直接写 transaction{ /*...*/ } 会编译失败。
常见误判是把 std::mutex + std::lock_guard 当成 STM —— 那只是锁，不是事务：它不支持重试、无死锁保证、不可组合、也无法原子地读-改-写多个非关联对象。
gcc 的 __transaction_atomic 已不可靠，别在新项目里用
GCC 4.7–6 曾通过 -fgnu-tm 启用硬件/软件混合事务内存（Transactional Memory），语法形如：
__transaction_atomic {
x++;
y = x * 2;
}
但它依赖底层内核和 CPU 支持（如 Intel RTM），实际运行常 fallback 到慢速软件路径；GCC 7+ 彻底移除了该特性，Clang 从未支持。现在硬写这个，编译直接报错 error: transactional memory not supported，或链接时找不到 libitm。
如果你在旧代码里见到它，迁移方案只有两个：
• 改用细粒度锁 + 重试逻辑模拟事务语义
• 换成现代 STM 库（见下一条）
想真用 STM？选 libcds 或手写轻量级乐观锁事务
libcds 是目前最成熟的 C++ 并发数据结构库，其 cds::container::MichaelHashMap 等容器内部用乐观并发控制（OCC）模拟事务行为，虽不暴露顶层 begin_transaction()，但能保证多 key 更新的原子性与一致性。更直接的做法是手写一个基于版本戳的轻量事务：
核心思路：每个共享变量带 version 字段；事务开始时记录所有读取对象的 version；提交前再次校验是否全未变；任一被修改就中止并重试。
关键点：
- 必须用
std::atomic<size_t></size_t>存 version，避免 ABA 问题 - 读操作要
load(std::memory_order_acquire)，写提交要compare_exchange_weak - 不能嵌套事务——C++ 没有栈式事务上下文，重试逻辑得显式循环
- 长事务极易活锁，建议限制最大重试次数（如 100 次），超限降级为锁
性能比锁差很多，除非场景高度契合否则别上 STM
STM 的开销来自三部分：读集/写集记录、每次提交的版本校验、冲突时的完整回滚与重试。实测中，当争用率 >5%，STM 吞吐常比细粒度 std::shared_mutex 低 3–10 倍。
真正适合 STM 的场景非常窄：
- 大量只读 + 极少更新的共享数据（如配置缓存、路由表）
- 天然需要“要么全成功、要么全失败”的跨对象操作（如银行账户 A 扣款 + B 入账）
- 无法预知访问模式，导致锁顺序难设计（易死锁）
其他情况——比如保护一个计数器、一个队列、或一组有明确访问顺序的对象——直接用 std::mutex 或 std::atomic 更简单、更快、更可控。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
