关于 ARC 和 GC 两种不同内存回收方式

[yunbaIO]

#云巴技术干货#

分享一篇我司 CEO 大大 @Tiger_张虎 撰写的关于 ARC 和 GC 两种不同内存回收方式的文章。

原链接戳： http://zhang.hu/arc-vs-gc/

[owt5008137]

很多细节解释得有问题，排版不错

[allenforrest]

说实话我看到 「 Object C 」 我就关掉页面了，过了一会儿，想想还是要尊重一下，继续打开看完了。
觉得写的还不错，但是说实话营养和干货并不多。

[blahgeek]

本来就这样一篇普通的文章的话…虽然没啥干货 不过看看也无妨… 不过还非得强调 CEO 一下子对这个公司和这个人的好感度都降低了…

[shimanooo]

ARC 最关键的环状引用、多线程竞争没说。

[hyyy]

还以为是个技术分享，没想到就这么点东西，干货太少， CEO 三个字母就别发了，影响不好。

[owt5008137]

@shimanooo 这也是我觉得细节有问题的地方之一。

而且 GC 是个宽泛的概念，看这篇文章说得所谓 GC 似乎指的是类似标记删除的方法

[mathgl]

@shimanooo arc 现在一般靠 weak ptr 来解决，不过如果相互关系很复杂，就要把 ownership 考虑得比较细致，实现起来也颇为麻烦。

[FrankHB]

RC 和 tracing GC 都是 1959 年发明的。现在一些 GC 也基于 RC ，但典型 GC 的主要指后者。
想要从大局对比，去掉 A ，谢谢。 ARC 是什么年代的东西了……而且讲真，离“广泛采用”（不是看你用户数，而是看用在多少解决方案里——即便现阶段看用户数也一样）差远了。——然后才发现，文章里讲的似乎就是 RC 而不是 OC/Swift 的那种 ARC 。
（虽然从字面上讲， C++那套才更有资格当成 A 。）

[FrankHB]

@shimanooo @mathgl 影响选取哪种 weak ptr 的 ownership 基本上本来就是应该最晚在详细设计时确定清楚的东西，不应该拖到实现的时候临时添乱。如果最后还发现引用环，说明设计有问题。
GC 实际上是把明确责任也延迟了，所以容易玩脱。
至于竞争，还是一点：注意粒度，避免不必要的可修改共享资源。 RC 也没什么特别的，无非就是更强调考虑造成（伪）共享是不是合适而已。设计时避免不了 aliasing 的那就老实 sharing ，实现后发现瓶颈再考虑是不是改用 GC 或者池来优化。

[canautumn]

Object A, Object B, ObjectC 凑齐了

[hinkal]

arc 概念说的真的对吗， gc 也可以用引用计数的啊

[8bit]

感觉就是一碗稀汤

[snnn]

"支持 GC 的平台里面有一个特殊的，就是 Erlang 。 Erlang 的 GC 是进程级别的，意味着 GC 发生时，只暂停当前进程" 看到这句话我要吐了。知道啥叫进程吗？

[coreS]

理解太表面了，算不上干货

[tigerz]

早听说 V2EX 上面多无脑喷，果然。

指出文章错误的我本人来一一回答一下，无脑喷的自动忽略。

[tigerz]

@allenforrest 笔误已经修改

[tigerz]

@FrankHB ARC 的确是比较新的技术，但从 C++11/Rust 看来是一个很重要的发展方向。
而单纯的 RC 其实很跟 GC 比较起来意义不是太多，编程效率提升非常有限。

[tigerz]

@snnn 你如果懂 Erlang 的进程，就知道我在说什么。 Erlang 的进程是虚拟机上实现的轻量级进程，不同于操作系统的进程。