移动应用中的Mutex — 什么是互斥锁、工作原理及互斥的应用

什么是Mutex？

Mutex（Mutual Exclusion的缩写 — 互斥）— 是一个同步对象，用于管理多线程环境中对共享资源的访问。当线程进入临界区时，它获取Mutex。如果另一个线程试图获取同一个Mutex，它将被转入等待状态，直到第一个线程释放锁。

Mutex的架构可以追溯到Edsger Dijkstra于1965年开发的THE操作系统。正是Dijkstra引入了信号量的概念，后来Mutex作为一个特例从中分离出来——带有所有权支持的二进制信号量。现代操作系统（Linux、Windows、Android）在内核级别实现Mutex，这确保了即使在不同进程之间的同步也能正确工作。

Mutex的关键属性是所有权（ownership）。只有获取了互斥锁的线程才能释放它。这使Mutex有别于二进制信号量，在二进制信号量中任何线程都可以执行信号（V操作）。所有权防止了另一个线程意外释放锁，这使得Mutex对于移动开发中的典型同步场景更加安全。根据Android开发者文档（进程和线程，2024），在高竞争条件下使用Mutex代替synchronized可以将性能提高30%。

Mutex如何工作

状态和操作

Mutex处于两种状态之一：已锁定（locked） — 被线程获取；空闲（unlocked） — 未被获取。两个基本操作——lock()（获取）和unlock()（释放）。如果Mutex已被获取，调用lock()的线程将被阻塞直到释放。在JVM中，被阻塞的线程进入BLOCKED状态，不消耗CPU。

等待线程的调度

当Mutex被释放时，系统选择哪个等待线程将获得锁。在不公平（non-fair）调度下，选择可能落在刚刚释放了互斥锁的线程上——这提高了吞吐量，但可能导致饥饿（Starvation）。公平（fair）调度器使用FIFO队列：第一个等待线程最先获得锁。ReentrantLock(true)正是实现了这种机制。

递归获取（Reentrancy）

Java/Kotlin中的大多数Mutex实现都支持递归（reentrant）获取。如果线程已经拥有Mutex并再次调用lock()，操作成功——Mutex不会阻塞自身。递归计数器增加，线程必须调用与lock()相同次数的unlock()。这对于递归调用和嵌套临界区很重要。

Kotlin中使用Mutex的示例

考虑一个典型任务——使用ReentrantLock（Java/Kotlin中的经典Mutex）保护共享计数器免受竞态条件的影响。没有Mutex，代码会给出不正确的结果；有了Mutex，所有1000个线程都能保证递增计数器的值。

import java.util.concurrent.locks.ReentrantLock

class MutexCounter {
    private val mutex = ReentrantLock()
    private var count = 0

    fun increment() {
        mutex.lock()
        try {
            count++  // 临界区
        } finally {
            mutex.unlock()  // 必需的finally
        }
    }

    fun getCount(): Int {
        mutex.lock()
        try {
            return count
        } finally {
            mutex.unlock()
        }
    }
}

fun main() = runBlocking {
    val counter = MutexCounter()
    val jobs = List(1000) {
        launch(Dispatchers.Default) {
            counter.increment()
        }
    }
    jobs.forEach { it.join() }
    println(counter.getCount())  // 总是1000
}

注意finally块——使用Mutex时的强制模式。如果在临界区内发生异常，unlock()将不会被调用，Mutex将永远保持锁定——这会导致死锁。finally块保证在任何执行结果下释放Mutex。

Kotlin中的替代方法——使用扩展函数withLock，它自动处理带有finally的lock/unlock。

fun increment() {
    mutex.withLock {  // lock + try/finally 自动
        count++
    }
}

fun getCount(): Int = mutex.withLock { count }

Mutex vs 信号量 vs 监视器

这三种同步机制经常被混淆，尽管它们具有不同的属性和应用领域。Mutex — 二进制，有所有权。信号量 — 许可计数器，无所有权。监视器 — 高级机制，将Mutex与条件变量（condition variables）结合起来。理解差异对于为特定任务选择正确的工具至关重要。

何时选择Mutex：需要保护一个资源免受同时访问——例如共享集合、文件或计数器。何时选择信号量——需要限制对资源池的同时访问数量，例如具有5个连接的数据库连接池。何时选择监视器——需要带有条件等待的同步，例如通过wait/notify的生产者-消费者队列。在现代Android开发中，synchronized经常被ReentrantLock或kotlinx.coroutines Mutex取代。

使用Mutex的常见错误

在finally中忘记解锁

最常见的错误——缺少finally块来调用unlock()。如果在临界区发生异常，Mutex将保持锁定，其他线程将永远等待。即使您确信异常不可能发生——始终使用try/finally或withLock。这是防御性编程的原则，在移动开发中尤为重要，因为异常可能由于内存不足或配置更改而发生。

不同的Mutex获取顺序

当应用程序中使用多个Mutex时，建立统一的获取顺序至关重要。如果线程A获取M1 → M2，而线程B获取M2 → M1，就会发生死锁。在大型项目（超过5万行代码）中，锁定顺序记录在架构决策中，并由linter检查。IntelliJ IDEA中的Lock Checker工具可以自动检测不一致的锁获取顺序。

临界区过长

持有Mutex超过1-2毫秒——设计不当的标志。临界区应仅包含最必要的操作。网络请求、文件输入输出和复杂计算应在锁定块之外执行。在Android中，在UI线程中长时间持有锁会导致丢帧（jank）和ANR。如果临界区主要由读取操作组成，请使用ReadWriteLock。

Kotlin协程中的Mutex

kotlinx.coroutines库提供了自己的Mutex实现，该实现与经典的ReentrantLock有着根本的不同。主要区别——挂起Mutex不会阻塞操作系统线程，而是挂起协程直到锁被释放。这意味着线程可以执行其他协程，而当前协程正在等待Mutex。

import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class CoroutineCounter {
    private val mutex = Mutex()
    private var count = 0

    suspend fun increment() {
        mutex.withLock {  // suspending — 不阻塞线程
            count++
        }
    }

    suspend fun getCount(): Int = mutex.withLock { count }
}

kotlinx Mutex的关键特性：不可重入（non-reentrant） — 与ReentrantLock不同，协程不能再次获取已经拥有的Mutex。如果需要，请使用Semaphore(1)代替Mutex。此外，kotlinx.coroutines中的Mutex是非阻塞的：它通过suspend使用挂起，这允许不阻塞池线程。

在实践中，挂起Mutex在协程代码中比经典ReentrantLock更受欢迎，原因有两个：可伸缩性 — 一个协程在等待Mutex，而线程服务于其他协程，这提高了系统的吞吐量；没有BlockedThread — 不会浪费资源来存储阻塞线程的栈。根据JetBrains（Kotlin协程指南，2024），使用挂起Mutex在100多个协程下可将吞吐量提高40%。