引用鏈條中只要有一環發生迴圈引用，就會導致記憶體洩露。工具難以查出，因為符合使用約定。

遺憾的是相互引用十分常見，對於介面來說有時是必要的，特別是OBJC大量使用委託模式進行回撥。因此OBJC也建議委託最好不進行retain，而改用 assign，以避免迴圈引用。不過一些非同步呼叫，多執行緒使用是很難通過此種方式解決的，容易出現野指標。所以要解決迴圈引用導致的記憶體洩露需要從根源理 解洩露出現的原因，而不是單純禁止使用。

迴圈引用問題，是引用計數所引入的問題。因此使用引用計數作為資料管理的架構都會出現類似問題。JAVA、C#的垃圾回收機制都有專門的演算法來解決此問 題。引數管理的資料都是共享關係，相互引用就是相互共享，這種記憶體洩露是符合共享邏輯的。但實際情況中，當出現相互引用，往往存在依賴關係。一個引用為擁 有，而另一個僅為回撥。回撥引用依賴擁有引用。引數管理不能直接描述依賴關係，因此需要手工打斷。

現假設B處由於某種原因使C被釋放掉，比如執行緒結束或是Cancel操作，則此時在由root處釋放A時，則全部釋放。

所以不是隻要迴圈引用就會記憶體洩露，通過打斷解決記憶體洩露是有效的，因為打斷補充了相互引用的依賴邏輯。但要注意，如果出於省事僅將打斷程式碼放置在dealloc中，則仍然會出現記憶體洩露。原 因在於release字面意思是釋放的意思，但這裡的釋放不是記憶體的最終釋放而是所有權的釋放。呼叫release是分不清記憶體釋放還是僅僅減了一個計 數。迴圈引用時，存在於dealloc中的打斷程式碼，將永遠不會通過release呼叫。因此要解決迴圈引用，還要注意不要將打斷程式碼放置在 dealloc中，而要在使用完畢後立即打斷，dealloc的打斷只能作為象徵性防護。

總結：

防止迴圈引用導致的記憶體洩露，基本上有兩種方法。

1)如果其中一個物件的生命週期覆蓋另一個物件，則採用OBJC推薦的策略，短週期物件保持長週期物件使用assign。

2）如果相互引用的物件其生命週期不能覆蓋對方，則必須在各自生命週期的終點處打斷對方，打斷程式碼不能依賴在dealloc時打斷。比如對於UI物件可通過事件處打斷，執行緒物件於Main結尾處打斷。只要有一處打斷被執行就不會產生記憶體洩露。

此外還有另一種解決方法——利用指標的指標建立依賴引用機制。

這裡提供一下思路：引用雙方只assign不retain，雙方再額外儲存對方引用的指標，當一方release時順便將自身在對方的引用清空，以達到通知連線斷開的目的。可將這種引用關係封裝為一個類簡化使用。

優點：避免迴圈引用導致記憶體洩露，即便在release處釋放連線也不會引起記憶體洩露。

缺點：引用返回的是id型別，因此使用時需要型別轉換。

另外程式設計時還要注意非預期的迴圈引用。比如OBJC庫中經常使用字典作為引數的儲存位置，而字典使用retain儲存物件。如果A保持字典，字典中又保持A，或者保持B，但B保持A，則有可能產生記憶體洩露。

總之迴圈引用引起記憶體洩露，是需要在OBJC中額外注意的。C/C++不會產生此問題，因為引用需要手工維護。JAVA、C#中由於垃圾回收機制，也無需刻意注意。