Android getReadableDatabase 主線程調用風險：SQLiteException database locked 根因與解決

現象

Android 2.2 設備偶發 SQLiteException: database locked，API 文檔警告：getReadableDatabase() 可能耗時，不應在主線程調用。

文檔警告解讀

「此方法可能需要很長時間返回，不應從應用主線程調用，包括 ContentProvider.onCreate()」

原因：首次調用時會檢查數據庫完整性、執行 onCreate/onUpgrade、獲取文件鎖、WAL 模式檢查點等，可能阻塞主線程導致 ANR。

「偶發 database locked」真實根因

並非主線程調用直接導致，而是並發訪問衝突：

• 多線程同時操作同一 SQLiteOpenHelper 實例
• 一個線程持有寫鎖 (getWritableDatabase)，另一線程嘗試讀 (getReadableDatabase)
• 未正確關閉數據庫 (close()) 導致鎖未釋放
• 多進程訪問同一數據庫文件 (需啟用 WAL 或跨進程鎖)

解決方案對比

Room 核心優勢：主線程保護

// Room 自動在背景線程執行查詢
@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    LiveData> getAllUsers(); // 返回 LiveData，自動在 IO 線程查詢
    
    @Insert
    suspend fun insertUsers(users: List); // 協程掛起函數，自動切換 IO 線程
}

// 主線程直接觀察，零風險
viewModel.users.observe(this) { users -> 
    adapter.submitList(users) 
}

若必須繼承用 SQLiteOpenHelper：最小化風險清單

1. 單例模式：全進程唯一實例，避免多實例並發
2. 所有 DB 操作加同步鎖：synchronized(helper) { db = helper.getWritableDatabase(); ... }
3. 啟用 WAL 模式：db.enableWriteAheadLogging() 提升並發讀寫性能
4. 嚴格配對 open/close：或使用 try-with-resources (API 19+)
5. 避免在主線程做耗時查詢：用 AsyncQueryHandler 或自定義線程池

總結

文檔警告是為防 ANR，database locked 是並發衝突。徹底解決請遷移 Room，舊專案加鎖+WAL+單例可緩解。