哪些編程習慣會導致內存泄漏？

01-13

看到 @kubisoft 的答案，必須反對一下。

內存泄漏、線程安全和大尺度上的系統性能，都是通過規劃設計決定的。通過什麼方式管理生命周期如果在寫代碼之前和期間沒有全局的安排，後期去隨機修復基本是不可能的。@vczh 的 RAII 自動管理是一種方案；手工管理也不是不可以，但每個對象的生命周期，誰負責管理誰只是訪問，基本應該是一目了然的。

所以，回到題目中：「哪些編程習慣會導致內存泄露？」

對內存 / 對象生命周期沒有統籌設計，隨機處置的必然結果之一就是內存泄漏。

堅持人肉delete

堅持使用C/C++。

對於自己過於自信，是導致內存泄露的主要原因

沒有編程情懷

不用valgrind

貼兩個Android開發中常見的錯誤，分別是Handler Leak和Context Leak。

這兩種均是很常見的寫法，存在於絕大多數Android代碼中，很多程序員都習慣於這樣去寫而並不知道潛在的問題。

瀉藥。

內存泄漏這種問題，已經超出了人類的智力，靠狹義的編程習慣是解決不了的。再怎麼注意編程習慣，難免有遺漏的地方，很可能你刻意去避免內存泄漏，多花了幾倍的編碼時間，只省下來幾十k的內存，卻被你一個不小心就漏了100m，全毀了。

我的觀點比較激進。寫代碼的時候最好不要考慮這類問題，但是必須跑工具去檢測內存泄漏。一旦發現，就在對應的地方加上防止泄漏的代碼，然後反覆檢測。當做bug來調試。

－－－－－－－－－－－－－－－－－－

監測泄漏有各種工具啊，c++有memchecker之類的東西，xcode有instrument工具箱。

檢測泄漏的同時要注意代碼覆蓋率，有的代碼根本沒被執行過，發生泄漏就在所難免。代碼覆蓋率也需要採用相關工具來檢測。

如果不是跑個一兩個月不停機的伺服器，不用那麼介意內存泄漏問題。

把new出來的指針傳給別的類，到處存，而且還不用智能指針

一般內存泄露比較容易存在於c/c++的編程中

我就說說一些c/c++里避免內存泄露的習慣吧

一、資源申請釋放對稱

二、其他條件準備好在進行資源申請

三、對於複雜的資源申請釋放封裝成函數

四、資源釋放後將變數置為無效

五、盡量一次性申請一次性釋放（動態資源用在for里時最好把申請放在for外面，然後一次性釋放）

六、內存引用計數為0一定要釋放

七、運用一些工具：Valgrind Yourkit Scitech

此外業內常用的智能指針 unique_ptr 和 shared_ptr

1.太自信

2.太信隊友

只要是手動管理內存，泄露幾乎不可避免

強循環引用

良好的內存使用習慣，自己創建的內存記得刪除。

監控程序長時間運行的內存量使用。

不用ARC，濫用block，不懂引用計數。。。

iOS編程菜菜路過

new/malloc 沒有釋放，一般容易出現非代碼尾部return，break的地方。

個人覺得內存越界的情況出現更多，而且自己很難發現。

在用C語言編程的時候，代碼裡面還用了類似java的異常機制，程序可以拋出異常，一不小心就內存泄露

不論是自動的，還是人為的。都可能存在泄漏，只是自動的，是你認為它是「安全的」，畢竟連這個所謂的安全也是人寫的。。。所以，個人人為：造成泄漏最主要的原因是正在開發的人員本身不具有高強度的「內存安全」意識。再加上檢測工具，上一道保險而已。

打開的文件沒有關閉，網路連接沒有關閉，也可能導致。

好的做法是在哪裡申請的，在哪裡釋放。

很多人表示內存泄漏是由於使用了需要手動管理內存的編程語言，如c/c++。我覺得，這不是廢話嗎？你用個自動管理內存的語言，還談什麼內存泄漏？

我覺得內存泄漏的根本原因還是對內存理解不透。理解透了，不會有內存泄漏問題。

內存泄漏在各個語言里幾乎都會存在，然而一些語言做了相應的內存管理，如JVM，會自動去掃那些沒有任何引用的heap里的object，然而JAVA也是會有內存泄漏的情況存在，比如說單例模式里,一個public class 里存在一個public static Object object = new AnotherClass(); 那這個object就會一直存在, 伴隨著內存泄漏的產生

開闢一些內存空間，生成一個object，並去引用他，即使不用了，還保持這這個引用，就會存在內存泄漏的現象。因此，編程過程中，應當適時的進行空間的釋放

一直New。。。。不釋放。。

像JVM這種自動處理垃圾的仍然會有泄露出現，可見編碼時應該注意對象，變數生命周期的把控。同時加強監控，可以通過Jstats，dump等手段監控內存