必须用 GCHandle 固定托管对象当非托管代码异步访问或长期持有托管内存地址时，否则 GC 可能移动或释放内存导致崩溃；常见于重叠 I/O、回调函数、显存映射等场景。
什么时候必须用 GCHandle 固定托管对象
当你要把托管内存地址（比如 byte[]、struct 实例）传给非托管代码（如 C DLL 的指针参数），而该非托管函数会**异步访问或长期持有这个地址**时，GCHandle 就不可省略。GC 不知道你在非托管侧还用着这块内存，可能在下次回收时移动或释放它，导致访问违规或数据错乱。
常见场景包括：调用 WriteFile 的重叠 I/O、注册回调函数传入结构体指针、OpenGL/Vulkan 显存映射、FFmpeg 解码器传入缓冲区等。
- 仅临时同步调用（如一次
memcpy）且不保存指针 → 可用fixed语句，更轻量 - 需要跨 P/Invoke 边界长期有效（尤其涉及线程回调、异步完成例程）→ 必须用
GCHandle.Alloc -
string传给非托管代码时，优先用Marshal.StringToHGlobalAnsi等，而不是固定字符串对象（string是不可变且可能被 intern，固定它风险高）
GCHandle.Alloc 的三种类型怎么选
GCHandle 有四种类型，但实际常用的是前三个：
-
GCHandleType.Normal：只防止 GC 移动，**不阻止回收**。适用于你已确保对象生命周期长于非托管使用期（例如全局 static 对象），但极少单独用 -
GCHandleType.Pinned：最常用。固定内存位置 + 防止回收，返回可直接转为IntPtr的地址。适用于数组、结构体等连续内存块 -
GCHandleType.Weak和WeakTrackResurrection：不阻止回收，只用于观察对象是否存活，和“固定”无关，此处不讨论
注意：Pinned 会增加 GC 压力——被固定的内存块无法被压缩，碎片化加剧。不要长期持有大量 Pinned 句柄，用完立刻 Free()。
正确分配与释放 GCHandle 的写法
典型错误是忘记 Free()，或在异常路径下泄漏句柄（导致内存无法回收、程序变慢甚至崩溃）。
推荐写法（以固定 byte[] 为例）：
byte[] buffer = new byte[1024];
GCHandle handle = GCHandle.Alloc(buffer, GCHandleType.Pinned);
try
{
IntPtr ptr = handle.AddrOfPinnedObject();
// 传给非托管函数，例如：
// SomeUnmanagedFunc(ptr, (uint)buffer.Length);
}
finally
{
if (handle.IsAllocated)
handle.Free(); // 必须放 finally 中
}
-
AddrOfPinnedObject()返回的是数组首地址（对byte[]是&array[0]），不是对象头地址 - 对结构体，先用
Marshal.StructureToPtr拷贝到非托管内存，再固定该非托管内存块；或直接用Marshal.AllocHGlobal+Marshal.StructureToPtr，避免固定托管结构体（结构体字段可能含引用类型，Pinned不安全） - 不能对普通类实例（
class）使用Pinned—— 它们在堆上布局不连续，固定无意义且会抛ArgumentException
替代方案：什么情况下不该用 GCHandle
不是所有“传指针”都要 GCHandle。过度使用反而引入复杂性和风险。
- 传
int*、float*等简单类型数组 → 用fixed更简洁安全（编译器自动插Free） - 需要非托管侧长期持有缓冲区 → 考虑让非托管代码自己分配（如通过回调函数传入分配器），或用
Marshal.AllocHGlobal分配非托管内存，托管侧只负责拷入/拷出 - Interop 层较复杂时，可用
Span+MemoryMarshal.AsPointer（.NET Core 2.1+），但前提是该指针**只在当前同步调用栈内使用**，且非托管侧不存储 - COM 互操作、Windows Runtime 类型 → 用
ComImport或 WinRT projection，底层已处理内存管理
真正难的不是怎么写 GCHandle.Alloc，而是判断“非托管侧到底会不会异步读写”以及“谁负责释放”。这两点没理清，Free() 放早了或放晚了，都会出静默故障。
