C语言有没有什么垃圾回收的库

shan_ghost

cuusrname 发表于 2014-03-12 15:55
如果用c做的东西不大，不复杂，用GC就没有太大的意义。

不过，反过来说，网景浏览器的作者曾经说过：jav ...

跳大神少说也有7000年历史了，有些人是否应该认真对待它呢？


没有人说GC没用。

但，作为一个有追求的死码农，对某些吹的华里胡哨，实则@#￥@#￥%的技术保持警惕，难道不应该是最基本的素质吗？

嗯，我说的就是某些吹起牛来信誓旦旦“能控制到1ms之内”、实则还没抠电池重启快的嘴炮技术。


当然，哪怕还不如抠电池好用，但这个技术毕竟能有效的降低软件开发的入门门槛，使得诸多身残志坚的好后生得以园自己的码农梦（咦？这段话咋这么耳熟？），功劳还是大大地～～


不过呢，对我们这些老家伙来说，任何一个逻辑肯定都是有头有尾的，任何一个算法都是局部的，任何一个程序都可拆分为一个个细小局部，然后再整合而成的。

所以呢，只要处理好每个局部的生与死——并且做到谁欠债谁还帐，坚决抵制杨白劳的帐用喜儿来还的封建遗毒——那么，每个局部的资源（注意是资源，资源包括但不限于内存；甚至连逻辑锁、flag、状态都可泛泛归于资源）都可以在内部完美管理起来：有头，有尾；有生，有死。

资源——内存只是资源的一种——的管理，在这个过程中，已经自然被解决。

所以，管理内存，从来都不是什么难事。真正难的是，究竟怎样把一个纷繁复杂的大项目，拆分成一个个各自无关的局部算法，把它变成模块级的小项目、然后再把每个模块变成函数级的小项目、再把一个个函数这类语句级的小项目写出来。



反之，连个内存都不知道怎么处理，程序中那么多的状态如何搞得定？
内存你不打算管，那我一宗交易锁了数据库，你打算不打算解开？要不要搞个“锁回收”来帮你搞？
嗯，锁总归还是只有两种状态（读写锁别乱叫，懒得理你），那要是一个系统有十几种状态来回迁移，我不信你还能到哪找个“状态回收”库。

总之呢，偷懒就是偷懒，没追求就是没追求，嘴炮就是嘴炮，别装的那么高大上。

shan_ghost

说起资源，想起前些天帮同学处理过的一个问题了……

一个医院用的管理系统，大概每天也就数百宗交易的样子。刚开始还行，用了几个月后，当5、6个终端机同时操作时，死锁了。此时数据库会卡死十几分钟，直到数据库死锁检测程序发现死锁，强制杀掉几个事务……

这种状况出现的频率越来越高，从几天一次，到每天几次……这位坐不住了，发截图问我怎么回事。
还能怎么回事，提示框写的清清楚楚，死锁。谁写的软件找谁，搞不定重写，愿意给钱我可以帮他重写。


结果是： 经过N天扯皮，无数次“数据库调优”无法解决后，人家买了一台新的16 CPU的数据库服务器。
当然，逻辑问题不解决，只能是一切照旧。

——傻瓜机是很好……但我们是专业人员呢。

cuusrname

回复 31# shan_ghost


    你举的是什么例子？
    锁出现的频率和内存申请的是一个数量级吗？ 开一个小时车你能保证不出错，10万个小时呢？
    嘴炮你可以跟云风打。
   

shan_ghost

cuusrname 发表于 2014-03-12 18:05
回复 31# shan_ghost

1、内存分配有状态改变出现的数量级高？

2、在很多行业，锁出现的频率比内存分配多得多得多。

3、云风说的是，使用gc是一种设计选择，不是偷懒。
比如对象生命期未知这种情况下，使用gc能简化算法。但一旦对象生命期明确，那么立即释放/内存池就是最优策略。

连别人的话都看不懂……

cuusrname

shan_ghost 发表于 2014-03-12 18:48
1、内存分配有状态改变出现的数量级高？

2、在很多行业，锁出现的频率比内存分配多得多得多。

3、云风说的是，使用gc是一种设计选择，不是偷懒。
比如对象生命期未知这种情况下，使用gc能简化算法。但一旦对象生命期明确，那么立即释放/内存池就是最优策略。

“2、在很多行业，锁出现的频率比内存分配多得多得多。” 这个你说的对，我前一个回复考虑不周。
但“内存状态改变”不一定要锁，这个不可比。

“使用gc是一种设计选择”也没错。
java那样必须用GC，或者C这样没有一个可靠的GC，都不理想。
最好GC是可选项：
在你精心设计时，GC可以帮你查漏补缺。
条件许可时，想不考虑内存分配也可以，毕竟人的精力有限。

hellioncu

“智能”、“自动”的东西并只能适应某些场景，很多时候不是最佳选择，反而把问题搞复杂了，不可控，用C开发的项目往往是希望可控

cuusrname

可选的GC不是更可控了吗？

shan_ghost

cuusrname 发表于 2014-03-12 19:53
但“内存状态改变”不一定要锁，这个不可比。

我说的是“状态改变”，不是“内存状态改变”。


比如一笔交易，进入购物车是一个状态，进入支付流程又是一个状态，支付成功又是一个状态，发货又是一个状态……

再比如，用户登录，未登录是一个状态、认证失败又是一个状态、多次认证失败导致帐号重试间隔出现又是一个状态、帐号锁定又是一个状态……当然，登录成功、解锁成功又是个状态。


这类状态其实比内存分配复杂的多，但同样必须维护好。

事实上，绝大多数时候，内存分配是状态相关的。如果你能把状态维护好，那么内存分配必然已经伴随着状态维护被自然解决了。

如果承认前一句话，那么这句话就是顺理成章的： （除了忘记free之类低级错误）内存泄漏实质上并不是内存管理的问题，而是整个系统状态不清、耦合过重（耦合过重就导致代码中时时处处都在维护状态）的问题。

总之，内存管理是一个问题，但绝不是大的无法直视的问题。事实上，合格的设计方案中，它的成本往往只是状态维护成本的零头而已。
状态没控制好，内存管理的成本才会凸显；状态越乱、越没有经过认真分析，内存管理也就越难。



当然，某些系统的确会出现难以控制的、不确切的状态。比如云风提到的无锁数据结构之类场景，因为操作之后状态无法确定、所以需要等状态确定后才能执行内存释放操作。而“等状态确定”是一个极其复杂、困难的操作；用gc方案就绕开了这个技术难点。


但，另一方面，无锁数据结构是为了极限挖掘性能；拉进来个gc能否保证性能不受损害呢？尤其是对java那种动辄锁死一切且持续几分钟的情形，显然是得不偿失的。


当然，java的问题是“用gc来偷懒”，于是不仅未得其利，反而导致用户不得不频频采用抠电池这个更优方案。

Hugo801122

应该没有，需要程序员自己做好内存管理，这是难点也是灵活的地方。Java所为垃圾机制，效率很低。

cuusrname

回复 38# shan_ghost


内存管理和业务代码放在一起也是一种耦合。
“忘记free之类低级错误”有时候是很害人的，这种东西有时候少写一个，再找这个Bug就费劲了。

gc的性能未必很低，你举的例子可能条件特殊。
我在前面发的链接里，有个例子是虚幻游戏引擎也用了gc。