引用计数 vs. GC

内存管理问题

内存管理是编程过程中的一个经典问题，早期在 C 语言时代，几乎都靠 malloc/free 手动管理内存。随着各个平台的发展，到现在被广泛采用的主要有两个方法：

引用计数 (ARC，Automatic Reference Counting)
GC (Garbage Collection)

管理方法 ARC/GC

因为 Java 的流行，GC 被广泛的认知。GC 简单的说是定期查找不再使用的对象，释放对象占用的内存。

基于 GC，申请的对象不需要手动释放，只需要确认对象在不再需要时，不再被其他对象引用。

引用计数早期主要用于底层系统，比如文件系统的 inode 管理，后来 C++ 的 boost 库实现了一套完整的 ARC，目前流行的系统还有 Objective C 也是采用的 ARC。

ARC 的特点是，一个对象被引用时，引用计数增加 1，引用对象释放时，引用计数减少 1，如果引用计数为 0，释放对象。

比较

因为 ARC 和 GC 的不同策略，对编程的几个方面的影响。

性能

GC 需要一套额外的系统跟踪分配的内存，分析哪些内存需要释放，相对来说就需要更多的计算。这也是为什么对性能敏感的场景不采用 GC 的原因，比如，高性能的服务端程序，资源有限的嵌入式设备（iOS 就没有采用 GC）。

ARC 由开发者自己来管理资源在什么时候释放，不需要额外的资源，所以性能没有损失。

延迟

GC 回收内存时，需要完全暂停当前程序，这会给程序带来难以预测的一个延迟期。如果需要回收的资源很多，这个延迟可能会非常大。

ARC 在资源引用为 0 时立即释放，没有不可预测的延迟。

编程难度

不难看出，GC 在性能、延迟等方面有明显的缺点，为什么 GC 还会被广泛采用呢？

GC 带来的最大好处是不需要开发者手动管理内存分配，这大大降低了编程难度，同时可以大幅减少跟内存管理相关的 Bug：

悬空指针。指针指向的内存被其他代码释放
重复释放内存
内存泄漏。申请的内存没释放

不过使用 GC 并不代表可以完全不用理解内存管理，如果对象的引用关系跟想象的不一致，GC 也会有内存泄漏的问题。

我们之前理解的内存泄漏 是指一个分配的内存没有被释放造成的。而 GC 平台下的内存泄漏是指对象有引用而开发者不知道，比如：

ObjectA -> ObjectB

ObjectB 使用完后，我们没有及时把 ObjectA 引用 ObjectB 的指针设置为 NULL，这时， ObjectB 不会被 GC 回收。

对比表格

	时机	性能	延迟	编程难度
ARC	引用计数为 0 马上回收	快	小	较大
GC	定时扫描清理	慢	大	较小

怎么选择 ARC or GC

开发一个项目时，采用什么样的平台，跟实际面对的场景有很大关系，没有一个技术是用来解决所有问题的。

一般来说，对延迟和性能不敏感的系统，可以考虑带 GC 的平台，比如 Java、Go 等来开发，通常可以提高开发效率。

如果需要对系统的性能有良好的控制，或者平台的资源有限，ARC 是更好的选择。比如操作系统、数据库等选择 C 或者 C++。比如 iOS 的 Objective C 就是采用 ARC，实际来看比使用 Java (GC) 的 Android 平台的表现要好太多。

但是 ARC 平台一般对开发者要求要更高。

最近出现的新语言 Rust 采用的是 ARC，但是 Rust 会在代码编译阶段对内存、指针的使用做严格的分析和检查，确保程序没有内存管理问题。相当于把 GC 的一部分工作移到编译阶段，这样程序的运行性能几乎没有损失，同时又大大减少内存管理相关的 Bug。

我的观察从 C++11 正式吸纳 boost 的 smart pointer 后，C++ 在内存管理方面比之前有极大的提升，如果严格的按照 smart pointer 的规范，同样可以减少内存管理的风险。Rust 就有点像一个严格的 C++11 编译系统。

支持 GC 的平台里面有一个特殊的，就是 Erlang。Erlang 的 GC 是进程级别的(Erlang 的轻量级进程），意味着 GC 发生时，只暂停当前进程，其他进程不受影响。另外，Erlang 程序往往会运行海量的进程，相当于把 GC 分散开了，所以 Erlang 的 GC 一般不会产生明显的延迟。

了解这些细节，在面对具体问题时，能帮你做出正确的选择。

欢迎来微博留下您的意见：http://weibo.com/2255454164/E48lBE9pU