Windows平台下Interlocked API是否仍在使用？何时及为何替代atomic？

一、Interlocked API还在用吗？ #

当然用，它至今仍是Windows生态里离不开的同步工具——系统底层组件、维护了十几年的Win32老项目，甚至不少新写的特定场景代码，都在依赖它。

二、和C++ atomic比，Interlocked API的适用场景及原因 #

1. 纯C环境或老Win32项目兼容需求 #

• 很多十几年前的纯C Win32项目，从开发初期就基于Interlocked API写同步逻辑，现在要换成C++ atomic的话，得全量测试验证，成本高到没必要。
• 纯C环境里根本用不了C++ atomic（它是C++标准库的特性），这时候Interlocked API是唯一的原生原子操作选择。

2. 需底层硬件指令级控制的场景 #

• Interlocked API能直接映射到x86/ARM的硬件原子指令，比如InterlockedCompareExchange就是对x86 cmpxchg指令的直接封装。有些做极致性能优化的开发者，就需要这种精准的底层控制，而C++ atomic的抽象层可能会隐藏一些细节。
• 部分Interlocked函数自带明确的内存屏障语义，比如InterlockedReleaseAcquire，能满足一些对内存模型有特殊要求的底层同步场景，比C++ atomic的内存顺序参数更直接。

3. Windows内核/系统深度交互场景 #

• 要是写Windows内核驱动、或者和系统底层组件交互，Interlocked API是系统原生支持的接口，兼容性拉满。内核模式下的同步操作，基本都是用Interlocked系列函数，而非C++ atomic。
• 搭配Windows特有的同步机制（比如临界区、事件）时，Interlocked API能写出更贴合系统生态的同步逻辑，避免C++ atomic和系统API之间可能出现的适配问题。

4. 跨语言调用场景 #

• 当需要跨语言交互时（比如C#调用原生DLL、汇编和C代码交互），Interlocked的C风格接口更容易被其他语言绑定调用。而C++ atomic的模板特性、名字修饰规则，会让跨语言调用的复杂度飙升。

内容的提问来源于stack exchange，提问作者yoonsoh