为什么 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<int string>()</int>任何值类型到
object的装箱(如
obj = i;其中
i是
int) 捕获局部变量的 lambda:
ThreadPool.QueueUserWorkItem(_ => DoWork(x))(
x被闭包捕获并堆分配)
如何避免:从分配源头控制 + GC.KeepAlive 的真实用途
GC.KeepAlive不是用来“防止 lock 内分配”的,它只解决一个特定问题:确保某个对象在代码执行到某一点之前**不会被 GC 回收**,常用于 P/Invoke 场景中托管对象与非托管句柄生命周期不同步的情况。它对减少内存分配完全无效。
真正可行的策略是:
把内存分配移出lock—— 先计算、构造、复制,再进锁做原子更新 复用缓冲区:用
ArrayPool<byte>.Shared.Rent()</byte>替代
new byte[n]用
Span<t></t>/
ReadOnlySpan<t></t>处理字符串切片,避免子串分配 禁用 LINQ,改用 for 循环 + 预分配集合(如
var results = new List<t>(capacity)</t>) 若必须在锁内调用外部方法,确认该方法是否分配——必要时加注释或用
[MethodImpl(MethodImplOptions.AggressiveInlining)]引导内联(仅适用于小函数)
private readonly object _sync = new();
private List<int> _data = new();
public void AddRange(ReadOnlySpan<int> items)
{
// ✅ 分配在外:先拷贝到栈或复用池
var temp = ArrayPool<int>.Shared.Rent(items.Length);
try
{
items.CopyTo(temp);
// ✅ 锁内只做最小原子操作
lock (_sync)
{
_data.AddRange(temp.AsSpan(0, items.Length));
}
}
finally
{
ArrayPool<int>.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封装的资源却手动管理生命周期。
