第九块石头

多线程下使用FMDB进行数据库访问和死锁问题

| Comments

多线程访问数据库本身就存在分险,容易形成脏数据。幸好FMDB这个第三方库支持了多线程访问,从而解决了脏数据问题。然而也带来了死锁问题……

先看看FMDB的多线程机制的原理。

看了它的代码,发现其实很简单的一个思路,但是实现起来还真不容易,难怪花了好长时间才支持多线程!!它是生成一个请求队列,将一次事务进行封装放在队列中,只有一个事务完成了,才会进行下一个事务。这就出现了一种现象:如果某一个请求耗时过大,将会导致所有请求堵塞!!同时也要求:同一个线程中,在一个事务完成之前,不能进行下一个事务。

举个例子:

1
2
3
4
5
[self.dbQueue inTransaction:^(FMDatabase *db, BOOL *rollback) {
    if ([db executeUpdate:sql]) {
        [self increaseCounter];
    }
}];

这个方法在执行sql成功后,将会调用increaseCounter方法:

1
2
3
4
5
- (void)increaseCounter {
    [self.dbQueue inTransaction:^(FMDatabase *db, BOOL *rollback) {
        [db executeQuery:@"insert ..."];
    }];
}

而increaseCounter方法中又增加一个事务,去执行另外一个sql语句。

结果出现了这种现象:

第一个事务没结束,第二个事务等待第一个事务结束,而第一个事务等待第二个事务返回状态,出现死锁!!

正确的写法:

1
2
3
4
5
6
7
__block BOOL status = NO;
[self.dbQueue inTransaction:^(FMDatabase *db, BOOL *rollback) {
    status = [db executeUpdate:sql];
}];
if (status) {
    [self increaseCounter];
}

也就是将两个事务拆开。

总结:

  • 多线程编程应该尽量采用事务队列
  • 事务队列与Mysql等的锁数据库效果相似,即事务完成前,其他线程以及本线程不能访问数据库(注意不是锁表,是锁库
  • 一个事务内应该只包含数据库请求语句,不应当包含其他逻辑
  • 一个请求不应耗时过长,否则出现线程等待

Comments

comments powered by Disqus