Android应用Kotlin协程Mutex解锁崩溃求助：IllegalStateException

根因分析 #

这个崩溃的核心就是没拿到Mutex锁就调用了unlock()。Mutex是互斥锁，只有当前持有锁的协程才能解锁，不然直接抛出这个异常。

难以复现的原因通常是多协程并发场景下的时序问题，比如：

• 协程A刚获取锁还在执行逻辑，协程B在某个分支里误调用了unlock()
• 锁的获取与解锁没有严格配对，比如在try-catch块里写了解锁，但lock()根本没成功就执行到了解锁步骤
• 不小心使用了不带检查的unlock()重载（不过默认版本都是带检查的，这种情况较少）

解决方案 #

1. 严格保证锁的获取与解锁配对 #

一定要用try-finally包裹锁的使用逻辑，确保只有成功获取锁后才会执行解锁：

val mutex = Mutex()

suspend fun safeOperation() {
    mutex.lock()
    try {
        // 执行需要同步的业务逻辑
    } finally {
        mutex.unlock()
    }
}

更推荐使用withLock()扩展函数，它内部已经封装了try-finally逻辑，能彻底避免配对失误：

suspend fun saferOperation() {
    mutex.withLock {
        // 执行需要同步的业务逻辑
    }
}

2. 排查并发分支的逻辑漏洞 #

逐个检查所有调用unlock()的代码位置，确认只有确定已经获取锁的情况下才会执行解锁操作。比如避免在条件分支里随意调用解锁，也不要在协程被取消后误触发解锁逻辑。

3. 增加调试日志定位问题 #

针对难以复现的场景，可以临时添加日志，记录锁的获取、解锁操作以及当前协程ID：

suspend fun debugOperation() {
    val coroutineId = Thread.currentThread().id
    Log.d("MutexDebug", "协程 $coroutineId 尝试加锁")
    mutex.lock()
    try {
        Log.d("MutexDebug", "协程 $coroutineId 加锁成功")
        // 业务逻辑
    } finally {
        Log.d("MutexDebug", "协程 $coroutineId 执行解锁")
        mutex.unlock()
    }
}

通过日志可以追踪异常发生时的协程执行时序，定位到哪个协程在未持锁的情况下调用了解锁。

4. 避免手动调用unlock() #

尽量用withLock()替代手动调用lock()和unlock()，减少人为失误的可能性。

内容的提问来源于stack exchange，提问作者eldartsa