FMDB 在多线程中的使用

在App中保持一个FMDatabaseQueue的实例，并在所有的线程中都只使用这一个实例。

[FMDatabaseQueue databaseQueueWithPath:path];

FMDatabaseQueue虽然看似一个队列，实际上它本身并不是，它通过内部创建一个Serial的dispatch_queue_t来处理通过inDatabase和inTransaction传入的Blocks，所以当我们在主线程（或者后台）调用inDatabase或者inTransaction时，代码实际上是同步的。FMDatabaseQueue这么设计的目的是让我们避免发生并发访问数据库的问题，因为对数据库的访问可能是随机的（在任何时候）、不同线程间（不同的网络回调等）的请求。内置一个Serial队列后，FMDatabaseQueue就变成线程安全了，所有的数据库访问都是同步执行，而且这比使用@synchronized或NSLock要高效得多。

但是这么一来就有了一个问题：如果后台在执行大量的更新，而主线程也需要访问数据库，虽然要访问的数据量很少，但是在后台执行完之前，还是会阻塞主线程。
对此，robertmryan给出了一些想法：

1. 如果你是在后台使用的inDatabase来执行更新，可以考虑换成inTransaction，后者比前者更新起来快很多，特别是在更新量比较大的时候（比如更新1000条或10000条）。
2. 拆解你的更新数据量，如果有300条，可以分10次、每次更新30条。当然有时不能这么做，因为你可能通过网络请求回来的数据，你希望一次性、完整地写入到数据库中，虽然有局限性，不过这确实能很好地减少每个Block占用数据库的时间。
3. 上面两点可以改善问题，但是问题依然是存在的，在大多数时候，你应该把从主线程调用inDatabase和inTransaction放在异步里：

   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
       [self.databaseQueue inDatabase:^(FMDatabase *db) {
           //do something...
       }];
   });

   这种方式能解决不依赖于数据库返回的结果的情况，如果对返回结果有依赖，就需要考虑UI上的体验了，如加一个UIActivityIndicatorView。