3

我有这个（罕见的）奇怪的情况，我的 Objective-c iOS 程序被锁定。当我闯入调试器时，有两个线程，它们都卡在@synchronized() 处。

除非我完全误解了@synchronized，否则我认为这是不可能的，也是命令的全部意义所在。

我有一个主线程和工作线程，它们都需要访问 sqlite 数据库，所以我将访问数据库的代码块包装在 @synchronized(myDatabase) 块中。除了 db 访问之外，这些块中没有发生太多其他事情。

我也在使用 FMDatabase 框架来访问 sqlite，我不知道这是否重要。

myDatabase 是一个包含 FMDatabase 对象的全局变量。它在程序开始时创建一次。

4

2 回答 2

5

我知道我迟到了，但我发现了一种奇怪的情况组合，@synchronized处理不好，可能是你的问题的原因。除了更改代码以消除原因之外，我没有解决方案，一旦您知道它是什么。

我将在下面使用此代码进行演示。

- (int)getNumberEight {
    @synchronized(_lockObject) {
        // Point A
        return 8;
    }
}

- (void)printEight {
    @synchronized(_lockObject) {
        // Point B
        NSLog(@"%d", [self getNumberEight]);
    }
}

- (void)printSomethingElse {
    @synchronized(_lockObject) {
        // Point C
        NSLog(@"Something Else.");
    }
}

通常，@synchronized是递归安全锁。因此，调用[self printEight]是可以的，不会导致死锁。我发现的是该规则的一个例外。以下一系列事件将导致死锁并且极难追踪。

  1. 线程 1 进入-printEight并获取锁。
  2. 线程 2 进入-printSomethingElse并尝试获取锁。锁由线程 1 持有，因此它被排队等待直到锁可用并阻塞。
  3. 线程 1 进入-getNumberEight并尝试获取锁。锁已经被持有，并且其他人在队列中以获取它，因此线程 1 阻塞。僵局。

看来，此功能是在使用@synchronized. 只有当没有其他线程在等待它时，锁才是递归安全的。

下次您在代码中遇到死锁时，请检查每个线程上的调用堆栈，以查看是否有任何一个死锁线程已经持有锁。在上面的示例代码中，通过在 A、B 和 C 点添加长时间休眠，可以以几乎 100% 的一致性重新创建死锁。

编辑：

我不再能够演示上一个问题，但是有一个相关的情况仍然会导致问题。它与 的动态行为有关dispatch_sync。

在这段代码中，有两次尝试以递归方式获取锁。第一次调用从主队列进入后台队列。第二个调用从后台队列进入主队列。

导致行为差异的原因是调度队列和线程之间的区别。第一个示例调用不同的队列，但从不更改线程，因此获取了递归互斥锁。第二个在更改队列时更改线程，因此无法获取递归互斥锁。

需要强调的是，此功能是设计使然，但对于一些不太了解 GCD 的人来说，它的行为可能是出乎意料的。

dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
NSObject *lock = [[NSObject alloc] init];
NSTimeInterval delay = 5;

NSLog(@"Example 1:");
dispatch_async(queue, ^{
    NSLog(@"Starting %d seconds of runloop for example 1.", (int)delay);
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:delay]];
    NSLog(@"Finished executing runloop for example 1.");
});
NSLog(@"Acquiring initial Lock.");
@synchronized(lock) {
    NSLog(@"Acquiring recursive Lock.");
    dispatch_sync(queue, ^{
        NSLog(@"Deadlock?");
        @synchronized(lock) {
            NSLog(@"No Deadlock!");
        }
    });
}

NSLog(@"\n\nSleeping to clean up.\n\n");
sleep(delay);

NSLog(@"Example 2:");
dispatch_async(queue, ^{
    NSLog(@"Acquiring initial Lock.");
    @synchronized(lock) {
        NSLog(@"Acquiring recursive Lock.");
        dispatch_sync(dispatch_get_main_queue(), ^{
            NSLog(@"Deadlock?");
            @synchronized(lock) {
                NSLog(@"Deadlock!");
            }
        });
    }
});

NSLog(@"Starting %d seconds of runloop for example 2.", (int)delay);
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:delay]];
NSLog(@"Finished executing runloop for example 2.");
于 2013-10-17T14:43:33.497 回答
0

我最近偶然发现了这个，假设它@synchronized(_dataLock)做了它应该做的事情，因为它毕竟是一个基本的事情。

我继续调查该_dataLock对象，在我的设计中，我有几个Database对象将独立进行锁定，所以我只是_dataLock = [[NSNumber numberWithInt:1] retain]为每个Database.
但是[NSNumber numberWithInt:1]返回相同的对象，就像在相同的指针中！！！

这意味着我认为只有一个实例的本地化锁Database不是所有实例的全局锁Database。
当然，这从来都不是预期的设计，我相信这是问题的根源。

我会改变

_dataLock = [[NSNumber numberWithInt:1] retain]

和

_dataLock = [[NSUUID UUID] UUIDString] retain]
于 2015-11-23T17:32:01.323 回答