通常情况下，sqlite中每个连接都会一个独立的pager对象，pager对象中管理了该连接的缓存信息，通过pragma cache_size指令可以设置缓存大小，默认是2000个page，每个page是1024B。这样导致了对于同一个数据文件，多个连接各自维护了自己的一份缓存，在高并发情况下，可能导致使用大量的内存。而sqlite作为一个嵌入式 数据库，通常用于嵌入式设备，内存可能比较有限，为了应对这种问题，sqlite提供了一种方法，通过让多个连接公用一个pager对象，共享同一份缓存。

当打开这个特性后，多个连接可以共享一个pager对象，这样在一定程度上减少了内存的消耗和文件的IO次数。一个线程的多个连接对象，以及多个线程的多个连接对象都可以采用这种方式来共享缓存。由于sqlite以动态库方式嵌入在应用程序中，每个应用程序有自己独立的进程空间，因此该特性不能用于进程之间，同一个进程可以共享一份缓存，

进程之间各自维护自己的缓存。关于缓存的实现后面会单独写一篇文章。下图展示了启用共享缓存后的结构图。

从图1中可以看到，Process1中的两个连接共享BtShared对象，BtShared对象对应一个Pager对象，而缓存由Pager对象管理，因此整个Process1中的所有连接公用一个缓存，通过Pager模块操作Page，IO操作对上层模块透明。

实现原理

调用接口sqlite3_open_v2打开连接时，通过指定参数SQLITE_OPEN_SHAREDCACHE来声明连接采用共享缓存模式。之前SQLite系列(二):常规性能测试 中的单表主键查询测试章节中提到，开启共享缓存模式下，导致应用的程序的并发性能大大下降，多线程情况下，CPU也只能用一个核。因此大家在实际使用中，要权衡内存和并行度，来确定是否开启共享缓存模式。

我们的测试场景都是只读，理论上不应该存在并发冲突，那么为什么不能并行？这里要看共享缓存的实现了。从图1中也可以看到，每个连接有一个btree对象，多个btree对象通过共享BtShared对象来共享缓存，BtShared对象通过mutux来维护里面的成员，包括page cache的管理，table-lock信息等，因此这个mutex是一个热点，在高并发场景下，多个线程同时访问BtShared对象，会由于竞争mutex，无法充分并发，导致并行度差。

table-lock

默认情况下，sqlite只通过文件锁就可以实现读写互斥，读读并发的效果，关于这点我在SQLite系列(五):SQLITE封锁机制中已经说明。那么为什么要引入table-lock？这个也是拜共享缓存所赐。共享缓存模式下，多个btree对象对应同一个BtShared对象，在执行更新时，首先会修改pager中cache，此时更新事务加了reserved-lock，与读事务的shared-lock不互斥。为了避免读到脏页，在共享缓存模式下，增加了table-lock，避免读写事务同时访问同一个cache，导致脏读的情况发生。用户访问具体某个表的page之前，会首先调用sqlite3BtreeLockTable对该表设置一个READ-LOCK(select 操作)或WRITE-LOCK(DML操作)，如果发现冲突，则抛出SQLITE_LOCKED错误。通过这种方式，保证了多个线程不会同时对一个表进行读写操作。函数sqlite3BtreeLockTable部分实现如下：

sqlite3BtreeEnter(p);

//判断加锁是否冲突

rc = querySharedCacheTableLock(p, iTab, lockType);

if( rc==SQLITE_OK ){

//加锁

rc = setSharedCacheTableLock(p, iTab, lockType);

}

sqlite3BtreeLeave(p);

从上面的代码可以看到，若加锁冲突，则直接报SQLITE_LOCKED错误；否则加上锁。注意看到判断加锁和加锁过程通过BtShared对象的mutex来保护(sqlite3BtreeEnter,sqlite3BtreeLeave)，因此加锁过程是串行的，table-lock链表不会被多个线程同时操作。

querySharedCacheTableLock代码逻辑

/* If some other connection is holding an exclusive lock, the

** requested lock may not be obtained.

*/

if( pBt->pWriter!=p && (pBt->btsFlags & BTS_EXCLUSIVE)!=0 ){
   
     sqlite3ConnectionBlocked(p->db, pBt->pWriter->db);
     return SQLITE_LOCKED_SHAREDCACHE;
}
setSharedCacheTableLock逻辑

for(pIter=pBt->pLock; pIter; pIter=pIter->pNext){
    if( pIter->iTable==iTable && pIter->pBtree==p ){  
    pLock = pIter;
    break;
  }
}

/*create a table lock*/
if( !pLock ){
   pLock = (BtLock *)sqlite3MallocZero(sizeof(BtLock));

   if( !pLock ){
     
   return SQLITE_NOMEM;
  }
   
pLock->iTable = iTable;
pLock->pBtree = p;
pLock->pNext = pBt->pLock;
pBt->pLock = pLock;
}

遍历BtShared对象中已有锁链表，比较iTable和对应的pBtree是否与自身相同(自己是否已经加过)，若没有，则申请锁对象，加入链表。

加锁流程

我们知道sqlite有两种日志模式，默认的DELETE模式和WAL模式，下面我会介绍开启共享缓存模式后，更新操作的加锁流程，主要变化在于table-lock。

普通日志模式+共享缓存模式

开启事务：shared-lock[sqlite3BtreeBeginTrans]

DML操作：

文件锁，reserved-lock

table-lock，

将对应的表加锁，同一个表的读锁与写锁互斥

读取表对应的page

提交：

加execlusive-lock [sqlite3PagerCommitPhaseOne,刷日志]

删除日志文件

释放execlusive-lock

释放table-lock

WAL日志模式+共享缓存模式

开启事务，shared-lock[sqlite3BtreeBeginTrans]