在Objective-C的ARC狀況下，什麼樣的內存泄漏是沒法避免或者減小的？

以前寫了一個關於__unsafe_unretained特殊標識符講解的翻譯，其中也講到了關於ARC狀況下內存泄漏的問題，這片文章就是對以前問題的一個翻譯講解。

點擊進入StackOverFlow問答頁

1、問題

問題

問題翻譯

在Mac和iOS平臺上，未被釋放的指針常常會致使內存泄漏。傳統狀況下，檢查你的alloc、copy和retain來肯定每一個都有相對應的釋放常常會變得極爲重要。

伴隨着Xcode 4.2到來的數據鏈，介紹了來自於最新一個版本的LLVM編譯器的自動引用計數（ARC），經過讓編譯器對內存進行管理，徹底能夠解決這個問題。這是很是酷的，而且它確實減小了沒必要要的、無用的開發時間，並防止不少不當心的內存泄漏，這些內存泄漏運用適當的保留或者釋放會很容易修復。當你爲Mac和iOS應用啓用ARC時，即便自動釋放池也須要進行不一樣的管理（由於你不該該分配本身的NSAutoreleasePools了）。

可是還有什麼其餘沒有被阻止的內存泄漏我還須要注意麼？

做爲額外的，Mac OS X和iOS上的ARC，以及Mac OS X上的內存回收有什麼區別？

2、回答

回答

回答翻譯

您仍然須要注意的主要內存相關問題是循環引用。這種狀況出如今當一個對象有一個強引用指針到另外一個對象，可是目標指針也有一個強引用的指針指向最初的對象。å即便刪除對這些對象的全部其餘引用，他們仍然互相持有對方而且不會被釋放。這也可能間接發生，經過可能在鏈中的最後一個對象引用回到較早對象的對象鏈。

這就是__unsafe_unretained和__weak全部權限定詞存在的緣由。前者不會保留任何它指向的對象，可是留下該對象消失和指向錯誤內存的可能性，然後者不保留對象，而且當其目標被釋放時自動將其設置爲nil。二者之中，__weak在支持它的平臺上一般是首選的。

你可使用這些限定符來執行像代理一類的事情，這種狀況下你不但願對象保留其委託對象而且可能致使循環引用。

另外幾個重要的內存相關問題是處理Core Foundation對象和使用malloc()分配像類型爲char *的內存。ARC無論理這些類型，只管理Objective-C的對象，因此你仍然須要本身去處理他們。Core Foundation類型可能特別棘手，由於有時他們須要經過橋樑來匹配Objective-C對象，反之亦然。這意味着在Core Foundation類型和Objective-C之間橋接時，須要從ARC來回轉移控制。一些和橋接相關的關鍵字已經被添加了，而且麥克·阿什（Mike Ash）在他漫長的ARC寫做中描述了各類橋樑案例。

除此以外，還有其餘幾個較不頻繁但仍然是潛在的問題的案例，在發佈的規範中將詳細介紹。

基於只要存在一個很強的指針就能夠保持對象的不少新的行爲，很大程度上與Mac上的垃圾回收很是類似。然而，技術基礎是很是不一樣的。這種風格的內存管理依賴於咱們在Objective-C中須要遵照的剛性保留/釋放規則，而不是有一個按期運行的用來清理再也不被指向的對象的垃圾回收進程。

ARC只須要重複咱們已經作了多年的內存管理任務並將其分流到編譯器，因此咱們不再用擔憂了。這樣，你在垃圾回收平臺上就沒有中止問題或在經歷的鋸齒存儲器配置問題了。我已經在垃圾回收的Mac應用程序中都經歷了這兩種，而且很想看到它們在ARC下的行爲。

想看更多地關於垃圾回收和ARC，看看Chris Lattner對Objective-C郵件列表的很是有趣的迴應，他列出了ARC對Objective-C 2.0垃圾回收的許多優勢。我遇到了他所描述的幾個垃圾回收問題。

另外

• 簡書地址
• 掘金地址