我是乙個學過一點c++語言的人。在c++中，沒有自動記憶體管理，卻有很多可以值得借鑑的思路。
我認為乙個記憶體，申請了，卻不用，然後，不用了，卻不釋放，都是一種資源浪費，而不是說，程式最終都會在某乙個時刻**釋放就叫防止記憶體洩漏了。就算有一小部分記憶體我是永遠都用不上，洩露了，而相對有大部分記憶體不能好好利用上，那個更加不合理？因此，記憶體洩露是很廣義的，程式應該協調好，提高記憶體利用才是正道。
.net框架的記憶體管理問題，在於對釋放點的不確定，巨集觀的管理有時候是好的，但是程式往往有區域性性，對細顆粒的控制往往是穩定性和效能的關鍵。至於如何提高這些記憶體的利用率，我覺得還是c++那套實在，什麼時候用，什麼時候申請，什麼時候不用，什麼時候釋放。
在函式的的變數，是在棧中申請的，會在函式結束後，完成釋放。這是乙個記憶體管理的典範。
而建立在堆上的動態申請的記憶體，才是萬惡的根源。當然，動態記憶體是有很多使用價值的。c++的做法是利用類的機制，建立的時候申請記憶體，消亡的時候釋放記憶體，非常有效。雖然預設是手工實現，但是也能使用點技術手段達到自動管理。
真正的問題在於類的物件成員。物件成員可以指向自身，也可以指向另乙個物件，那個物件又有物件成員指向出發物件，等等而形成乙個迴路。
因此，總結導致複雜性的問題根源在於：
1.物件（如.net 的類例項，而不是結構例項）
2.物件的物件成員
3.物件的物件成員的類延伸出去，最終在某個類有相容出發型別的成員物件。
這些是必要而不是充分的條件。但是從這些條件，改進編譯器，讓其識別出來，也能夠簡化不少情況的處理。
然後讓我們直面慘淡的物件迴路問題吧。
物件迴路在結構上來說，類似有多個根節點，然後加乙個有向網路，網路節點可能還有一些沒有迴路的枝葉。
釋放的條件是：
1.根節點等於0整個結構釋放
2.任意一節點的引用計數等於0，釋放該節點和減少後繼結點計數
記憶體管理的思考方式
首先看到 引用計數 這個詞，我們會不自覺想到 某處有某物多少 而將注意力放到計數上。但是更加正確的思考方式是 objective c記憶體管理中的alloc retain release dealloc方法分別是nsbject類的alloc類方法 retain例項方法 release例項方法 dea...
技術管理思考
其實技術團隊大家都很聰明，很多人認為他自己肯定比你更聰明，技術更好，那麼大家為什麼要聽你管理呢？自己的經驗是，首先為大家開好頭，其次過程中要為大家掃清細碎的事情，最後並結好尾巴。總之是乙個服務員型的角色，同樣自己也要做專案當廚師的角色，這樣就能不離開團隊，和團隊一起戰鬥。這樣的壞處就是要為這個專案操...
對Linux記憶體管理的思考
經典！看了對低端物理記憶體和高3 核心的虛擬記憶體被連續對映到最低端的物理記憶體。這是所有問題的開始。為什麼要把核心的虛擬位址空間連續地對映到物理記憶體最低端？這個根本不是個問題。開發人員或是出於效率的原因或是出於實現的原因，就是做了這樣的設計。但這種設計卻引發了很多令人困惑的問題。假設我們使用32...