做ios也有1年了,C#的东西有些都忘记了,最近几天也打算重温一下,不能学了ios把C#给抛弃了,两者都要抓,一精多专。目前C#只是重温,重点是web这块。今天主要是想起了之前做过的面试题,虽然题比较变态,但也有它的意义。
public void test(int i)
{
lock(this)
{
if (i > 10)
{
i--;
test(i);
}
}
}
根据线程安全的相关知识,分析以下代码,当调用test方法时i>10时是否会引起死锁?并简要说明理由。
想必做过C#面试过的都会遇到过这题,我记得我第一次面试做的时候也是做错了,想着递归中包含锁,肯定会死锁。
当时回去自己动手敲了一下,然并卵,没有死锁。后来又看了大学时的C#教材,又百度了下,发现自己把锁理解错了。我记得当时教材上举的例子是一个银行取款的例子。而在这道题中,一直都在主线程中,并没有开启第二个线程,怎么会发生锁呢。 我记得数据库中也有锁机制,锁主要是解决并发的问题,锁生成的原因主要有两个:同时争夺同一资源A、B同时要C,争夺资源时形成一个环状,A要B,B要C,C要A。
在百度搜了下,百度也有这个,解释如下:在《CLR via C#》第二版(中文版,清华大学出版社出版)的第530页中第7行找到了这样的描述:“同样需要引起注意的是线程可以递归拥有同步块”。即同一线程可以递归调用lock语句。
---------------华丽分割线-----------------------
刚才试了下oc中的NSLock,可是同样用上面的就会发生死锁的情况.
//
// Lock.h
// LockTest
//
// Created by City--Online on 16/2/3.
// Copyright 2016年 City--Online. All rights reserved.
//
#import <Foundation/Foundation.h>
@interface Lock : NSObject
@property (nonatomic,strong) NSLock *lock;
-(void) test:(int )i;
@end
#import "Lock.h"
@implementation Lock
-(void) test:(int )i
{
[self.lock lock];
if (i > 10)
{
i--;
NSLog(@"%d",i);
[self test:i];
}
[self.lock unlock];
}
-(NSLock *)lock
{
if (!_lock) {
_lock=[[NSLock alloc]init];
}
return _lock;
}
@end
2016-02-03 15:17:19.435 LockTest[16870:213115] 10
2016-02-03 15:17:19.436 LockTest[16870:213115] *** -[NSLock lock]: deadlock (<NSLock: 0x100106bf0> '(null)')
2016-02-03 15:17:19.436 LockTest[16870:213115] *** Break on _NSLockError() to debug.
百度了下原来还有一个锁来解决这个的NSRecursiveLock
将上面的NSLock改为NSRecursiveLock,就解决了。具体参考http://www.cocoachina.com/ios/20150513/11808.html
2016-02-03 15:22:23.627 LockTest[17165:219724] 10
Program ended with exit code: 0
NSRecursiveLock可以允许同一线程多次加锁,而不会造成死锁。递归锁会跟踪它被lock的次数。每次成功的lock都必须平衡调用unlock操作。只有所有达到这种平衡,锁最后才能被释放,以供其它线程使用。
NSLock每次进入都会去加一次锁,而从第二次开始,由于锁已经被使用了且没有解锁,所以它需要等待锁被解除,这样就导致了死锁,线程被阻塞住了。两者实现的机制可能不一样,这个还要请哪个大神指点。