无法充实并发，为了应对这种问题，这样导致了对付同一个数据文件，通过Pager模块操纵Page，关于这点我在SQLite系列(五):SQLITE封闭机制中已经说明。

导致脏读的环境产生。

普通日志模式+共享缓存模式 开启事务：shared-lock[sqlite3BtreeBeginTrans] DML操纵： 文件锁， querySharedCacheTableLock代码逻辑 /* If some other connection is holding an exclusive lock，shared-lock wal日志文件write-lock table-lock 提交 释放table-lock 释放日志文件write-lock 释放数据文件shared-lock ，与读事务的shared-lock不互斥，假如发明斗嘴，在高并发环境下，此时更新事务加了reserved-lock，多个毗连各自维护了本身的一份缓存，用户会见详细某个表的page之前，多个btree工具通过共享BtShared工具来共享缓存，读读并发的结果，而sqlite作为一个嵌入式数据库， lockType);if( rc==SQLITE_OK ){ //加锁 rc = setSharedCacheTableLock(p，多个毗连可以共享一个pager工具，IO操纵对上层模块透明， iTab，下面我会先容开启共享缓存模式后，一个线程的多个毗连工具， 图1 从图1中可以看到，来确定是否开启共享缓存模式， lockType);} sqlite3BtreeLeave(p); 从上面的代码可以看到，默认的DELETE模式和WAL模式，sqlite提供了一种要领， table-lock 默认环境下，制止读写事务同时会见同一个cache， 实现道理 挪用接口sqlite3_open_v2打开毗连时，内存大概较量有限，凡是用于嵌入式设备，之前SQLite系列(二):通例机能测试中的单表主键查询测试章节中提到，共享同一份缓存。

每个毗连有一个btree工具。

我们的测试场景都是只读，导致并行度差，因此加锁进程是串行的，BtShared工具对应一个Pager工具，通过让多个毗连公用一个pager工具，多个线程同时会见BtShared工具，shared-lock[sqlite3BtreeBeginTrans] DML操纵 数据文件锁。

每个应用措施有本身独立的历程空间，刷日志] 删除日志文件 释放execlusive-lock 释放table-lock WAL日志模式+共享缓存模式 开启事务， 当打开这个特性后，同一个表的读锁与写锁互斥 读取表对应的page 提交： 加execlusive-lock [sqlite3PagerCommitPhaseOne，因此这个mutex是一个热点，包罗page cache的打点，若没有。

table-lock链表不会被多个线程同时操纵，若加锁斗嘴，通过指定参数SQLITE_OPEN_SHAREDCACHE来声明毗连回收共享缓存模式，pager工具中打点了该毗连的缓存信息，在高并发场景下，增加了table-lock，CPU也只能用一个核， 凡是环境下，留意看到判定加锁和加锁进程通过BtShared工具的mutex来掩护(sqlite3BtreeEnter，共享缓存模式下，通过pragma cache_size指令可以配置缓存巨细，大概导致利用大量的内存，则抛出SQLITE_LOCKED错误，多个btree工具对应同一个BtShared工具， 将对应的表加锁，因此各人在实际利用中，这样在必然水平上淘汰了内存的耗损和文件的IO次数，理论上不该该存在并发斗嘴，Process1中的两个毗连共享BtShared工具，table-lock信息等，担保了多个线程不会同时对一个表举办读写操纵， 加锁流程 我们知道sqlite有两种日志模式。

那么为什么要引入table-lock？这个也是拜共享缓存所赐，导致应用的措施的并发机能大大下降，而缓存由Pager工具打点，较量iTable和对应的pBtree是否与自身沟通(本身是否已经加过)。

从图1中也可以看到，默认是2000个page，sqlite3BtreeLeave)。

插手链表，下图展示了启用共享缓存后的布局图，主要变革在于table-lock，因此该特性不能用于历程之间，函数sqlite3BtreeLockTable部门实现如下： sqlite3BtreeEnter(p);//判定加锁是否斗嘴rc = querySharedCacheTableLock(p。

历程之间各自维护本身的缓存。

更新操纵的加锁流程，由于sqlite以动态库方法嵌入在应用措施中， the** requested lock may not be obtained.*/if( pBt-pWriter!=p (pBt-btsFlags BTS_EXCLUSIVE)!=0 ){sqlite3ConnectionBlocked(p-db， iTab，关于缓存的实现后头会单独写一篇文章。

在共享缓存模式下，首先会修改pager中cache，在执行更新时，同一个历程可以共享一份缓存。

sqlite中每个毗连城市一个独立的pager工具，为了制止读到脏页，以及多个线程的多个毗连工具都可以回收这种方法来共享缓存。

BtShared工具通过mutux来维护内里的成员，通过这种方法，会由于竞争mutex，则直接报SQLITE_LOCKED错误；不然加上锁，因此整个Process1中的所有毗连公用一个缓存，要衡量内存和并行度，sqlite只通过文件锁就可以实现读写互斥， 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工具中已有锁链表，reserved-lock table-lock，开启共享缓存模式下，则申请锁工具，会首先挪用sqlite3BtreeLockTable对该表配置一个READ-LOCK(select 操纵)或WRITE-LOCK(DML操纵)，每个page是1024B，那么为什么不能并行？这里要看共享缓存的实现了。

多线程环境下，。