這兩天在專案中用大強度大頻率的方法測試時遇到sqlite報database is locked的問題,
分析下來原因是sqlite對資料庫做修改操作時會做(檔案)鎖使得其它程序同一時間使用時會報該錯誤(也就是SQLITE_BUSY)，但如果僅是多程序或多執行緒查詢sqlite是支援的。
解決方法有：
1。使用程序或執行緒間的同步機制以避免同時操作；如用訊號量，互斥鎖等（pthread_mutex_lock，pthread_mutex_unlock）,如果你的專案工程較大要求較高的話建議用此方法自行封裝函式處理同步
2。使用sqlite提供的兩個busy handler函式，但對於一個連線來說，只能有一個busy handle，兩個函式會相互影響，設定一個的同時會清除另一個，應根據需要來選擇。
int sqlite3_busy_handler

(sqlite3 *, int (*)(void *, int), void *)
不註冊此函式時預設回撥函式為NULL，清除busy handle，申請不到鎖直接返回;
函式可以定義一個回撥函式，當出現數據庫忙時sqlite會呼叫該函式進行延時並返回非0會重試本次操作，回撥函式的第二個引數會被傳遞為此次因BUSY忙事件而呼叫該函式的次數,因此你完全可以自行控制多少次後(也就是延時多少後)才真正返回BUSY;
回撥函式返回非０,資料庫會重試當前操作，返回０則當前操作返回SQLITE_BUSY;

int sqlite3_busy_timeout(sqlite3*, int ms);
不註冊此函式時預設超時等待為0，當ms<=0時，清除busy handle，申請不到鎖直接返回;
定義一個毫秒數，當未到達該毫秒數時，sqlite會sleep並重試當前操作,
如果超過ms毫秒，仍然申請不到需要的鎖，當前操作返回SQLITE_BUSY;
很多人用這個函式沒有成功

，其實只要你仔細檢視sqlite的原始碼就會發現，
這個函式實際上註冊了一個預設的sqlite3_busy_handler（sqliteDefaultBusyCallback），而這個回撥函式在你的編譯環境下可能使得第二個ms引數必需要大於1000且是他的整數倍才有意義,由於此預設callback函式延時較大,建議自己寫回調函式然後用slite3_busy_handler註冊,這樣就可以自己用自己的延時函式或方法進行處理了.