因为sqlite是文件数据库，所以它的锁也基本是和文件一致，也即：写独占，读共享。这意味是在读取数据库的时候，是可以多个线程共享的，而如果有增删改的操作，则会独占此文件，其他线程会进程都会被阻塞。

在移动设备上，比较常见的情况是App的UI进程和Service进程同时访问数据库，这个时候就要对其访问做好并发的处理，否则会出现很多意想不到的后果。

对于每个sqlite的API执行，都需要妥善处理返回值，尤其是sql_BUSY的时候。

当一个线程独占数据库时，其他线程无论是查询还是写入，都可能返回sql_BUSY，这个时候，有几种处理方式：

1，使用操作系统的锁，比如信号量和Mutex，把执行写入的操作代码框在临界区内。

HANDLE hMutex =NULL;

hMutex = CreateMutex(NULL,TRUE,NULL);

WaitForSingleObject(hMutex,INFINITE);

sqlite operation;

ReleaseMutex(hMutex);

2，让其他线程在遇到sql_BUSY的时候重试。

Exec:

int nRet = sqlite3_exec(db,sql,NULL,errmsg);

if(nRet== sql_BUSY)

{
    sleep(100);
    goto Exec;

}

注意个人设置重试次数，以免死锁。

3，经测试，在显式地开启了事务后，其他线程似乎会默认等待，到事务执行完成后再进入临界区。相当于sqlite引擎做了第1种方案做的事。