c# Pin an object (GCHandle) 对GC和并发性能的影响_网络技术

Pin对象阻止GC移动但不阻止回收，需手动释放GCHandle以防泄漏；仅支持数组和blittable类型；应优先使用Span/Memory替代显式pin。

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 存在静态字段或跨线程共享；每个线程应独立管理自己的 han
dle
使用 fixed 语句比手动 GCHandle 更安全（编译器自动插 Free），但它只能用于局部作用域，且不能跨 await 边界

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

.NET Core 2.1+ 中，绝大多数原本需要 pin 的场景（如 socket send/receive、JSON 序列化、图像处理）已可通过 Span 和 Memory 安全绕过。它们由运行时内部管理 pin 状态，仅在真正进入非托管边界时临时 pin，且生命周期严格绑定到作用域。

socket.ReceiveAsync(new Memory(buffer)) 不需要你手动 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.Shared.Rent() + Memory 组合

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

# js # json # windows # access # ai # win # microsoft # c# # 作用域 # .net # red # Object # 结构体 # int # 指针 # 堆 # class # 值类型 # 线程 # 主线程 # 并发 # 对象 # 事件 # 异步 # http # ui # 用了 # 死锁 # 但不 # 回调 # 自己的 # 堆中 # 几个 # 就会 # 也不 # 钉住

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】