Delphi中ARC内存管理的方向

几年前，当Embarcadero开始为Windows以外的平台构建新的Delphi编译器时，就核心语言功能和语言的整体感知而言，有很多讨论新Delphi与当前语言的兼容性。最终出现的决定是保持极高程度的兼容性，并采用一些重要而大胆的步骤来实现更能吸引新一代开发人员的语言。 

什么是自动参考计数？

（具有弱引用的交叉链接对象）

其中一个变化就是决定采用新的移动平台内存管理模式，遵循Apple已经推出的iOS内存模式：自动引用计数或ARC。在使用垃圾收集的移动电话这样的内存受限设备上通常被认为是一个问题（因为您最终消耗的内存比严格需要的内存多，并且还会影响电池寿命）并且ARC提供了简化的内存管理模型，更易于使用在简单的场景中，完全确定性和健壮性。

这就是为什么Delphi选择相同的模型，扩展对象引用计数模型已经可用于接口很长一段时间了，使得它更强大的弱和不安全的引用，并将其扩展为普通的对象变量。该模型确实提供了一些显着的优势，其中一个最初的想法是在所有平台上将其扩展为Delphi语言。

ARC缺点

（缠绕弱和强引用）

在计划推出几年后，我们仍然看到它的优势和好处，但我们对ARC模型的缺点以及它在Windows和VCL应用程序中使其成为默认值的效果更加清晰。 。

我们长期以来一直认为ARC内存管理是对传统Delphi模型的改进，因为它消除并简化了一些内存管理。但是，我们在构建和维护大型库时，以及在复杂的代码库上与客户交谈时已经学到了这一点，虽然ARC在纸上看起来很棒，对于局部变量和更简单的场景，但它往往会给复杂场景带来很多麻烦。我们所有库的TComponent所有权模型都与ARC不一致，使得支持ARC的现有组件库变得复杂。
我们本可以决定在Windows上使用“完全ARC”，但这会导致现有应用程序和组件的严重破坏，造成比我们过去的Unicode迁移更多的麻烦 - 这是由于外部压力造成的提供良好的国际支持以及底层操作系统（从Windows开始）也是Unicode的事实。

我们有许多要求使ARC成为可选项，但是一个启用ARC的对象不会轻易与非启用ARC的对象共存，我们需要两种对象的容器，并且无法混合它们。这最终将成为一个非常复杂的场景。混合ARC和非ARC不是一个可行的解决方案，但是在不同平台上保持不同的内存模型最终会击败“单一来源，多平台”的整个想法，这是当今Delphi服务器端的核心原则（Windows和Linux）和所有平台上的客户端站点都可以构建FireMonkey应用程序。

另一个重要的角度是ARC具有运行时成本。虽然可以对事物进行优化和改进，但最终自动管理并非完全免费。虽然垃圾收集在开始时具有（非常高的）成本，但ARC在对象生命周期和对象交互方面有成本（除非您小心地将const用于所有参数传递）。禁用ARC的积极效果是可衡量的性能改进。最后，Delphi中的ARC与产品的C ++方面有点不一致，后者是RAD Studio不可或缺的一部分。

新计划：逐步淘汰ARC

（在Delphi中使用接口）

考虑到所有这些因素，经过广泛的内部讨论，还涉及合作伙伴和外部开发人员，我们得出的结论是，最好的方法是将ARC模型作为默认的内存管理解决方案，并弥补其损失与其他选择。

实际上，10.3 Rio版本中的Linux 64位编译器将提供Windows平台的传统Delphi内存管理，使您的Windows和Linux服务器端代码完全等效 - 至少在Delphi语言和内存方面管理。

前进的计划是不接受ARC用于即将推出的macOS 64位平台（因此所有桌面平台都将保留在非ARC模型上）并且将来也禁用ARC用于移动平台（很可能是在10.3）之后的下一个主要版本。请注意，在10.3 Rio中，移动编译器仍然启用了ARC，与10.2完全相同。

现代记忆管理还有什么？

（来源：https：//pixabay.com/photo-1751201/）

我们仍然认为引用计数内存管理是相关的，但我们更愿意利用和扩充Delphi中接口和字符串使用的现有引用计数模型，而不是为它引入新机制。这种情况已经存在了很长时间。如果处理不当，接口引用和对同一对象的对象引用会引起麻烦，但这是大多数Delphi开发人员已经知道如何处理的问题，并且有很多关于该主题的文档。 

最近使用弱引用甚至不安全的引用扩展了接口引用。这些附加选项大大增加了“ARC for interfaces”的功能和灵活性。换句话说，虽然我们要删除ARC以进行对象引用，但是用于接口引用的ARC是已经并将继续可用的语言的一个特性。

除此之外，我们希望改进和简化具有堆栈引用的本地短期对象的生命周期（和内存管理）的管理。这是我们将在10.3中引入的一个非功能，但我们正在积极研究这些功能，并且可以由开发人员利用托管记录（10.3中的新语言功能）部分实现。

包起来

（内存泄漏跟踪变得简单）

虽然我们知道几年前对计划的这种改变可能会令人惊讶并影响现有代码，开发人员对ARC模型不满意，支持不同平台上的多个模型，以及与本机内存管理相比性能损失，很可能会欣赏这个决定。 

提供进一步简化Delphi内存管理的替代方法是在RAD Studio的路线图中，但当前的一组功能（具有引用计数和支持弱和不安全引用，组件所有权模型和标准通用实践的接口）已经提供了一个很好的框架减少Delphi开发人员对手动内存管理的担忧。

最终，编程语言中没有完美的内存管理解决方案，因为自动编程语言有其缺点，而手动编程语言（手动）也是如此。德尔福在过去一直保持着良好的平衡，这种平衡今天仍在继续，并且将来只会有所改善。