我知道 C# 让程序员能够在不安全的上下文中访问和使用指针。但是什么时候需要呢？
在什么情况下，使用指针成为必然？
仅仅是出于性能原因吗？
另外，为什么 C# 会通过不安全的上下文公开此功能，并从中删除所有托管优势？理论上是否可以在不失去托管环境优势的情况下使用指针？
【问题讨论】：
标签： c# .net performance pointers unsafe
什么时候需要？什么情况下使用指针成为必然？
当托管安全解决方案的净成本不可接受但不安全解决方案的净成本可接受时。您可以通过从总成本中减去总收益来确定净成本或净收益。不安全解决方案的好处是“不会浪费时间进行不必要的运行时检查以确保正确性”；代价是 (1) 即使托管安全系统关闭，也必须编写安全的代码，以及 (2) 必须处理可能降低垃圾收集器效率的问题，因为它不能在具有非托管指针的内存中移动它。
或者，如果您是编写编组层的人。
仅仅是出于性能原因吗？
出于性能以外的原因在托管语言中使用指针似乎是不正当的。
在绝大多数情况下，您可以使用 Marshal 类中的方法来处理与非托管代码的互操作。 （在某些情况下，使用编组设备解决互操作问题可能很困难或不可能，但我不知道。）
当然，正如我所说，如果您是编写 Marshal 类的人，那么显然您无法使用编组层来解决您的问题。在这种情况下，您需要使用指针来实现它。
为什么 C# 会通过不安全的上下文公开此功能，并从中删除所有托管优势？
这些托管优势伴随着性能成本。例如，每次向数组询问第十个元素时，运行时都需要检查是否有第十个元素，如果没有则抛出异常。使用指针可以消除运行时成本。
相应的开发人员成本是，如果您做错了，那么您将处理内存损坏错误，这些错误会格式化您的硬盘并在一小时后使您的进程崩溃，而不是在错误发生时处理一个干净的异常。
理论上是否可以在不失去托管环境的任何优势的情况下使用指针？
我认为“优势”是指垃圾收集、类型安全和引用完整性等优势。因此，您的问题本质上是“理论上是否有可能关闭安全系统，但仍然可以获得打开安全系统的好处？”不，显然不是。如果您因为不喜欢它的昂贵而关闭该安全系统，那么您将无法获得开启它的好处！
【讨论】：
指针与托管的垃圾收集环境存在内在矛盾。
一旦你开始搞乱原始指针，GC 就不知道发生了什么。
具体来说，它无法判断对象是否可访问，因为它不知道您的指针在哪里。
它也不能在内存中移动对象，因为这会破坏你的指针。
所有这些都将通过 GC-tracked 指针解决；这就是引用。
您应该只在混乱的高级互操作场景或高度复杂的优化中使用指针。
如果你不得不问，你可能不应该问。
【讨论】：
interior_ptr
GC 可以移动引用；使用 unsafe 使对象不受 GC 控制，并避免了这种情况。 “固定”固定对象，但让 GC 管理内存。
根据定义，如果你有一个指向对象地址的指针，而 GC 移动了它，你的指针就不再有效。
关于为什么需要指针：主要原因是使用非托管 DLL，例如那些用 C++ 编写的
另请注意，当您固定变量并使用指针时，您更容易受到堆碎片的影响。
编辑
您已经谈到了托管代码与非托管代码的核心问题......内存是如何释放的？
您可以按照您的描述混合代码以提高性能，只是不能使用指针跨越托管/非托管边界（即，您不能在“不安全”上下文之外使用指针）。
至于它们是如何被清理的……你必须管理自己的记忆；您的指针指向的对象是使用（希望）CoTaskMemAlloc() 创建/分配的（通常在 C++ DLL 中），并且您必须以相同的方式释放该内存，调用 CoTaskMemFree()，否则您将有内存泄漏.请注意，只有使用CoTaskMemAlloc() 分配的内存才能使用CoTaskMemFree() 释放。
另一种选择是从您的本机 C++ dll 中公开一个方法，该方法接受一个指针并释放它...这让 DLL 决定如何释放内存，如果它使用其他方法来分配内存，则效果最好。您使用的大多数本机 dll 都是您无法修改的第三方 dll，而且它们通常没有（我见过的）此类可调用的函数。
释放内存的例子，取自here：
string[] array = new string[2];
array[0] = "hello";
array[1] = "world";
IntPtr ptr = test(array);
string result = Marshal.PtrToStringAuto(ptr);
Marshal.FreeCoTaskMem(ptr);
System.Console.WriteLine(result);
更多阅读材料：
C# deallocate memory referenced by IntPtr 下面的第二个答案解释了不同的分配/解除分配方法
How to free IntPtr in C#? 加强了以与分配内存相同的方式解除分配的需要
http://msdn.microsoft.com/en-us/library/aa366533%28VS.85%29.aspx 有关分配和释放内存的各种方法的官方 MSDN 文档。
简而言之...您需要知道内存是如何分配的才能释放它。
编辑
如果我正确理解您的问题，简短的回答是肯定的，您可以将数据交给非托管指针，在不安全的上下文中使用它，并在退出不安全的上下文后使数据可用。
关键是您必须使用fixed 块固定您引用的托管对象。这可以防止您引用的内存在 unsafe 块中被 GC 移动。这里涉及许多微妙之处，例如您不能重新分配在固定块中初始化的指针...如果您真的打算管理自己的代码，则应该阅读不安全和固定的语句。
总而言之，管理您自己的对象和以您描述的方式使用指针的好处可能不会像您想象的那样为您带来性能提升。为什么不这样做的原因：
HTH，
詹姆斯
【讨论】：
GC.AddMemoryPressure 和GC.RemoveMemoryPressure 显式通知垃圾回收来自非托管内存的内存压力。您仍然需要自己释放内存，但这样垃圾收集器在做出调度决策时会考虑非托管内存。
在 C# 中显式使用指针的最常见原因：
从 C# 中删除与指针相关的语法的原因（根据我的知识和观点——Jon Skeet 会更好地回答 B-））在大多数情况下被证明是多余的。
从语言设计的角度来看，一旦您通过垃圾收集器管理内存，您就必须对指针可以做什么和不可以做什么施加严格的限制。例如，使用指针指向对象的中间可能会给 GC 带来严重的问题。因此，一旦限制到位，您就可以省略额外的语法并以“自动”引用结束。
此外，在 C/C++ 中发现的超仁慈的方法是常见的错误来源。对于大多数情况下，微性能根本无关紧要，最好提供更严格的规则并约束开发人员以减少难以发现的错误。因此，对于常见的业务应用程序而言，.NET 和 Java 等所谓的“托管”环境比假定针对裸机工作的语言更适合。
【讨论】：
obj->Property, obj.Property 可以代替。将澄清我的答案。
假设您想使用 IPC（共享内存）在 2 个应用程序之间进行通信，那么您可以将数据编组到内存并通过 Windows 消息传递或其他方式将此数据指针传递给其他应用程序。在接收应用程序时，您可以取回数据。
在将数据从 .NET 传输到传统 VB6 应用程序的情况下也很有用，其中您将数据编组到内存，使用 win msging 将指针传递给 VB6 应用程序，使用 VB6 copymemory() 从托管内存空间获取数据到 VB6应用非托管内存空间..
【讨论】：