簡介：
本文介紹如何在 Android 檢測 Cursor 泄漏的原理以及使用方法，還指出幾種常見的出錯示例。有一些泄漏在代碼中難以察覺，但程序長時間運行后必然會出現(xiàn)異常。同時該方法同樣適合于其他需要檢測資源泄露的情況。

最近發(fā)現(xiàn)某蔬菜手機連接程序在查詢媒體存儲（MediaProvider）數(shù)據(jù)庫時出現(xiàn)嚴重 Cursor 泄漏現(xiàn)象，運行一段時間后會導致系統(tǒng)中所有使用到該數(shù)據(jù)庫的程序無法使用。另外在工作中也常發(fā)現(xiàn)有些應用有 Cursor 泄漏現(xiàn)象，由于需要長時間運行才會出現(xiàn)異常，所以有的此類 bug 很長時間都沒被發(fā)現(xiàn)。

但是一旦 Cursor 泄漏累計到一定數(shù)目（通常為數(shù)百個）必然會出現(xiàn)無法查詢數(shù)據(jù)庫的情況，只有等數(shù)據(jù)庫服務所在進程死掉重啟才能恢復正常。通常的出錯信息如下，指出某 pid 的程序打開了 866 個 Cursor 沒有關閉，導致了 exception：

1. Cursor 檢測原理
在 Cursor 對象被 JVM 回收運行到 finalize() 方法的時候，檢測 close() 方法有沒有被調用，此辦法在 ContentResolver 里面也得到應用。簡化后的示例代碼如下：

然后查詢的時候，把 TestCursor 作為查詢結果返回給 APP：
1 return new TestCursor(cursor); // cursor 是普通查詢得到的結果，例如從 ContentProvider.query()
該方法同樣適合于所有需要檢測顯式釋放資源方法沒有被調用的情形，是一種通用方法。但在 finalize() 方法里檢測需要注意
優(yōu)點：準確。因為該資源在 Cursor 對象被回收時仍沒被釋放，肯定是發(fā)生了資源泄露。
缺點：依賴于 finalize() 方法，也就依賴于 JVM 的垃圾回收策略。例如某 APP 現(xiàn)在有 10 個 Cursor 對象泄露，并且這 10 個對象已經(jīng)不再被任何引用指向處于可回收狀態(tài)，但是 JVM 可能并不會馬上回收（時間不可預測），如果你現(xiàn)在檢查不能夠發(fā)現(xiàn)問題。另外，在某些情況下就算對象被回收 finalize() 可能也不會執(zhí)行，也就是不能保證檢測出所有問題。關于 finalize() 更多信息可以參考《Effective Java 2nd Edition》的 Item 7： Avoid Finalizers

2. 使用方法
對于 APP 開發(fā)人員
從 GINGERBREAD 開始 Android 就提供了 StrictMode 工具協(xié)助開發(fā)人員檢查是否不小心地做了一些不該有的操作。使用方法是在 Activity 里面設置 StrictMode，下面的例子是打開了檢查泄漏的 SQLite 對象以及 Closeable 對象（普通 Cursor/FileInputStream 等）的功能，發(fā)現(xiàn)有違規(guī)情況則記錄 log 并使程序強行退出。

對于 framework 開發(fā)人員
如果是通過 ContentProvider 提供數(shù)據(jù)庫數(shù)據(jù)，在 ContentResolver 里面已有 CloseGuard 類實行類似檢測，但需要自行打開（上例也是打開 CloseGuard）：
1 CloseGuard.setEnabled(true);更值得推薦的辦法是按照本文第一節(jié)中的檢測原理，在 ContentResolver 內部類 CursorWrapperInner 里面加入。其他需要檢測類似于資源泄漏的，同樣可以使用該檢測原理。

3. 容易出錯的地方
忘記調用 close() 這種低級錯誤沒什么好說的，這種應該也占不小的比例。下面說說不太明顯的例子。
提前返回
有時候粗心會犯這種錯誤，在 close() 調用之前就 return 了，特別是函數(shù)比較大邏輯比較復雜時更容易犯錯。這種情況可以通過把 close() 放在 finally 代碼塊解決

類的成員變量
假設類里面有一個在類全局有效的成員變量，在方法 A 獲取了查詢結果，后面在其他地方又獲取了一次查詢結果，那么第二次查詢的時候就應該先把前面一個 Cursor 對象關閉。

注意：曾經(jīng)遇到過有人對 mCursor 感到疑惑，明明是同一個變量為什么還需要先關閉？首先 mCursor 是一個 Cursor 對象的引用，在 methodA 時 mCursor 指向了 query() 返回的一個 Cursor 對象 1；在 methodB() 時它又指向了返回的另外一個 Cursor 對象 2。在指向 Cursor 對象 2 之前必須先關閉 Cursor 對象 1，否則就出現(xiàn)了 Cursor 對象 1 在 finalize() 之前沒有調用 close() 的情況。
異常處理
打開和關閉 Cursor 之間的代碼出現(xiàn) exception，導致沒有跑到關閉的地方：

這種情況應該把 close() 放到 finally 代碼塊里面：
 
4. 總結思考
在 finalize() 里面檢測是可行的，且基本可以滿足需要。針對 finalize() 執(zhí)行時間不確定以及可能不執(zhí)行的問題，可以通過記錄目前打開沒關閉的 Cursor 數(shù)量來部分解決，超過一定數(shù)目發(fā)出警告，兩種手段相結合。

還有沒有其他檢測辦法呢？有，在 Cursor 構造方法以及 close() 方法添加 log，運行一段時間后檢查 log 看哪個地方?jīng)]有關閉。簡化代碼如下：

檢查時看某個 hashCode() 的 Cursor 有沒有調用過 close() 方法，沒有的話說明資源有泄露。這種方法優(yōu)點是同樣準確，且更可靠。缺點是需要檢查大量 log，且打開/關閉的地方可能相距較遠，如果不寫個小腳本分析人工看的話會比較痛苦；另外必須 APP 完全退出后才能檢查，因為后臺運行時某些 Cursor 還在正常使用。

最新評論