SQLite的锁

_南_无_生_

已于 2022-08-31 20:53:19 修改

阅读量3.2k

点赞数 14

文章标签： sqlite 数据库

于 2022-08-28 14:50:11 首次发布

本文链接：https://blog.csdn.net/m0_68994303/article/details/126569701

版权

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

一、简介

SQLite是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。它是一个零配置的数据库，这意味着与其他数据库不一样，您不需要在系统中配置。

就像其他数据库，SQLite 引擎不是一个独立的进程，可以按应用程序需求进行静态或动态连接。SQLite 直接访问其存储文件。

大家注意，在写入的时候，如果要写入中文的话，就要将中文从GB2312转换到utf-8再写入，

二、事务与锁

2.1 SQLITE的锁

1)UNLOCKED：无锁 文件没有持有任何锁，即当前数据库不存在任何读或写的操作。其它的进程可以在该数据库上执行任意的读写操作。此状态为缺省状态。 2)SHARED：共享锁 在此状态下，该数据库可以被读取但是不能被写入。在同一时刻可以有任意数量的进程在同一个数据库上持有共享锁，因此读操作是并发的。换句话说，只要有一个或多个共享锁处于活动状态，就不再允许有数据库文件写入的操作存在。 3)RESERVED：保留锁 假如某个进程在将来的某一时刻打算在当前的数据库中执行写操作，然而此时只是从数据库中读取数据，那么我们就可以简单的理解为数据库文件此时已经拥有了保留锁。当保留锁处于活动状态时，该数据库只能有一个或多个共享锁存在，即同一数据库的同一时刻只能存在一个保留锁和多个共享锁。在Oracle中此类锁被称之为预写锁，不同的是Oracle中锁的粒度可以细化到表甚至到行，因此该种锁在Oracle中对并发的影响程序不像SQLite中这样大。 4)PENDING：等待锁（写等待） PENDING锁的意思是说，某个进程正打算在该数据库上执行写操作，然而此时该数据库中却存在很多共享锁(读操作)，那么该写操作就必须处于等待状态，即等待所有共享锁消失为止，与此同时，新的读操作将不再被允许，以防止写锁饥饿的现象发生。在此等待期间，该数据库文件的锁状态为PENDING，在等到所有共享锁消失以后，PENDING锁状态的数据库文件将在获取排他锁之后进入EXCLUSIVE状态。 5)EXCLUSIVE：排它锁（写） 在执行写操作之前，该进程必须先获取该数据库的排他锁。然而一旦拥有了排他锁，任何其它锁类型都不能与之共存。因此，为了最大化并发效率，SQLite将会最小化排他锁被持有的时间总量。

在SQLite中，锁和事务是紧密联系的。为了有效地使用事务，需要了解一些关于如何加锁的知识。 SQLite采用粗放型的锁。当一个连接要写数据库，所有其它的连接被锁住，直到写连接结束了它的事务。SQLite有一个加锁表，来帮助不同的写数据库都能够在最后一刻再加锁，以保证最大的并发性。 SQLite使用锁逐步上升机制，为了写数据库，连接需要逐级地获得排它锁。SQLite有5个不同的锁状态：未加锁(UNLOCKED)、共享(SHARED)、保留(RESERVED)、未决(PENDING)和排它(EXCLUSIVE)。每个数据库连接在同一时刻只能处于其中一个状态。每种状态(未加锁状态除外)都有一种锁与之对应。最初的状态是未加锁状态，在此状态下，连接还没有存取数据库。当连接到了一个数据库，甚至已经用BEGIN开始了一个事务时，连接都还处于未加锁状态。未加锁状态的下一个状态是共享状态。为了能够从数据库中读(不写)数据，连接必须首先进入共享状态，也就是说首先要获得一个共享锁。多个连接可以同时获得并保持共享锁，也就是说多个连接可以同时从同一个数据库中读数据。但哪怕只有一个共享锁还没有释放，也不允许任何连接写数据库。

如果一个连接想要写数据库，它必须首先获得一个保留锁。一个数据库上同时只能有一个保留锁。保留锁可以与共享锁共存，保留锁是写数据库的第1阶段。保留锁即不阻止其它拥有共享锁的连接继续读数据库，也不阻止其它连接获得新的共享锁。一旦一个连接获得了保留锁，它就可以开始处理数据库修改操作了，尽管这些修改只能在缓冲区中进行，而不是实际地写到磁盘。对读出内容所做的修改保存在内存缓冲区中。当连接想要提交修改(或事务)时，需要将保留锁提升为排它锁。为了得到排它锁，还必须首先将保留锁提升为未决锁。获得未决锁之后，其它连接就不能再获得新的共享锁了，但已经拥有共享锁的连接仍然可以继续正常读数据库。此时，拥有未决锁的连接等待其它拥有共享锁的连接完成工作并释放其共享锁。一旦所有其它共享锁都被释放，拥有未决锁的连接就可以将其锁提升至排它锁，此时就可以自由地对数据库进行修改了。所有以前对缓冲区所做的修改都会被写到数据库文件。

2.2 事务种类

SQLite有三种不同的事务，使用不同的锁状态。事务可以开始于：DEFERRED、MMEDIATE或EXCLUSIVE。事务类型在BEGIN命令中指定： BEGIN [ DEFERRED | IMMEDIATE | EXCLUSIVE ] TRANSACTION; 一个DEFERRED事务不获取任何锁(直到它需要锁的时候)，BEGIN语句本身也不会做什么事情——它开始于UNLOCK状态。默认情况下就是这样的，如果仅仅用BEGIN开始一个事务，那么事务就是DEFERRED的，同时它不会获取任何锁；当对数据库进行第一次读操作时，它会获取SHARED锁；同样，当进行第一次写操作时，它会获取RESERVED锁。由BEGIN开始的IMMEDIATE 事务会尝试获取RESERVED锁。如果成功，BEGIN IMMEDIATE保证没有别的连接可以写数据库。但是，别的连接可以对数据库进行读操作；但是，RESERVED锁会阻止其它连接的BEGIN IMMEDIATE或者BEGIN EXCLUSIVE命令，当其它连接执行上述命令时，会返回SQLITE_BUSY错误。这时你就可以对数据库进行修改操作了，但是你还不能提交，当你COMMIT时，会返回SQLITE_BUSY错误，这意味着还有其它的读事务没有完成，得等它们执行完后才能提交事务。

EXCLUSIVE事务会试着获取对数据库的EXCLUSIVE锁。这与IMMEDIATE类似，但是一旦成功，EXCLUSIVE事务保证没有其它的连接，所以就可对数据库进行读写操作了。上节那个例子的问题在于两个连接最终都想写数据库，但是它们都没有放弃各自原来的锁最终，SHARED锁导致了问题的出现。如果两个连接都以BEGIN IMMEDIATE开始事务，那么死锁就不会发生。在这种情况下，在同一时刻只能有一个连接进入BEGIN IMMEDIATE，其它的连接就得等待。BEGIN IMMEDIATE和BEGIN EXCLUSIVE通常被写事务使用。就像同步机制一样，它防止了死锁的产生。基本的准则是：如果你正在使用的数据库没有其它的连接，用BEGIN就足够了。但是，如果你使用的数据库有其它的连接也会对数据库进行写操作，就得使用BEGIN IMMEDIATE或BEGIN EXCLUSIVE开始你的事务。

2.2.1 事务的生命周期

一般来说，一个事务的生命周期和语句差不多，你也可以手动结束它。默认情况下，事务自动提交，当然你也可以通过BEGIN..COMMIT手动提交。大多数情况下，锁的生命周期在事务的生命周期之中。它们不一定同时开始，但总时同时结束。当你结束一个事务时，也会释放它相关的锁。或者说，锁直到事务结束或系统崩溃时才会释放。如果系统在事务没有结束的情况下崩溃，那么下一个访问数据库的连接会处理这种情况。

2.3 并发控制过程

SQLite的并发控制机制是采用加锁的方式，当执行select即读操作时，需要获取到SHARED锁（共享锁），当执行insert/update/delete操作(即内存写操作时)，需要进一步获取到RESERVERD锁（保留锁），当进行commit操作(即磁盘写操作时)，需要进一步获取到EXCLUSIVE锁（排它锁）。

对于RESERVERD锁，sqlite3保证同一时间只有一个连接可以获取到保留锁，也就是同一时间只有一个连接可以写数据库(内存)，但是其它连接仍然可以获取SHARED锁，也就是其它连接仍然可以进行读操作（这里可以认为写操作只是对磁盘数据的一份内存拷贝进行修改，并不影响读操作）。

对于EXCLUSIVE锁，是比保留锁更为严格的一种锁，在需要把修改写入磁盘即commit时需要在保留锁/未决锁的基础上进一步获取到排他锁，顾名思义，排他锁排斥任何其它类型的锁，即使是SHARED锁也不行，所以，在一个连接进行commit时，其它连接是不能做任何操作的（包括读）。

PENDING锁（即未决锁），则是比较特殊的一种锁，它可以允许已获取到SHARED锁的事务继续进行，但不允许其它连接再获取SHARED锁，当已存在的SHARED锁都被释放后（事务执行完成），持有未决锁的事务就可以获得commit的机会了。sqlite3使用这种锁来防止writer starvation（写饿死）。

2.4 线程模式

SQLite 支持如下三种线程模型

单线程模型这种模型下，所有互斥锁都被禁用，同一时间只能由一个线程访问。多线程模型这种模型下，一个连接在同一时间内只有一个线程使用就是安全的。串行模型开启所有锁，可以随意访问。（同一个连接在不同线程中执行也优化成串行）

单线程：这种模式下，没有进行互斥，多线程使用不安全。禁用所有的mutex锁，并发使用时会出错。当SQLite编译时加了SQLITE_THREADSAFE=0参数，或者在初始化SQLite前调用sqlite3_config(SQLITE_CONFIG_SINGLETHREAD)时启用。

多线程：这种模式下，只要一个数据库连接不被多个线程同时使用就是安全的。源码中是启用bCoreMutex，禁用bFullMutex。实际上就是禁用数据库连接和prepared statement(准备好的语句)上的锁，因此不能在多个线程中并发使用同一个数据库连接或prepared statement。当SQLite编译时加了SQLITE_THREADSAFE=2参数时默认启用。若SQLITE_THREADSAFE不为0，可以在初始化SQLite前，调用sqlite3_config(SQLITE_CONFIG_MULTITHREAD)启用;或者在创建数据库连接时，设置SQLITE_OPEN_NOMUTEX flag。

串行：sqlite是线程安全的。启用所有的锁，包括bCoreMutex和bFullMutex 。因为数据库连接和prepared statement都已加锁，所以多线程使用这些对象时没法并发，也就变成串行了。当SQLite编译时加了SQLITE_THREADSAFE =1参数时默认启用。若SQLITE_THREADSAFE不为0，可以在初始化SQLite前，调用sqlite3_config(SQLITE_CONFIG_SERIALIZED)启用;或者在创建数据库连接时，设置SQLITE_OPEN_FULLMUTEX flag 。而这里所说的初始化是指调用sqlite3_initialize()函数，这个函数在调用sqlite3_open()时会自动调用，且只有第一次调用是有效的.

SQLite 可以通过以下三种方式进行线程模型的设置，在实际应用中选择任一一项都可以。

编译期设定 通过 SQLITE_THREADSAFE 这个参数进行编译器的设定来选择线程模型

初始化设定 通过调用 sqlite3_config() 可以在 SQLite 初始化时进行设定

运行时设定 通过调用 sqlite3_open_v2() 接口指定数据库连接的数据库模型

为了达到线程安全，SQLite在编译时必须将 SQLITE_THREADSAFE 预处理宏置为1。在Windows和Linux上，已编译的好的二进制发行版中都是这样设置的。如果不确定你所使用的库是否是线程安全的，可以调用 sqlite3_threadsafe() 接口找出。调用sqlite3_threadsafe()可以获得编译期的SQLITE_THREADSAFE参数。

也就是说线程模式可以在编译时（通过源码编译sqlite库时）、启动时（使用sqlite的应用程序初始化时）或者运行时（创建数据库连接时）来指定。一般而言，运行时指定的模式将覆盖启动时的指定模式，启动时指定的模式将覆盖编译时指定的模式。但是，单线程模式一旦被指定，将无法被覆盖。默认的线程模式是串行模式。

2.4.1 编译时选择线程模式

这几种模式可以通过参数SQLITE_THREADSAFE在编译阶段指定，可以取值0，1，2，默认是1。这三种取值的含义如下：

0:单线程模式，即内部不做mutex保护，多线程运行sqlite不安全。

1:多线程的串行模式，sqlite帮助多线程实现串行化。

2:多线程的并发模式，要求同一个时刻，同一个连接不被多个线程使用。

sqlite3_threadsafe()函数的返回值可以确定编译时指定的线程模式。如果指定了单线程模式，函数返回false。如果指定了串行或者多线程模式，函数返回true。由于sqlite3_threadsafe()函数要早于多线程模式以及启动时和运行时的模式选择，所以它既不能区别多线程模式和串行模式也不能区别启动时和运行时的模式。

最后一句可通过sqlite3_threadsafe函数的实现来理解

SQLITE_API int sqlite3_threadsafe(void){ return SQLITE_THREADSAFE; }

如果编译时指定了单线程模式，那么临界互斥逻辑在构造时就被省略，因此也就无法在启动时或运行时指定串行模式或多线程模式。

2.4.2 初始化选择线程模式

假如在编译时没有指定单线程模式，就可以在应用程序初始化时使用sqlite3_config()函数修改线程模式。参数SQLITE_CONFIG_SINGLETHREAD可指定为单线程模式，SQLITE_CONFIG_MULTITHREAD指定为多线程模式，SQLITE_CONFIG_SERIALIZED指定为串行模式。