引用计数怎么到你那里就变成 gc 了？上个世纪在 gc 出来之前 reference counting 就在用了，比如早期的 delphi、win com，对循环引用的处理方式就是不处理。

为了解决循环引用问题，有两种方案，一种是 weak reference，说白了还是不处理；另外一种才是用 gc 来解决。而在实践中如果一门语言高度依赖 reference counting，那么基本上都是不处理的，换句话说由程序员负责 weak reference，写错了就泄露。

道理很简单，引用计数的 overhead 非常高。而 gc 的问题只是发生回收时的高延迟，它本身不破坏执行流水过程，不破坏 cpu cache，反倒提高了不发生回收时的运行速度。所以在实践中 gc 跟 reference counting 是对立的概念，如果说有 gc，那不大可能是基于引用计数实现的，反过来如果说用了 arc，那大概率就得你自己管 weak reference。

回过头来看 rust
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

大标题 Reference Cycles Can Leak Memory
第一段最后：it’s possible to create references where items refer to each other in a cycle. This creates memory leaks because the reference count of each item in the cycle will never reach 0, and the values will never be dropped.

再往下几段：Preventing Reference Cycles: Turning an Rc<T> into a Weak<T>
跟我说的一样，自己管 weak reference，管不明白就内存泄露。

我不了解 c++ 怎么做的，也许标准库自带一个 gc。但我的理解，如果用了 weak_ptr，那就是编译器不管，而且也不会额外再带个 gc runtime 出来

换句话说，rust 默认行为是不管循环引用的。所以针对你的最后一个问题，rust 的标准库做法很明确：没有 gc，直接 leak

【 在 Knightmare (梦醒时分) 的大作中提到: 】
: gc不包含引用计数才是你自己发明的逻辑。
: 损失性能你的逻辑也根本不对，是否损失性能是要有参照物才行的，与合理的手动管理
: 内存或者rust语法中包含的ownership+scope相比，rc与arc就是会有性能损失，这个性能
: ...................
--
修改:eGust FROM 115.188.151.*
FROM 115.188.151.*

【 在 Knightmare (梦醒时分) 的大作中提到: 】
: 标  题: Re: Rust语言有没有希望？
: 发信站: 水木社区 (Wed Feb 12 16:55:21 2020), 站内
:
: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting
:
: Reference counting[edit]
: Main article: Reference counting
: Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero. An object's reference count is incremented when a reference to it is created, and decremented when a reference is destroyed. When the count reaches zero, the object's memory is reclaimed.[6]
这不就是我说的么，计数为0的标记为垃圾，完全是 gc 的策略。delphi 里当引用计数降到0，直接就调用 destructor、释放内存，根本就不存在一个 gc。

:
: As with manual memory management, and unlike tracing garbage collection, reference counting guarantees that objects are destroyed as soon as their last reference is destroyed, and usually only accesses memory which is either in CPU caches, in objects to be freed, or directly pointed by those, and thus tends to not have significant negative side effects on CPU cache and virtual memory operation.
从这段话开始，都是在说使用 reference counting 策略的 gc 的缺点。这也是我前面说过的，reference counting 有很高的 overhead，所以正常情况下没人用这种策略来设计 gc；反过来如果用了 reference counting，那么大概率是用 weak reference 来解决循环引用的问题，实际上就是不管——用错了就内存泄露，没有 gc 给你接着

:
: 【 在 eGust (十年) 的大作中提到: 】
: : 标  题: Re: Rust语言有没有希望？
: : 发信站: 水木社区 (Wed Feb 12 15:45:15 2020), 站内
: :
: : 你的定义更麻烦，我的标准很简单，有没有 garbage collector
: :
: : 根据 wiki 条目
: : https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
: :
: : 条目下面有4种常见策略，其中第一条的独立条目
: : https://en.wikipedia.org/wiki/Tracing_garbage_collection
: : Tracing garbage collection is the most common type of garbage collection – so much so that "garbage collection" often refers to tracing garbage collection, rather than other methods such as reference counting – and there are a large number of algorithms used in implementation.
: :
: : 虽然基于 reference counting 策略的 gc 带了 reference counting 字样，但并不是只要提到了 reference counting 就是 gc。比如 arc，到0了就直接释放，而不是等内存不够了，gc 才开始工作，引用计数为0的是标记为可以安全释放的对象
: :
: : 【 在 ilovecpp (cpp) 的大作中提到: 】
: : : 你们越说越复杂（且不正确）了。
: : : 一般对语言是否有gc的概念很简单：
: : : 缺省所有内存都自动回收，也许可以显式分配不自动回收的内存(opt-out)：语言有gc。
: : : ...................
: :
: : --
: :
: : ※ 来源:·水木社区 newsmth.net·[FROM: 115.188.151.*]
:
:
: --
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 39.114.185.*]
--
FROM 115.188.151.*

我不了解，但是估计应该都有现成的工具吧

当年 delphi 下我自己都实现过类似的东西，给内存管理器包了一层，等退出的时候如果有没释放的内存，直接把申请时的调用栈打印出来

探知循环引用的技术很成熟，如果是使用 arc 的语言，ref counter 对象中的偏移量应该都是常数值（比如-8），难点就只在猜那些地址是对其它对象的 reference。但如果语言本身支持反射的话，那就完全没有技术难度了

不过不管怎么弄，引用计数总是有非常大的额外开销，实际上性能要比用 gc 的差很多。但是像 ui 这种单线程、对延迟敏感、性能不敏感的场景来说，arc 还是有意义的

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 是否有什么办法让编译器探测出在哪些情况下会产生循环引用，然后给程序员报错，让程序员主动选择 Weak Reference?
: 这样子既可以避免出错，也可以更即时地销毁资源。
: 另外，我觉得内存管理与资源管理应该分开。引用计数为0的时候必须调用析构函数。但是调用释放内存的函数却非必要。这两件事情分开在某些场景下或许可以提升性能。
: ...................
--
修改:eGust FROM 115.188.151.*
FROM 115.188.151.*