.NET 8中ReaderWriterLockSlim引发CPU过载的问题排查与解决

将项目从.NET 6迁移至.NET 8后，使用ReaderWriterLockSlim时出现CPU性能问题：.NET 8下CPU消耗比.NET 6高4-5倍。以下是用于性能测试的代码：

public class ReaderWriterSlimTests
{
    private static readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();

    private static int _sharedResource = 0;
    private static readonly int ReaderCount = Environment.ProcessorCount * 2;
    private static readonly int WriterCount = Environment.ProcessorCount / 2;
    private static readonly int Iterations = 1_000_000;
    private static volatile bool _running = true;

    public void RunTests()
    {
        Console.WriteLine($"Running test on .NET {Environment.Version}");
        Console.WriteLine($"Readers: {ReaderCount}, Writers: {WriterCount}, Iterations: {Iterations}");

        Stopwatch stopwatch = Stopwatch.StartNew();
        Process process = Process.GetCurrentProcess();
        TimeSpan startCpuTime = process.TotalProcessorTime;

        Thread[] readers = new Thread[ReaderCount];
        Thread[] writers = new Thread[WriterCount];

        // Start readers
        for (int i = 0; i < ReaderCount; i++)
        {
            readers[i] = new Thread(ReaderTask);
            readers[i].Start();
        }

        // Start writers
        for (int i = 0; i < WriterCount; i++)
        {
            writers[i] = new Thread(WriterTask);
            writers[i].Start();
        }

        // Run for a few seconds
        Thread.Sleep(30000);
        _running = false;

        // Wait for all threads to finish
        foreach (var reader in readers) reader.Join();
        foreach (var writer in writers) writer.Join();

        stopwatch.Stop();
        TimeSpan endCpuTime = process.TotalProcessorTime;
        double cpuUsage = (endCpuTime - startCpuTime).TotalMilliseconds / stopwatch.ElapsedMilliseconds * 100;

        Console.WriteLine($"Elapsed Time: {stopwatch.ElapsedMilliseconds} ms");
        Console.WriteLine($"CPU Usage Approximation: {cpuUsage:F2}%");
    }

    private void ReaderTask()
    {
        while (_running)
        {
            _lock.EnterReadLock();
            var value = _sharedResource; // Simulate read
            _lock.ExitReadLock();
        }
    }

    private void WriterTask()
    {
        Random rnd = new Random();
        while (_running)
        {
            _lock.EnterWriteLock();
            _sharedResource = rnd.Next(); // Simulate write
            _lock.ExitWriteLock();
        }
    }
}

测试结果：.NET 6中CPU使用率约300%，.NET 8中约1800%。

原因分析 #

• 自旋等待策略调整：.NET 8对ReaderWriterLockSlim的自旋逻辑进行了优化，但在高并发无间隙的锁竞争场景下，默认的自旋次数/时间被增加，导致线程在抢锁失败时持续空转，大量消耗CPU。相比之下，.NET 6的自旋策略更保守，空转时间更短。
• 极端测试场景放大差异：测试代码是无停顿的循环抢锁，没有任何业务逻辑延迟，这种场景会让同步原语的自旋行为被无限放大。实际业务场景中，读写操作通常伴随业务逻辑，锁竞争频率远低于该测试场景，因此性能差异不会如此显著。
• 线程调度优化的副作用：.NET 8的线程池调度算法有更新，在多核心环境下，线程可能更频繁地在核心间切换，叠加自旋等待的CPU消耗，进一步推高了整体使用率。

解决方法 #

1. 调整锁竞争的等待策略 #

避免无限制的自旋抢锁，改用TryEnterReadLock/TryEnterWriteLock并配合短暂等待，减少CPU空转：

private void ReaderTask()
{
    while (_running)
    {
        if (_lock.TryEnterReadLock(1)) // 加入1ms的等待超时
        {
            var value = _sharedResource;
            _lock.ExitReadLock();
        }
        else
        {
            Thread.SpinWait(10); // 轻量级自旋等待，避免线程上下文切换
        }
    }
}

private void WriterTask()
{
    Random rnd = new Random();
    while (_running)
    {
        if (_lock.TryEnterWriteLock(1))
        {
            _sharedResource = rnd.Next();
            _lock.ExitWriteLock();
        }
        else
        {
            Thread.SpinWait(10);
        }
    }
}

2. 模拟实际业务延迟 #

在读写操作后加入微小延迟，贴近真实业务场景，降低锁竞争频率：

private void ReaderTask()
{
    while (_running)
    {
        _lock.EnterReadLock();
        var value = _sharedResource;
        _lock.ExitReadLock();
        Thread.Sleep(1); // 模拟业务处理延迟
    }
}

private void WriterTask()
{
    Random rnd = new Random();
    while (_running)
    {
        _lock.EnterWriteLock();
        _sharedResource = rnd.Next();
        _lock.ExitWriteLock();
        Thread.Sleep(1);
    }
}

3. 改用更适合的同步原语 #

如果业务场景允许，可替换为更适配高并发读写的结构：

• 针对简单数值类型，使用Interlocked类的原子操作替代锁，完全避免锁竞争。
• 针对集合场景，使用ConcurrentDictionary等线程安全集合，内部已优化同步逻辑。

4. 升级.NET 8补丁 #

微软后续可能针对该极端场景的自旋问题发布修复补丁，确保使用最新的.NET 8版本。

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