c# 如何避免在 lock 语句块内分配内存(GC.KeepAlive)

lock块内分配内存会引发GC压力和对象提早回收风险,因频繁创建临时对象及JIT误判生命周期;应将分配移出lock,复用缓冲区,禁用LINQ,慎用GC.KeepAlive仅限非托管资源场景。

为什么 lock 语句块里分配内存会引发问题

不是 lock 本身导致 GC 压力,而是锁内频繁创建临时对象(如字符串拼接、LINQ 查询、装箱、匿名函数闭包)会让 GC 频繁触发,尤其在高并发短临界区场景下,可能拖慢吞吐量或造成锁持有时间意外延长。更隐蔽的问题是:若锁保护的对象在 lock 块中被局部变量引用但未被后续代码使用,JIT 可能提前判定其“已死”,触发提早回收——哪怕锁还没释放,这在涉及非托管资源或回调注册时会出错。

哪些操作在 lock 中实际会分配内存

以下常见写法在 lock 块内执行时,几乎必然触发堆分配:

  • string.Concat(a, b, c)$"x={x} y={y}"(插值字符串在 .NET 6+ 有优化,但仍有逃逸可能)
  • list.Where(x => x > 0).ToList()(LINQ 构建迭代器 + 新 List)
  • new byte[1024]new Dictionary()
  • 任何值类型到 object 的装箱(如 obj = i; 其中 iint
  • 捕获局部变量的 lambda:ThreadPool.QueueUserWorkItem(_ => DoWork(x))x 被闭包捕获并堆分配)

如何避免:从分配源头控制 + GC.KeepAlive 的真实用途

GC.KeepAlive 不是用来“防止 lock 内分配”的,它只解决一个特定问题:确保某个对象在代码执行到某一点之前**不会被 GC 回收**,常用于 P/Invoke 场景中托管对象与非托管句柄生命周期不同步的情况。它对减少内存分配完全无效。

真正可行的策略是:

  • 把内存分配移出 lock —— 先计算、构造、复制,再进锁做原子更新
  • 复用缓冲区:用 ArrayPool.Shared.Rent() 替代 new byte[n]
  • Span / ReadOnlySpan 处理字符串切片,避免子串分配
  • 禁用 LINQ,改用 for 循环 + 预分配集合(如 var results = new List(capacity)
  • 若必须在锁内调用外部方法,确认该方法是否分配——必要时加注释或用 [MethodImpl(MethodImplOptions.AggressiveInlining)] 引导内联(仅适用于小函数)
private readonly object _sync = new();
private List _data = new();

public void AddRange(ReadOnlySpan items)
{
    // ✅ 分配在外:先拷贝到栈或复用池
    var temp = ArrayPool.Shared.Rent(items.Length);
    try
    {
        items.CopyTo(temp);
        // ✅ 锁内只做最小原子操作
        lock (_sync)
        {
            _data.AddRange(temp.AsSpan(0, items.Length));
        }
    }
    finally
    {
        ArrayPool.Shared.Return(temp);
    }
}

GC.KeepAlive 应该在什么时机用?别乱加

只有当你明确存在「对象在锁释放后仍需被非托管代码访问」的风险时才需要 GC.KeepAlive。典型场景是:你在 lock 块中调用了 Marshal.AllocHGlobal 并把指针传给了 native 代码,而托管对象(比如一个 byte[])只是用来管理这块内存的生命周期。

此时错误写法是:

lock (_sync)
{
    var buffer = new byte[1024];
    IntPtr ptr = Marshal.AllocHGlobal(1024);
    CopyToNative(ptr, buffer); // 假设这个函数把 buffer 数据复制过去
    RegisterWithNative(ptr);   // native 侧开始异步使用 ptr
    // ❌ buffer 在这里就可能被 GC 回收,即使 native 还在用 ptr
}

正确做法是让 buffer 的生命周期至少延续到 native 使用结束之后:

lock (_sync)
{
    var buffer = new byte[1024];
    IntPtr ptr = Marshal.AllocHGlobal(1024);
    CopyToNative(ptr, buffer);
    RegisterWithNative(ptr);
    // ✅ 确保 buffer 不被提前回收,直到 native 完成
    GC.KeepAlive(buffer);
}

注意:GC.KeepAlive 必须放在所有依赖该对象的逻辑之后,且不能被 JIT 优化掉(它本质是插入一个“使用”屏障)。它和 lock 没有语法绑定关系,加在锁外、锁内、甚至锁后都行——关键是语义上要覆盖整个非托管使用期。

绝大多数

业务代码根本不需要 GC.KeepAlive;滥用它只会掩盖设计缺陷,比如本该用 SafeHandle 封装的资源却手动管理生命周期。