Gc 是一种失败的内存管理模式


#64

多谢指点! 我们还是回到正题上来,这个帖子要讨论的是"内存管理方式",然后给个"成功/失败的判断"。 内存管理无法两种方式:

  • 手动:(RAII,Reference Count)

  • GC

  • 基于手动管理的方式,会有内存泄漏,但是这种内存泄漏是可以根治的

  • 基于GC的管理方式,会让开发者从内存管理中部分解脱出来,但是GC背后带来的“运行中断”,“内存峰值”都是巨大的隐患,而且这种隐患一直都在,无法根治

如果这个角度来看,基于GC的内存管理肯定是失败的。


#65

我们从来都接受水平质疑。

只要你能提出更好的东西, 发表出更好的文章来。

既然你的代码公布不了, 我们按照学术界的传统, 以发表的论文论英雄。

目前我已经发表的讲座很多, 你要是继续质疑, 可以发表更多更好的。 让大家知道并判断你的水平。


#66

我说的很清楚。在你在乎的时候是失败的。C++程序员选择C++就是因为他们在乎。但是很多场景并不在乎。平时GC一下就GC一下了,不会怎么样;但如果时间长了leak内存,然后down了,就坏了。我能够理解C++程序员不会有这种场景。


#67

那真不好意思了, 因为你一直在说 GC 很好, 智能指针不好, 再加上你需要我在回帖里提醒你对文章主题的理解有问题 -》 很自然的得出你的水平可能真的不行。

不想被人误解的话, 真的需要下大功夫。


#68

我自认为我只有批评 GC 烂 的水平, 还没有足够的水平好好的教大家如何用好智能指针。 你无非是想我批评了 GC 的同时再好好的讨论智能指针, 把智能指针的优缺点都意义列举, 好好的讨论如何避免缺陷。

在我的回帖里, 我已经明确的表示, 不行。 不可能。 那需要另外的文章, 好好的讨论。 显然目前我还没有做好足够的准备。

按照你爱给忠告的性格特点, 如果你知道, 还麻烦你另开一个帖子好好的交代智能指针。届时我也会修改帖子指向你的讨论贴


#69

我一直在说GC好的地方和不work的地方。shared_ptr好的地方你说了,我只说不好的地方。我对你文章里隐藏shared_ptr不好的地方不满

你说你需要“不行,不可能””需要另外的文章“那你最好注解上。我对你的强烈不满是:隐藏不好的地方。

顺便很可惜,我可能真的不接受在这种地方“水平质疑”。我比较傲慢无礼。对不起。


#70

说句偷懒的话, 我隐藏是因为我不知道。 如果你知道, 可以指出来。

但是不要三言两语就指出来。 我知道这是不可能的。 试图几句话就指出来只能是又一种形式的误导。

这比不指出来还要可怕。


#71

是这样的,脱离了具体的场景来谈好坏意义不大。如果把GC与手动管理结合起来就比较有趣了,类似于iOS平台中的ARC机制,既可以将开发者从内存管理中解脱出来,产生类似于GC的便利,又可以通过在编译时期将ARC代码转换成近似于手动的内存管理,从而避免了运行时的GC存在,在iOS5中这种机制已经存在,应该是GC与非GC机制的一种折衷


#72

Python。所有Python对象都有reference count。但是还是有个mark and compact的GC


#73

我的建议是点击论坛边上的 “回复为新帖子” 好好的阐述你对 智能指针的理解。

这要比在下面回帖, 试图三言两语指出来 shared_ptr 的坏处要好的多。 至少不会形成 “小马过河” 式的误导。

我之所以选择这个论坛, 就是它特别适合这种发散性的讨论, 并且维持住主题之间的关联性。


#74

用不着

看3楼。


#75

refcount应该是GC的核心机制,如果把GC尽可能的简化,无非就是两个操作:

  • 处理对象之间构造,拷贝,引用时的refcount变化
  • 定时去扫描所有对象的refcount,如果refcount == 0则可以release操作

#76

要照顾到这里多数访客都是中国人, 不像你是加拿大华侨。说一口流利的英语。

如果不是这样的话, 大家大可以参加国际上的 cpp 讨论, 何必建立一个中文的。

你这样做是不负责的


#77

呃……你看看楼上的那个链接再说…………………………这个……

reference count其实可以作为辅助信息的……但是很多不用,就是因为我说的在critical path上有atomic operation。……而且generational gc能做的比较快,所以reference count恐怕也不一定是个好的hint……但是很不好说,比如python还是选择了用reference count,因为反正因为懒,用了GIL……


#78

ref = 0 是直接释放的, 无需 GC

GC 的介入是 ref > 0 , 而且还没有的对象。 这需要执行扫描, 找出所有的引用, 然后检查是不是发生了循环引用, 死引用 。。。。。


#79
struct A {
  std::shared_ptr<A> ptr;
};

void main()
{
  std::shared_ptr<A> x=std::make_shared<A>();
  std::shared_ptr<A> y=std::make_shared<A>();

  x->ptr = y; // not quite a cycle yet
  y->ptr = x; // now we got a cycle x keeps y alive and y keeps x alive
}

这样够了吧

x和y的reference count都是1,互相引用互相。


#80

不得不说, 就算是在 php 里, 这样也会导致内存泄露。java 没研究过这样会不会内存泄露。

能写出这样的代码, 基本上可以断定不合格。倒不是因为这个代码会导致循环引用。 不不不, 真不是这样原因。

判断为这个代码不合格的原因很简单: 它没有理解 shared_ptr .


#81

明显任何认真去实现GC的语言都不可能会有内存泄露。


#82

这段代码属于作者自己不懂指针而导致,使用指针一般要明白一个道理就是,对象的所有者。

也就是:

1、如果struct A内有shared_ptr确定ptr是属于struct A的话,那么所有外部引用ptr应该是weak_ptr,而且不应该由外部传递ptr进来。

2、如果struct A内的 ptr是只是引用外部ptr,而不属于struct A本身,则struct A应该内部定义是weak_ptr而不是shared_ptr。

无论是使用shared_ptr或裸指针,own的概念总是存在的,如果没有,那只能说明你在写面条代码。


#83

要你认真讨论, 你要给链接, 让别人自己看英文。

你可不是这样的! 你不是刚刚才列举了几个 shared-ptr 的缺点了么?

怎么, 一到严肃的讨论,你就开溜了, 发一个英文的了事?。