Mutex em aplicativos móveis — o que é, princípio de funcionamento e aplicação de exclusão mútua

O que é Mutex?

Mutex (abreviação de Mutual Exclusion — exclusão mútua) é um objeto de sincronização que gerencia o acesso a um recurso compartilhado em um ambiente multithread. Quando uma thread entra em uma seção crítica, ela adquire o Mutex. Se outra thread tenta adquirir o mesmo Mutex, ela é colocada em estado de espera até que o lock seja liberado pela primeira thread.

A arquitetura do Mutex remonta ao sistema operacional THE, projetado por Edsger Dijkstra em 1965. Dijkstra introduziu o conceito de semáforos, dos quais o Mutex surgiu posteriormente como um caso especial — um semáforo binário com suporte a propriedade. SOs modernos (Linux, Windows, Android) implementam Mutex no nível do kernel, garantindo sincronização correta mesmo entre processos diferentes.

A propriedade chave do Mutex é a propriedade (ownership). Apenas a thread que adquiriu o mutex pode liberá-lo. Isso distingue o Mutex de um semáforo binário, onde qualquer thread pode realizar um sinal (operação V). A propriedade impede a liberação acidental do lock por outra thread, tornando o Mutex mais seguro para cenários típicos de sincronização no desenvolvimento móvel. De acordo com Android Developer Docs (Processes and Threads, 2024), usar Mutex em vez de synchronized pode melhorar o desempenho em 30% sob alta contenção.

Como funciona o Mutex

Estados e operações

Um Mutex está em um de dois estados: bloqueado (locked) — adquirido por uma thread; ou livre (unlocked) — não adquirido. Existem duas operações básicas: lock() (adquirir) e unlock() (liberar). Se o Mutex já estiver bloqueado, a thread que chama lock() é bloqueada até que o lock seja liberado. Na JVM, uma thread bloqueada transita para o estado BLOCKED e não consome CPU.

Escalonamento de threads em espera

Quando um Mutex é liberado, o sistema seleciona qual thread em espera recebe o lock. Com escalonamento não justo (non-fair), a escolha pode recair sobre a thread que acabou de liberar o mutex — isso aumenta a taxa de transferência mas pode levar à inanição (Starvation). Um escalonador justo (fair) usa uma fila FIFO: a primeira thread em espera recebe o lock primeiro. ReentrantLock(true) implementa exatamente esse mecanismo.

Aquisição recursiva (Reentrância)

A maioria das implementações de Mutex em Java/Kotlin suporta aquisição reentrante. Se uma thread já possui o Mutex e chama lock() novamente, a operação é bem-sucedida — o Mutex não bloqueia a si mesmo. O contador de recursão aumenta, e a thread deve chamar unlock() tantas vezes quanto lock(). Isso é importante para chamadas recursivas e seções críticas aninhadas.

Exemplo de uso de Mutex em Kotlin

Vamos considerar uma tarefa típica — proteger um contador compartilhado de condições de corrida usando ReentrantLock (Mutex clássico em Java/Kotlin). Sem Mutex, o código produziria resultados incorretos; com Mutex, todas as 1000 threads incrementam de forma confiável o valor do contador.

import java.util.concurrent.locks.ReentrantLock

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

    fun increment() {
        mutex.lock()
        try {
            count++  // seção crítica
        } finally {
            mutex.unlock()  // finally obrigatório
        }
    }

    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())  // Sempre 1000
}

Preste atenção ao bloco finally — um padrão obrigatório ao trabalhar com Mutex. Se ocorrer uma exceção dentro da seção crítica, unlock() não será chamado e o Mutex permanecerá bloqueado para sempre — isso leva a um Deadlock. O bloco finally garante a liberação do Mutex independentemente de como a execução da seção termina.

Uma abordagem alternativa em Kotlin é usar a função de extensão withLock, que lida automaticamente com lock/unlock com finally.

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

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

Mutex vs Semáforo vs Monitor

Esses três mecanismos de sincronização são frequentemente confundidos, embora tenham propriedades e casos de uso diferentes. Mutex é binário com propriedade. Semáforo é um contador de permissões sem propriedade. Monitor é um mecanismo de alto nível que combina Mutex com variáveis de condição. Entender as diferenças é criticamente importante para escolher a ferramenta certa para uma tarefa específica.

Quando escolher Mutex: você precisa proteger um único recurso de acesso concorrente — por exemplo, uma coleção compartilhada, arquivo ou contador. Quando escolher Semáforo — você precisa limitar o número de acessos concorrentes a um pool de recursos, como um pool de conexões de banco de dados com 5 conexões. Quando escolher Monitor — você precisa de sincronização com espera condicional, como uma fila produtor-consumidor via wait/notify. No desenvolvimento Android moderno, synchronized é frequentemente substituído por ReentrantLock ou kotlinx.coroutines Mutex.

Erros comuns ao usar Mutex

Esquecer unlock no finally

O erro mais comum é a falta do bloco finally para chamar unlock(). Se ocorrer uma exceção na seção crítica, o Mutex permanece bloqueado e outras threads esperam para sempre. Mesmo se você tiver certeza de que exceções são impossíveis — sempre use try/finally ou withLock. Este é um princípio de programação defensiva, especialmente importante no desenvolvimento móvel onde exceções podem surgir devido à falta de memória ou Configuration Changes.

Ordem diferente de aquisição de Mutex

Quando uma aplicação usa múltiplos Mutexes, é criticamente importante estabelecer uma ordem de aquisição consistente. Se a Thread A adquire M1 → M2, e a Thread B adquire M2 → M1, ocorre um Deadlock. Em projetos grandes (mais de 50 mil linhas de código), a ordem dos locks é documentada na decisão arquitetural e verificada por linters. A ferramenta Lock Checker no IntelliJ IDEA detecta automaticamente a ordem inconsistente de aquisição de locks.

Seção crítica muito longa

Segurar um Mutex por mais de 1-2 milissegundos é sinal de design inadequado. A seção crítica deve conter apenas as operações mínimas necessárias. Requisições de rede, E/S de arquivos e cálculos complexos devem ser realizados fora do bloco bloqueado. No Android, segurar um lock prolongadamente na thread da UI leva à perda de quadros (jank) e ANR. Use ReadWriteLock se a seção crítica consiste principalmente de operações de leitura.

Mutex em Kotlin Coroutines

A biblioteca kotlinx.coroutines fornece sua própria implementação de Mutex, que difere fundamentalmente do ReentrantLock clássico. A principal diferença é que suspending Mutex não bloqueia a thread do SO, mas suspende a corrotina até que o lock seja liberado. Isso significa que a thread pode executar outras corrotinas enquanto a atual espera pelo 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 — não bloqueia a thread
            count++
        }
    }

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

Características principais do kotlinx Mutex: não reentrante (non-reentrant) — ao contrário do ReentrantLock, uma corrotina não pode readquirir um Mutex que já possui. Se isso for necessário, use Semaphore(1) em vez de Mutex. Além disso, Mutex do kotlinx.coroutines é não bloqueante: ele usa suspensão via suspend, permitindo não bloquear a thread do pool.

Na prática, suspending Mutex é preferível ao ReentrantLock clássico em código de corrotinas por duas razões: escalabilidade — uma corrotina espera pelo Mutex enquanto a thread atende outras corrotinas, aumentando a taxa de transferência do sistema; sem BlockedThread — nenhum recurso é gasto no armazenamento da pilha da thread bloqueada. De acordo com JetBrains (Kotlin Coroutines Guide, 2024), usar suspending Mutex melhora a taxa de transferência em 40% com 100+ corrotinas.