c# ARM64 和 x64 架构对c#并发代码性能的影响

来源：这里教程网时间：2026-02-21 17:37:13 作者：

ARM64 和 x64 在

SpinWait

行为上的差异直接影响忙等待效率

ARM64 架构没有 x86/x64 的

PAUSE

指令等效物，而 .NET 的

SpinWait.SpinOnce()

在 x64 上会插入

PAUSE

以降低功耗和提升流水线效率；在 ARM64 上则退化为纯空循环（或调用

YIELD

，取决于运行时版本）。这意味着在高争用自旋锁场景下，ARM64 可能出现更高 CPU 占用、更差的吞吐量。

.NET 6+ 对 ARM64 引入了
YIELD
（
yield
指令）替代方案，但效果仍弱于
PAUSE
—— 它不提示微架构暂停解码，仅让出当前逻辑核心时间片若代码显式使用
Thread.SpinWait(int)
或手写
while (!ready) { Thread.Yield(); }
，ARM64 下需格外注意循环退出条件是否严格，避免因调度延迟导致意外长等待验证方法：用
dotnet trace
抓取
Microsoft-Windows-DotNETRuntime:SpinWait
事件，在两平台对比实际自旋次数与耗时

Interlocked

操作在 ARM64 上需要显式内存屏障语义

x64 是强内存模型，多数

Interlocked

方法（如

Interlocked.CompareExchange

）天然具备 acquire/release 语义；ARM64 是弱内存模型，.NET 运行时必须在生成代码时插入额外的

DMB

（Data Memory Barrier）指令来保证顺序。这带来两个实际影响：

单次
Interlocked
调用开销略高（约 1–2ns 额外延迟），在极短临界区（如计数器累加）中可测出差距若混用
volatile
字段与
Interlocked
，ARM64 下更容易暴露未定义行为 —— 例如
volatile int flag
+
Interlocked.Increment(ref counter)
并不能保证 flag 的写对其他线程可见，必须统一用
Interlocked
或明确加
Volatile.Write
.NET 7 开始，JIT 对 ARM64 的
Interlocked.Read/Write
生成更紧凑的指令序列，但
CompareExchange
类仍需完整屏障

ThreadPool 线程调度在 ARM64 设备上受物理核心数与能效核限制

Windows on ARM64（如 Surface Pro X）或 Linux ARM64（如 AWS Graviton）常采用大小核（big.LITTLE）设计，而 .NET 默认的

ThreadPool

调度器并不感知能效核拓扑。结果是：

默认最小线程数（
SetMinThreads
）在 ARM64 上若设得过高，容易把任务堆积在少数高性能核上，其余能效核闲置，整体吞吐反而下降 Linux ARM64 下，若未启用
cgroups v2
或未绑定
CPUSet
，JIT 编译线程可能被调度到能效核，导致首次并发请求延迟明显升高（尤其 ASP.NET Core 启动期）建议做法：通过
dotnet-monitor
观察
threadpool\queue-length
和
threadpool\completed-items-per-second
，再结合
lscpu
或
cat /sys/devices/system/cpu/cpu*/topology/core_type
判断是否需手动调优
COMPlus_ThreadPool_UnfairSemaphoreSpinLimit
或限制线程数

ConcurrentDictionary 在 ARM64 上的分段锁竞争模式更敏感

ConcurrentDictionary<tkey tvalue></tkey>

内部按桶分段加锁，x64 下因缓存行对齐和原子操作延迟低，分段冲突率通常较低；ARM64 的 L1d 缓存一致性协议（如 MOESI 变种）在跨核更新同一缓存行时开销更大，导致：

当键哈希分布不均（如大量相同前缀字符串），多个线程持续争抢同一段锁，ARM64 下的平均等待时间上升更显著
GetOrAdd
中的委托执行若含 I/O 或长计算，会延长锁持有时间 —— 在 ARM64 上这种“锁内阻塞”更容易引发级联等待，建议改用
TryAdd
+ 外部重试，或预热字典减少运行时扩容可临时启用
ConcurrentDictionary
的调试模式（设置环境变量
DOTNET_SYSTEM_COLLECTIONS_CONCURRENTDICTIONARY_DEBUG=1
），观察各 segment 的
LockAcquisitionCount
分布

var dict = new ConcurrentDictionary<string, int>();
// ARM64 下更应避免这种写法：
dict.GetOrAdd("key", _ => {
    Thread.Sleep(10); // 锁内阻塞 → 扩大争用窗口
    return 42;
});
// 推荐拆解：
if (!dict.TryGetValue("key", out var value)) {
    value = ExpensiveCalculation(); // 移出锁作用域
    dict.TryAdd("key", value);
}

ARM64 并发性能不是简单“快或慢”的问题，而是内存模型、调度策略、硬件特性三者耦合的结果。最容易被忽略的是：同一份看似无害的