盒子
盒子

记一个多线程锁的bug

2018.11.09 林嘉伟

测试报了个问题,说我们的应用在退出之后,立即重新启动会无效,必须等几秒之后才能正常启动。

追踪代码之后发现问题出在对一个资源的获取上。我们的应用在启动的时候需要获取一个设备资源,但是这个设备资源在程序退出之后几秒才被释放。导致在这几秒内重新启动程序的话就会获取设备资源失败。

程序的大概逻辑如下:

  1. 获取到设备之后会起一个子线程,不断从设备中读取数据,然后分发给上层
  2. 退出的时候需要关闭这个子线程,并且释放设备资源
  3. 为了防止正在从设备中读取的时候释放设备,需要加锁保护

读取数据的代码如下:

1
2
3
4
5
6
7
8
9
10
//在子线程中起一个死循环不断从设备读取数据
while (true) {
    synchronized (mLock) {
        if (Thread.currentThread().isInterrupted()) {
            break;
        }

        // 从设备中读取数据并且分发
    }
}

退出的时候会退出子线程,并且释放设备资源:

1
2
3
4
synchronized (mLock) {
    mWorkThread.interrupt();
    // 释放设备资源
}

乍一看是没有问题的,但是实际加上打印的话会发现,子线程的while在做完一个循环释放锁之后,又立马抢占了锁。导致在退出的时候迟迟不能获取到锁,一直阻塞在那。大概四五秒之后才拿到锁,打断子线程的死循环。

这位前辈不小心踩到了个坑: synchronized是非公平锁。

也就是说,当两个线程在竞争一个锁的时候,系统并不会公平的将锁你一次我一次的依次给两个线程,而是随机的给一个线程,并且比较大的概率是给上次获得锁的线程。这样就导致while循环里一直抢占锁资源,这样退出的那个代码块就一直被阻塞在那里了。

暗暗欣喜自己之前的书没有白看,立马就想到关键原因。于是大手一挥,公平锁伺候:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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去了。

吃过午饭,缓了缓神,诈尸般反应过来。我也被带坑里去了!

为什么一定要用加锁的方法?这锁一加,代码的执行效率怎么办？

赶紧再改:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//在子线程中起一个死循环不断从设备读取数据
while (true) {
    if (Thread.currentThread().isInterrupted()) {
        break;
    }

    // 从设备中读取数据并且分发
}
// 释放设备资源

...

//退出的时候会退出子线程
mWorkThread.interrupt();
mWorkThread.join(); // 用join去等待子线程退出,子线程在跳出while循环的时候会自己是否资源

解bug的时候还是需要有自己的思路才行,不能被有问题的代码影响,要不然最后往往不能彻底解决问题,甚至有可能继续埋坑。