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存在静态字段或跨线程共享；每个线程应独立管理自己的 handle - 使用
fixed语句比手动GCHandle更安全（编译器自动插Free），但它只能用于局部作用域，且不能跨 await 边界
替代方案：Span 和 Memory 大幅减少显式 Pin 需求
.NET Core 2.1+ 中，绝大多数原本需要 pin 的场景（如 socket send/receive、JSON 序列化、图像处理）已可通过 Span 和 Memory 安全绕过。它们由运行时内部管理 pin 状态，仅在真正进入非托管边界时临时 pin，且生命周期严格绑定到作用域。
-
socket.ReceiveAsync(new Memory不需要你手动 pin；底层会在 I/O 发起瞬间 pin，完成后立即解 pin(buffer)) -
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 了就万事大吉。
