测试报了个问题,说我们的应用在退出之后,立即重新启动会无效,必须等几秒之后才能正常启动。
追踪代码之后发现问题出在对一个资源的获取上。我们的应用在启动的时候需要获取一个设备资源,但是这个设备资源在程序退出之后几秒才被释放。导致在这几秒内重新启动程序的话就会获取设备资源失败。
程序的大概逻辑如下:
- 获取到设备之后会起一个子线程,不断从设备中读取数据,然后分发给上层
- 退出的时候需要关闭这个子线程,并且释放设备资源
- 为了防止正在从设备中读取的时候释放设备,需要加锁保护
读取数据的代码如下:
//在子线程中起一个死循环不断从设备读取数据
while (true) {
synchronized (mLock) {
if (Thread.currentThread().isInterrupted()) {
break;
}
// 从设备中读取数据并且分发
}
}
退出的时候会退出子线程,并且释放设备资源:
synchronized (mLock) {
mWorkThread.interrupt();
// 释放设备资源
}
乍一看是没有问题的,但是实际加上打印的话会发现,子线程的while在做完一个循环释放锁之后,又立马抢占了锁。导致在退出的时候迟迟不能获取到锁,一直阻塞在那。大概四五秒之后才拿到锁,打断子线程的死循环。
这位前辈不小心踩到了个坑: synchronized是非公平锁。
也就是说,当两个线程在竞争一个锁的时候,系统并不会公平的将锁你一次我一次的依次给两个线程,而是随机的给一个线程,并且比较大的概率是给上次获得锁的线程。这样就导致while循环里一直抢占锁资源,这样退出的那个代码块就一直被阻塞在那里了。
暗暗欣喜自己之前的书没有白看,立马就想到关键原因。于是大手一挥,公平锁伺候:
private final ReentrantLock mLock = new ReentrantLock(true);
...
//在子线程中起一个死循环不断从设备读取数据
while (true) {
mLock.lock();
if (Thread.currentThread().isInterrupted()) {
break;
}
// 从设备中读取数据并且分发
mLock.unlock();
}
...
//退出的时候会退出子线程,并且释放设备资源
mLock.lock();
mWorkThread.interrupt();
// 释放设备资源
mLock.unlock();
验证ok,继续解别的bug去了。
吃过午饭,缓了缓神,诈尸般反应过来。我也被带坑里去了!
为什么一定要用加锁的方法?这锁一加,代码的执行效率怎么办？
赶紧再改:
//在子线程中起一个死循环不断从设备读取数据
while (true) {
if (Thread.currentThread().isInterrupted()) {
break;
}
// 从设备中读取数据并且分发
}
// 释放设备资源
...
//退出的时候会退出子线程
mWorkThread.interrupt();
mWorkThread.join(); // 用join去等待子线程退出,子线程在跳出while循环的时候会自己是否资源
解bug的时候还是需要有自己的思路才行,不能被有问题的代码影响,要不然最后往往不能彻底解决问题,甚至有可能继续埋坑。
