c# Pin an object (GCHandle) 对GC和并发性能的影响

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

Pin 对象会阻止 GC 移动该对象，但不阻止回收

调用

GCHandle.Alloc(obj, GCHandleType.Pinned)

后，GC 不会将该对象在堆中移动（即跳过 compact 阶段对该对象的重定位），但该对象仍可被回收——前提是

GCHandle

被释放且没有其他强引用。如果忘记调用

handle.Free()

，会导致内存泄漏；如果在异步或跨线程场景中提前释放了 handle，则后续访问 pinned 内存会触发

AccessViolationException

或静默读写错误。

只对数组（
byte[]
、
int[]
等）和 blittable 值类型结构体有效；对普通 class 实例调用
Pinned
会抛出
ArgumentException
pinning 本身开销极小（约几个纳秒），但副作用集中在 GC 行为上：被 pin 的对象会“钉住”其所在内存段，可能拖慢整个 generation 的 compact 过程 大对象堆（LOH）上的数组无法被 compact，所以 pinning LOH 对象不会加剧碎片，但会延长 GC 暂停时间（因为 GC 仍需扫描并标记 pinned 区域）

并发场景下 Pin 可能引发死锁或竞争条件

多个线程同时尝试 pin/unpin 同一对象不是问题，但若在 pin 期间执行跨线程操作（如回调、Task.ContinueWith、await），就容易出错。典型问题是：主线程 pin 一个 buffer，传给后台线程做非托管 I/O，后台线程完成时试图通过

SynchronizationContext

回调 UI 线程，而此时 UI 线程正因 GC 暂停卡住——若 pin 导致 GC 暂停变长，就会放大这种风险。

避免在
async
方法中 pin 对象后 await；应在同步上下文中完成 pin → 传递指针 → I/O → unpin 全流程不要把
GCHandle
存在静态字段或跨线程共享；每个线程应独立管理自己的 handle 使用
fixed
语句比手动
GCHandle
更安全（编译器自动插
Free
），但它只能用于局部作用域，且不能跨 await 边界

替代方案：Span 和 Memory 大幅减少显式 Pin 需求

.NET Core 2.1+ 中，绝大多数原本需要 pin 的场景（如 socket send/receive、JSON 序列化、图像处理）已可通过

Span<t></t>

和

Memory<t></t>

安全绕过。它们由运行时内部管理 pin 状态，仅在真正进入非托管边界时临时 pin，且生命周期严格绑定到作用域。

socket.ReceiveAsync(new Memory<byte>(buffer))</byte>
不需要你手动 pin；底层会在 I/O 发起瞬间 pin，完成后立即解 pin
Encoding.UTF8.GetString(span)
也不触发 pin；只有调用
span.Pin()
（已标记为 Obsolete）才显式暴露指针对 interop 场景，优先用
Marshal.AllocHGlobal
+ 手动管理内存，而非 pin 托管数组——尤其当数据要长期驻留非托管侧时

unsafe
{
    byte[] buffer = new byte[4096];
    fixed (byte* ptr = buffer)
    {
        // 编译器保证：ptr 在此块结束时自动失效，buffer 不会被 GC 移动
        NativeCall(ptr, buffer.Length);
    } // ← 自动 unpin，无需 GCHandle
}

性能实测的关键观察点

pinning 对吞吐影响不直接体现在 CPU 时间上，而反映在 GC 行为变化：gen0/1 compact 时间上升、LOH 碎片率升高、GC 触发频率微增。用

dotnet-trace

抓取

Microsoft-Windows-DotNETRuntime/GC/Start

和

/GC/End

事件，对比有无 pin 的 pause duration 分布，比看单次耗时更有意义。

每多一个长期 pinned 对象，就相当于在堆中“插了一根钉子”，GC 必须绕开它整理相邻内存；100 个 pinned 对象不一定比 1 个慢 100 倍，但可能让一次 gen1 compact 从 0.5ms 升至 3ms 使用
GC.GetTotalMemory(true)
无法检测 pin 引起的泄漏；要查
GCHandle
是否泄露，得用
dotnet-dump analyze
查
dumpheap -stat
中
GCHandle
实例数，再结合
gcroot
追踪引用链在高吞吐服务（如 Kestrel HTTP 处理）中，应避免在 request scope 内频繁 pin 数组；改用池化
ArrayPool<byte>.Shared.Rent()</byte>
+
Memory<t></t>
组合

pin 的代价不在分配那一刻，而在它迫使 GC 放弃优化机会；最危险的不是用了 pin，而是用了却忘了在哪解、或以为 pin 了就万事大吉。