C語言有沒有什么垃圾回收的庫

shan_ghost

cuusrname 發(fā)表于 2014-03-12 15:55
如果用c做的東西不大，不復雜，用GC就沒有太大的意義。

不過，反過來說，網景瀏覽器的作者曾經說過：jav ...

跳大神少說也有7000年歷史了，有些人是否應該認真對待它呢？


沒有人說GC沒用。

但，作為一個有追求的死碼農，對某些吹的華里胡哨，實則@#￥@#￥%的技術保持警惕，難道不應該是最基本的素質嗎？

嗯，我說的就是某些吹起牛來信誓旦旦“能控制到1ms之內”、實則還沒摳電池重啟快的嘴炮技術。


當然，哪怕還不如摳電池好用，但這個技術畢竟能有效的降低軟件開發(fā)的入門門檻，使得諸多身殘志堅的好后生得以園自己的碼農夢（咦？這段話咋這么耳熟？），功勞還是大大地～～


不過呢，對我們這些老家伙來說，任何一個邏輯肯定都是有頭有尾的，任何一個算法都是局部的，任何一個程序都可拆分為一個個細小局部，然后再整合而成的。

所以呢，只要處理好每個局部的生與死——并且做到誰欠債誰還帳，堅決抵制楊白勞的帳用喜兒來還的封建遺毒——那么，每個局部的資源（注意是資源，資源包括但不限于內存；甚至連邏輯鎖、flag、狀態(tài)都可泛泛歸于資源）都可以在內部完美管理起來：有頭，有尾；有生，有死。

資源——內存只是資源的一種——的管理，在這個過程中，已經自然被解決。

所以，管理內存，從來都不是什么難事。真正難的是，究竟怎樣把一個紛繁復雜的大項目，拆分成一個個各自無關的局部算法，把它變成模塊級的小項目、然后再把每個模塊變成函數級的小項目、再把一個個函數這類語句級的小項目寫出來。



反之，連個內存都不知道怎么處理，程序中那么多的狀態(tài)如何搞得定？
內存你不打算管，那我一宗交易鎖了數據庫，你打算不打算解開？要不要搞個“鎖回收”來幫你搞？
嗯，鎖總歸還是只有兩種狀態(tài)（讀寫鎖別亂叫，懶得理你），那要是一個系統(tǒng)有十幾種狀態(tài)來回遷移，我不信你還能到哪找個“狀態(tài)回收”庫。

總之呢，偷懶就是偷懶，沒追求就是沒追求，嘴炮就是嘴炮，別裝的那么高大上。

shan_ghost

說起資源，想起前些天幫同學處理過的一個問題了……

一個醫(yī)院用的管理系統(tǒng)，大概每天也就數百宗交易的樣子。剛開始還行，用了幾個月后，當5、6個終端機同時操作時，死鎖了。此時數據庫會卡死十幾分鐘，直到數據庫死鎖檢測程序發(fā)現死鎖，強制殺掉幾個事務……

這種狀況出現的頻率越來越高，從幾天一次，到每天幾次……這位坐不住了，發(fā)截圖問我怎么回事。
還能怎么回事，提示框寫的清清楚楚，死鎖。誰寫的軟件找誰，搞不定重寫，愿意給錢我可以幫他重寫。


結果是： 經過N天扯皮，無數次“數據庫調優(yōu)”無法解決后，人家買了一臺新的16 CPU的數據庫服務器。
當然，邏輯問題不解決，只能是一切照舊。

——傻瓜機是很好……但我們是專業(yè)人員呢。

cuusrname

回復 31# shan_ghost


    你舉的是什么例子？
    鎖出現的頻率和內存申請的是一個數量級嗎？ 開一個小時車你能保證不出錯，10萬個小時呢？
    嘴炮你可以跟云風打。
   

shan_ghost

cuusrname 發(fā)表于 2014-03-12 18:05
回復 31# shan_ghost

1、內存分配有狀態(tài)改變出現的數量級高？

2、在很多行業(yè)，鎖出現的頻率比內存分配多得多得多。

3、云風說的是，使用gc是一種設計選擇，不是偷懶。
比如對象生命期未知這種情況下，使用gc能簡化算法。但一旦對象生命期明確，那么立即釋放/內存池就是最優(yōu)策略。

連別人的話都看不懂……

cuusrname

shan_ghost 發(fā)表于 2014-03-12 18:48
1、內存分配有狀態(tài)改變出現的數量級高？

2、在很多行業(yè)，鎖出現的頻率比內存分配多得多得多。

3、云風說的是，使用gc是一種設計選擇，不是偷懶。
比如對象生命期未知這種情況下，使用gc能簡化算法。但一旦對象生命期明確，那么立即釋放/內存池就是最優(yōu)策略。

“2、在很多行業(yè)，鎖出現的頻率比內存分配多得多得多�！� 這個你說的對，我前一個回復考慮不周。
但“內存狀態(tài)改變”不一定要鎖，這個不可比。

“使用gc是一種設計選擇”也沒錯。
java那樣必須用GC，或者C這樣沒有一個可靠的GC，都不理想。
最好GC是可選項：
在你精心設計時，GC可以幫你查漏補缺。
條件許可時，想不考慮內存分配也可以，畢竟人的精力有限。

hellioncu

“智能”、“自動”的東西并只能適應某些場景，很多時候不是最佳選擇，反而把問題搞復雜了，不可控，用C開發(fā)的項目往往是希望可控

cuusrname

可選的GC不是更可控了嗎？

shan_ghost

cuusrname 發(fā)表于 2014-03-12 19:53
但“內存狀態(tài)改變”不一定要鎖，這個不可比。

我說的是“狀態(tài)改變”，不是“內存狀態(tài)改變”。


比如一筆交易，進入購物車是一個狀態(tài)，進入支付流程又是一個狀態(tài)，支付成功又是一個狀態(tài)，發(fā)貨又是一個狀態(tài)……

再比如，用戶登錄，未登錄是一個狀態(tài)、認證失敗又是一個狀態(tài)、多次認證失敗導致帳號重試間隔出現又是一個狀態(tài)、帳號鎖定又是一個狀態(tài)……當然，登錄成功、解鎖成功又是個狀態(tài)。


這類狀態(tài)其實比內存分配復雜的多，但同樣必須維護好。

事實上，絕大多數時候，內存分配是狀態(tài)相關的。如果你能把狀態(tài)維護好，那么內存分配必然已經伴隨著狀態(tài)維護被自然解決了。

如果承認前一句話，那么這句話就是順理成章的： （除了忘記free之類低級錯誤）內存泄漏實質上并不是內存管理的問題，而是整個系統(tǒng)狀態(tài)不清、耦合過重（耦合過重就導致代碼中時時處處都在維護狀態(tài)）的問題。

總之，內存管理是一個問題，但絕不是大的無法直視的問題。事實上，合格的設計方案中，它的成本往往只是狀態(tài)維護成本的零頭而已。
狀態(tài)沒控制好，內存管理的成本才會凸顯；狀態(tài)越亂、越沒有經過認真分析，內存管理也就越難。



當然，某些系統(tǒng)的確會出現難以控制的、不確切的狀態(tài)。比如云風提到的無鎖數據結構之類場景，因為操作之后狀態(tài)無法確定、所以需要等狀態(tài)確定后才能執(zhí)行內存釋放操作。而“等狀態(tài)確定”是一個極其復雜、困難的操作；用gc方案就繞開了這個技術難點。


但，另一方面，無鎖數據結構是為了極限挖掘性能；拉進來個gc能否保證性能不受損害呢？尤其是對java那種動輒鎖死一切且持續(xù)幾分鐘的情形，顯然是得不償失的。


當然，java的問題是“用gc來偷懶”，于是不僅未得其利，反而導致用戶不得不頻頻采用摳電池這個更優(yōu)方案。

Hugo801122

應該沒有，需要程序員自己做好內存管理，這是難點也是靈活的地方。Java所為垃圾機制，效率很低。

cuusrname

回復 38# shan_ghost


內存管理和業(yè)務代碼放在一起也是一種耦合。
“忘記free之類低級錯誤”有時候是很害人的，這種東西有時候少寫一個，再找這個Bug就費勁了。

gc的性能未必很低，你舉的例子可能條件特殊。
我在前面發(fā)的鏈接里，有個例子是虛幻游戲引擎也用了gc。