本文主要是介绍【腾讯Bugly干货分享】微信iOS SQLite源码优化实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/57b58022433221be01499480
作者：张三华
前言
随着微信iOS客户端业务的增长，在数据库上遇到的性能瓶颈也逐渐凸显。在微信的卡顿监控系统上，数据库相关的卡顿不断上升。而在用户侧也逐渐能感知到这种卡顿，尤其是有大量群聊、联系人和消息收发的重度用户。
我们在对SQLite进行优化的过程中发现，靠单纯地修改SQLite的参数配置，已经不能彻底解决问题。因此从6.3.16版本开始，我们合入了SQLite的源码，并开始进行源码层的优化。
本文将分享在SQLite源码上进行的多线程并发、I/O性能优化等，并介绍优化相关的SQLite原理。
多线程并发优化
1. 背景
由于历史原因，旧版本的微信一直使用单句柄的方案，即所有线程共有一个SQLite Handle，并用线程锁避免多线程问题。当多线程并发时，各线程的数据库操作同步顺序进行，这就导致后来的线程会被阻塞较长的时间。
2. SQLite的多句柄方案及Busy Retry方案
SQLite实际是支持多线程（几乎）无锁地并发操作。只需
- 开启配置
PRAGMA SQLITE_THREADSAFE=2 - 确保同一个句柄同一时间只有一个线程在操作
Multi-thread. In this mode, SQLite can be safely used by multiple threads provided that no single database connection is used simultaneously in two or more threads.
倘若再开启SQLite的WAL模式（Write-Ahead-Log），多线程的并发性将得到进一步的提升。
此时写操作会先append到wal文件末尾，而不是直接覆盖旧数据。而读操作开始时，会记下当前的WAL文件状态，并且只访问在此之前的数据。这就确保了多线程读与读、读与写之间可以并发地进行。
然而，阻塞的情况并非不会发生。
- 当多线程写操作并发时，后来者还是必须在源码层等待之前的写操作完成后才能继续。
SQLite提供了Busy Retry的方案，即发生阻塞时，会触发Busy Handler，此时可以让线程休眠一段时间后，重新尝试操作。重试一定次数依然失败后，则返回SQLITE_BUSY错误码。
这篇关于【腾讯Bugly干货分享】微信iOS SQLite源码优化实践的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
