sqlite3出現SQLITE_BUSY錯誤碼的緣由以及解決方法

轉載：http://www.javashuo.com/article/p-bkattthh-ew.html

轉載：https://blog.csdn.net/venchia_lu/article/details/50456142

轉載：https://blog.csdn.net/guofu8241260/article/details/36378291

轉載：https://www.jianshu.com/p/15051fbd5a35?utm_campaign

轉載：http://www.cnblogs.com/hustcat/archive/2009/03/01/1400757.html

轉載：http://www.javashuo.com/article/p-guuroinp-ma.html(相同的項目場景)

轉載：http://www.cnblogs.com/gfxxbk/p/5469200.html(錯誤碼)

轉載：http://www.javashuo.com/article/p-fecetapm-hy.html(sqlite線程模型)

轉載：http://www.javashuo.com/article/p-fegylplx-cn.html(API詳細介紹)

最近項目中涉及到sqlite併發讀寫的問題，先搞清楚sqlite3自身的機制。

1.sqlite3支持多線程同時讀操做，但不支持多線程同時寫操做。

2.同一時刻只能有一個線程去進行寫操做，而且在一個線程進行寫操做的時候，其餘線程是不能進行讀操做的。

  當一個線程正在寫操做時，其餘線程的讀寫都會返回操做失敗的錯誤，顯示數據庫文件被鎖住。

3.sqlite3的鎖類型

  sqlite3總共有三種事務類型：BEGIN [DEFERRED /IMMEDIATE / EXCLUSIVE] TRANSCATION，五種鎖，按鎖的級別依次是：UNLOCKED /SHARED /RESERVERD /PENDING /EXCLUSIVE。

  當執行select即讀操做時，須要獲取到SHARED鎖（共享鎖）；

  當執行insert/update/delete操做(即內存寫操做時)，須要進一步獲取到RESERVERD鎖（保留鎖），當進行commit操做(即磁盤寫操做時)，須要進一步獲取到EXCLUSIVE鎖（排它鎖）。

  對於RESERVERD鎖，sqlite3保證同一時間只有一個鏈接能夠獲取到保留鎖，也就是同一時間只有一個鏈接能夠寫數據庫(內存)，可是其它鏈接仍然能夠獲取SHARED鎖，也就是其它鏈接仍然能夠進行讀操做（這裏能夠認爲寫操做只是對磁盤數據的一分內存拷貝進行  修改，並不影響讀操做）。

 對於EXCLUSIVE鎖，是比保留鎖更爲嚴格的一種鎖，在須要把修改寫入磁盤即commit時須要在保留鎖/未決鎖的基礎上進一步獲取到排他鎖，顧名思義，排他鎖排斥任何其它類型的鎖，即便是SHARED鎖也不行，因此，在一個鏈接進行commit時，其它鏈接是不能作任何操做的（包括讀）。

 PENDING鎖（即未決鎖），則是比較特殊的一種鎖，它能夠容許已獲取到SHARED鎖的事務繼續進行，但不容許其它鏈接再獲取SHARED鎖，當已存在的SHARED鎖都被釋放後（事務執行完成），持有未決鎖的事務就能夠得到commit的機會了。sqlite3使用這種鎖來防止writer starvation（寫餓死）。

  sqlite3只支持庫級鎖，庫級鎖意味着什麼？——意味着同時只能容許一個寫操做，也就是說，即事務T1在A表插入一條數據，事務T2在B表中插入一條數據，這兩個操做不能同時進行，即便你的機器有100個CPU，也沒法同時進行，而只能順序進行。表級都不能並行，更別說元組級了——這就是庫級鎖。可是，SQLite儘可能延遲申請X鎖，直到數據塊真正寫盤時才申請X鎖，這是很是巧妙而有效的。

4.解決方案

對於多線程寫數據庫的狀況，Sqlite3不能實現同時寫，可是能夠實現串行寫數據，也就是一個線程在寫的時候，其餘線程等待，第一個線程寫完的時候，另外一個線程得到數據庫文件鎖開始寫。Sqlite3提供了接口sqlite3_busy_handler()，來實現多線程串行寫數據。BusyHandler實際上是一個回調函數。也就是當A線程正在寫操做時，其餘線程寫失敗時進行的重試操做，其餘線程不斷地調用BusyHandler來進行一些處理，直到本身得到寫權限以後。