Plugin IntelliJ travando: siga a cadeia de espera antes de mover o código

Autores de plugins passaram a ter acesso, na aba Freezes do JetBrains Marketplace, a relatórios de congelamento da interface atribuídos aos seus componentes.[7] A coleta depende de configuração no plugin, das opções do usuário e de a IDE identificar o componente como envolvido.[7] O recurso oferece evidências para casos difíceis de reproduzir, mas não entrega um diagnóstico pronto.

O ganho para o desenvolvedor é trocar uma descrição vaga de travamento por uma investigação sobre o que as threads realmente faziam. A diferença importa porque mover uma operação para segundo plano pode mudar o lugar do problema sem remover a espera.

O que muda para quem desenvolve

Os relatos semelhantes são agrupados e apresentam um trecho representativo de dump.[7] Quando disponíveis, os anexos incluem dumps completos capturados a cada cinco segundos, snapshot de CPU em JFR, análise de pilhas e métricas de desempenho em CSV.[7] Nem todo relatório contém todos esses arquivos.[7]

A orientação da JetBrains é começar pela thread de eventos, normalmente identificada como AWT-EventQueue-0, e distinguir trabalho caro de espera por outra operação.[7] O texto também descreve como uma ação de leitura longa e não cancelável em segundo plano pode reter um lock necessário para uma ação de escrita e bloquear a interface.[7]

Minha leitura é que o diagnóstico precisa preservar a relação entre as threads. Uma pilha da EDT mostra onde a interface parou; a explicação pode estar em outro componente que segura o recurso. A hipótese de correção deve ligar esses dois pontos, não apenas encontrar um método demorado.

Como aplicar

No mecanismo padrão, o artigo orienta registrar com.intellij.diagnostic.JetBrainsMarketplaceErrorReportSubmitter como tratador de erros em plugin.xml.[7] A implementação existe desde IntelliJ Platform 2023.3; em Split Mode, o registro precisa ficar no frontend ou em módulo compartilhado.[7]

Depois de habilitar a coleta, mantenha uma ficha de triagem com versão do plugin, operação relatada, evidências disponíveis e hipótese inicial. Se a versão não aparecer, marque-a como desconhecida. Não complete o campo com a versão mais recente apenas porque é a que você tem instalada.

Compare dumps sucessivos e anote a pilha da EDT, os recursos aguardados e as threads relacionadas. Se houver JFR, use-o para contrastar a hipótese de consumo de CPU com a hipótese de espera. Escreva o diagnóstico como uma cadeia causal a confirmar.

Um experimento de validação é repetir a operação num projeto de teste, antes e depois da mudança, coletando os mesmos tipos de evidência. Observe duração da operação, capacidade de cancelamento e novos freezes. A aceitação deve exigir melhora mensurável sem perder o resultado funcional.

Cuidados e limites

A JetBrains indica uma skill para agentes de programação analisarem padrões como corrotinas e esgotamento de Dispatchers.Default.[7] Use essa assistência para levantar hipóteses, não para promover um patch diretamente a solução comprovada.

Um trecho de pilha sem os dumps completos pode ser insuficiente para reconstruir a dependência. Registre o que falta e mantenha a incerteza explícita. Antes de enviar anexos a um serviço de IA, aplique as regras de proteção de dados do projeto.

Mover I/O bloqueante e reduzir ações de leitura são intervenções possíveis, citadas na orientação.[7] A escolha precisa responder ao bloqueio observado. Thread de fundo não é sinônimo de interface livre, e uma correção sem nova medição continua sendo apenas uma hipótese bem escrita.

Fonte

[7] Fonte: JetBrains Blog | Publicação: 09/10/2026 às 11:27:09