Heisenbug: o que é, por que ocorre e métodos para capturá-lo

O que é um Heisenbug no desenvolvimento móvel?

Heisenbug — uma classe de erros que se manifestam em produção ou durante a operação normal, mas desaparecem ao tentar reproduzi-los em um ambiente de depuração. O termo foi cunhado na década de 1980 pelo programador Jim Gray no contexto de sistemas distribuídos, mas é mais relevante hoje para aplicativos móveis devido à sua natureza assíncrona.

A principal razão: as ferramentas padrão de depuração alteram o ambiente de execução. Um breakpoint pausa a thread por vários milissegundos, o logging adiciona E/S síncrona, verificações adicionais alteram a ordem das operações. Em um ambiente multithread, mesmo um atraso de microssegundo pode alterar a ordem de execução das threads e ocultar uma data race.

De acordo com a Microsoft Research (2022), cerca de 15-25% de todos os bugs em aplicativos móveis multithread são classificados como Heisenbug. Ao mesmo tempo, o tempo para encontrar e corrigir um Heisenbug é em média 5 a 10 vezes maior do que um bug normal, devido à impossibilidade de reprodução direta.

Exemplo de Heisenbug

Um aplicativo trava em produção ao deslizar rapidamente por uma lista, mas ao conectar ao depurador ou adicionar logs — funciona perfeitamente. Causa: uma data race entre a thread de UI (atualizando RecyclerView) e a thread de fundo (atualizando dados do adaptador). Os logs adicionam um atraso que sincroniza as threads aleatoriamente.

Bohrbug, Mandelbug, Heisenbug: Classificação de bugs

Bohrbug — um bug previsível, estavelmente reproduzível. Nomeado por analogia com o modelo atômico de Bohr: como um átomo, o bug se comporta da mesma forma toda vez que é observado. Exemplo: NullPointerException ao clicar em um botão antes de carregar os dados. Tratado com testes unitários padrão.

Mandelbug — um bug com uma relação causal complexa e caótica (nomeado por analogia com o conjunto de Mandelbrot). Manifesta-se apenas sob uma certa combinação de condições: versão do SO, modelo do dispositivo, estado da rede. Difere do Heisenbug por não desaparecer durante a depuração — o problema é a dificuldade de reprodução, não a mudança de comportamento pelas ferramentas.

Heisenbug — um bug que desaparece precisamente por causa das ferramentas de depuração. Se você adicionar um log — o bug desaparece. Se você colocar um breakpoint — o bug não se manifesta. Se você remover tudo — o bug retorna. A principal causa: alteração do timing durante a depuração.

Principais causas do Heisenbug

Race condition — a causa número um do Heisenbug. Duas threads acessam dados compartilhados sem sincronização. O depurador introduz um atraso, fazendo com que as threads se sincronizem naturalmente. Sem o depurador, a ordem de execução é imprevisível.

Erros dependentes de timing — bugs que se manifestam apenas em uma certa velocidade de execução. Por exemplo, uma animação que deve terminar antes do início da próxima operação. No depurador, a animação é mais lenta e a operação tem tempo de começar após o término da animação. Em produção — o oposto.

// Example race condition — typical Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

    fun loadFromNetwork() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = api.fetchItems()
            items.addAll(result) // ❌ Not thread-safe
        }
    }

    fun getItems(): List<String> = items.toList()
    // Race condition: getItems read may overlap with loadFromNetwork write
}

Otimização do compilador — o compilador (JIT, ART, Kotlin/Native) pode reordenar instruções para otimização. Em uma compilação de depuração (debug build), as otimizações estão desativadas e o código executa «como foi escrito». Em uma compilação de lançamento (release build), o compilador altera a ordem das operações, o que pode revelar suposições ocultas no código.

• ThreadLocal — uso incorreto de variáveis thread-local que não são visíveis para outras threads
• Variáveis não inicializadas — código que depende de valores padrão de campos de classe
• Filas GCD/dispatch — no iOS, ordem indefinida de execução de blocos em filas concorrentes
• E/S com buffer — dados não são gravados no disco até que o buffer esteja cheio

Estratégias para capturar bugs elusivos

ThreadSanitizer (TSan) — uma ferramenta do Google para detectar data races em C/C++ e Kotlin/Native. Incorporada na compilação e detecta qualquer acesso à memória compartilhada sem sincronização. Ao contrário dos logs, o TSan não afeta o timing porque funciona através de código instrumentado, não de E/S.

Testes determinísticos — substitua a assincronia real por assincronia controlada. Use TestDispatcher (Kotlin), RxJava Plugins ou filas de teste GCD (iOS) para controle total sobre a ordem de execução. Especifique cenários concretos: a thread A executa, depois B, depois A novamente.

Logging cíclico — registro em um buffer circular na memória (não em disco). Quando o bug ocorre, o buffer é salvo em um arquivo. Como escrever na memória leva nanossegundos (em vez de milissegundos para E/S de disco), esse registro não afeta o timing e não mascara o Heisenbug.

class CyclicBuffer(val capacity: Int = 1000) {
    private val buffer = ArrayDeque<String>(capacity)
    private val lock = Any()

    fun log(message: String) {
        synchronized(lock) {
            if (buffer.size >= capacity) buffer.removeFirst()
            buffer.addLast(message)
        }
    }

    fun flush() {
        synchronized(lock) { buffer.forEach { fileWriter.write(it) } }
    }
}

Logging em produção — se o bug não for reproduzível localmente, colete dados em produção. Use logs do Firebase Crashlytics, Sentry Breadcrumbs ou um logger cíclico personalizado. Importante: o logging deve ser assíncrono e ter impacto mínimo no desempenho.

Prevenção de Heisenbug no nível da arquitetura

Isolamento de estado — minimize o estado mutável compartilhado. Cada componente deve ter seu próprio estado isolado, inacessível para escrita direta de outros componentes. Use Unidirectional Data Flow (UDF) — o estado flui em uma direção: Evento → Redutor → Estado → UI.

Abordagem funcional — funções puras sem efeitos colaterais são mais fáceis de testar e depurar. Isole os efeitos colaterais (rede, BD, arquivos) em camadas estritamente definidas (repositório, fonte de dados). Erros de concorrência em código funcional são praticamente impossíveis.

Modo estrito — ative o Android StrictMode na compilação de depuração. Ele detecta violações da política de threads (rede na thread principal, E/S de disco na thread principal) e lança uma exceção. Isso transforma um potencial Heisenbug em um Bohrbug determinístico que é imediatamente visível.

class DebugApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork()
                    .penaltyLog()
                    .build()
            )
        }
    }
}

Revisão de código com foco em assincronia — uma parte obrigatória do processo. Cada pull request deve ser verificado quanto a estado mutável compartilhado, coleções não seguras para threads e falta de sincronização. Use regras lint para proibir automaticamente certos padrões (por exemplo, acessar MutableList sem synchronized).