[TOC]
## 数据库锁
SQLite的数据库连接有5种状态:
| 状态 | 对应的锁 |
| --- | --- |
| 未加锁 | — |
| 共享(shared) | 共享锁 |
| 预留(reserved) | 预留锁 |
| 未决(pending) | 未决锁 |
| 排它(exclusive) | 排它锁 |
SQL使用锁逐步提升机制,上面的表格从上到下,对应锁的等级逐步提升,等级越高权限就越大。
**未加锁:**
未和数据库建立连接、已建立连接但是还没访问数据库、已用BEGIN开始了一个事务但未开始读写数据库,处于这些情形时是未加锁状态。
**共享:**
连接需要从数据库中读取数据时,需要申请获得一个共享锁,如果获得成功,则进入共享状态。
**预留:**
连接需要写数据库时,首先申请一个预留锁,一个数据库同时只能有一个预留锁,预留锁可以与共享锁共存。获得预留锁后进入预留状态,这时会先在缓冲区中进行需要的修改、更新操作,操作后的结果依然保存在缓冲区中,未真正写入数据库。
**未决:**
连接从预留升为排它前,需要先升为未决,这时其它连接就不能获得共享锁了,但已经拥有共享锁的连接仍然可以继续正常读数据库,此时,**拥有未决锁的连接等待其它拥有共享锁的连接完成工作并释放其共享锁后,提成到排它锁。**
**排它:**
连接需要提交修改时,需要将预留锁升为排它锁,这时其它连接都无法获得任何锁,直到当前连接的排它状态结束。
## 读写锁
当执行[select](https://so.csdn.net/so/search?q=select&spm=1001.2101.3001.7020)即读操作时,需要获取到SHARED锁(共享锁),
当执行[insert](https://so.csdn.net/so/search?q=insert&spm=1001.2101.3001.7020)/update/delete操作(即内存写操作时),需要进一步获取到RESERVERD锁(保留锁),
当进行commit操作(即磁盘写操作时),需要进一步获取到EXCLUSIVE锁(排它锁)。
* 对于RESERVERD锁,sqlite3保证同一时间只有一个连接可以获取到保留锁,也就是同一时间只有一个连接可以写数据库(内存),但**是其它连接仍然可以获取SHARED锁**,也就是其它连接仍然可以进行读操作(这里可以认为写操作只是对磁盘数据的一份内存拷贝进行修改,并不影响读操作)。
*
* 对于EXCLUSIVE锁,是比保留锁更为严格的一种锁,在需要把修改写入磁盘即commit时需要在保留锁/未决锁的基础上进一步获取到排他锁,顾名思义,排他锁排斥任何其它类型的锁,即使是SHARED锁也不行,所以,在一个连接进行commit时,[其它连接是不能做任何操作的]()(包括读)。
*
* PENDING锁(即未决锁),则是比较特殊的一种锁,它可以允许已获取到SHARED锁的事务继续进行,但不允许其它连接再获取SHARED锁,当已存在的SHARED锁都被释放后(事务执行完成),持有未决锁的事务就可以获得commit的机会了。sqlite3使用这种锁来防止writer starvation(写饿死)。
## 事务死锁
![](https://img.kancloud.cn/0c/f7/0cf74ffa190be3b0c9d958ae9bf4c1eb_601x647.png)
死锁的情况
死锁的情况:当两个连接使用begin transaction开始事务时,
第一个连接执行了一次select操作(已经获取到SHARED锁),
第二个连接执行了一次insert操作(已经获取到了RESERVERD锁),
此时第一个连接需要进行一次insert/[update](https://so.csdn.net/so/search?q=update&spm=1001.2101.3001.7020)/delete(需要获取到RESERVERD锁),
第二个连接则希望执行commit(需要获取到EXCLUSIVE锁),由于第二个连接已经获取到了RESERVERD锁,根据RESERVERD锁同一时间只有一个连接可以获取的特性,第一个连接获取RESERVERD锁的操作必定失败,
而由于第一个连接已经获取到SHARED锁,第二个连接希望进一步获取到EXCLUSIVE锁的操作也必定失败。就导致了事务死锁。
事务类型的使用原则
在用”begin transaction”显式开启一个事务时,默认的事务类型为DEFERRED,锁的状态为UNLOCKED,即不获取任何锁,如果在使用的数据库没有其它的连接,用begin就可以了。如果有多个连接都需要对数据库进行写操作,那就得使用BEGIN IMMEDIATE/EXCLUSIVE开始事务了。
使用事务的好处是:
1.一个事务的所有操作相当于一次原子操作,如果其中某一步失败,可以通过回滚来撤销之前所有的操作,只有当所有操作都成功时,才进行commit,保证了操作的原子特性;
2.对于多次的数据库操作,如果我们希望提高数据查询或更新的速度,可以在开始操作前显式开启一个事务,在执行完所有操作后,再通过一次commit来提交所有的修改或结束事务。
# 参考资料
[Sqlite3并发读写注意事项](https://blog.csdn.net/hqfok/article/details/75020563)
[SQLite 锁机制与事务简介](https://www.jianshu.com/p/8b0d70191b87)
- Android
- 四大组件
- Activity
- Fragment
- Service
- 序列化
- Handler
- Hander介绍
- MessageQueue详细
- 启动流程
- 系统启动流程
- 应用启动流程
- Activity启动流程
- View
- view绘制
- view事件传递
- choreographer
- LayoutInflater
- UI渲染概念
- Binder
- Binder原理
- Binder最大数据
- Binder小结
- Android组件
- ListView原理
- RecyclerView原理
- SharePreferences
- AsyncTask
- Sqlite
- SQLCipher加密
- 迁移与修复
- Sqlite内核
- Sqlite优化v2
- sqlite索引
- sqlite之wal
- sqlite之锁机制
- 网络
- 基础
- TCP
- HTTP
- HTTP1.1
- HTTP2.0
- HTTPS
- HTTP3.0
- HTTP进化图
- HTTP小结
- 实践
- 网络优化
- Json
- ProtoBuffer
- 断点续传
- 性能
- 卡顿
- 卡顿监控
- ANR
- ANR监控
- 内存
- 内存问题与优化
- 图片内存优化
- 线下内存监控
- 线上内存监控
- 启动优化
- 死锁监控
- 崩溃监控
- 包体积优化
- UI渲染优化
- UI常规优化
- I/O监控
- 电量监控
- 第三方框架
- 网络框架
- Volley
- Okhttp
- 网络框架n问
- OkHttp原理N问
- 设计模式
- EventBus
- Rxjava
- 图片
- ImageWoker
- Gilde的优化
- APT
- 依赖注入
- APT
- ARouter
- ButterKnife
- MMKV
- Jetpack
- 协程
- MVI
- Startup
- DataBinder
- 黑科技
- hook
- 运行期Java-hook技术
- 编译期hook
- ASM
- Transform增量编译
- 运行期Native-hook技术
- 热修复
- 插件化
- AAB
- Shadow
- 虚拟机
- 其他
- UI自动化
- JavaParser
- Android Line
- 编译
- 疑难杂症
- Android11滑动异常
- 方案
- 工业化
- 模块化
- 隐私合规
- 动态化
- 项目管理
- 业务启动优化
- 业务架构设计
- 性能优化case
- 性能优化-排查思路
- 性能优化-现有方案
- 登录
- 搜索
- C++
- NDK入门
- 跨平台
- H5
- Flutter
- Flutter 性能优化
- 数据跨平台