已锁定等待@synchronized

Question

我有一个(罕见的)奇怪的情况，我的objective-c iOS程序被锁住了。当我进入调试器时，有两个线程，它们都停留在@synchronized()上。

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

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

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

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

Answer 1

我知道我来晚了，但我发现了一种奇怪的情况组合，@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持有，因此它会排队等待，直到锁可用，并且blocks.
3. Thread 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.");

Answer 2

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

我继续研究_dataLock对象，在我的设计中，我有几个Database对象，它们将独立地进行锁定，所以我只是为每个Database实例创建_dataLock = [[NSNumber numberWithInt:1] retain]。

然而，[NSNumber numberWithInt:1]返回相同的对象，就像在相同的指针中一样！

这意味着我认为只有一个Database实例的本地化锁并不是所有Database实例的全局锁。

当然，这从来不是预期的设计，我相信这就是问题的原因。

我将更改

_dataLock = [[NSNumber numberWithInt:1] retain] 

使用

_dataLock = [[NSUUID UUID] UUIDString] retain]