Pausa para café #94. Revisão de cinco analisadores de código Java estáticos. Erros de memória de heap e pilha Java

Revisão de cinco analisadores de código Java estáticos

Fonte: DZone Os desenvolvedores geralmente exigem vários programas, incluindo analisadores de código estático, que podem encontrar e corrigir códigos errados no início do desenvolvimento. Embora as revisões de código sejam uma ferramenta inestimável nesse esforço, às vezes a quantidade de revisores de código que precisam revisar e revisar é assustadora. Isso exige muito tempo e esforço. Isso também leva ao fato de que os revisores muitas vezes prestam atenção apenas aos fragmentos de código que são críticos para o funcionamento do programa. Já as ferramentas de análise estática verificam todo o código com a mesma precisão. Reuni vários analisadores de código compatíveis com o IntelliJ IDEA. Espero que isso ajude você em seu trabalho.

Analisador IntelliJ IDEA integrado

O analisador de código Java estático integrado ao IntelliJ IDEA não é de forma alguma inferior às ferramentas especializadas de análise estática. A busca por fragmentos de código suspeitos, desordenados ou incorretos é realizada por meio de vários métodos de análise estática: análise de fluxo de dados e correspondência de padrões. O IntelliJ IDEA possui um grande número de inspeções. Na verdade, muitos deles nem sempre relatam o erro com precisão. Em vez disso, indicam negligência no código ou a possibilidade de alterá-lo com uma alternativa interessante. Depois de estudar um pouco “Inspeções → Java”, percebi uma coisa. As inspeções nas categorias de erros prováveis, problemas numéricos e problemas de serialização têm maior probabilidade de encontrar erros reais. Em qualquer caso, você mesmo deve realizar os testes e determinar quais serão úteis para o seu projeto. Como a análise estática é executada no modo de edição de código, no IntelliJ IDEA você pode corrigir erros segundos após eles ocorrerem. O editor destaca imediatamente o fragmento de código incorreto. É muito conveniente e legal! Além disso, se você usar a combinação “Alt + Enter” em um trecho de código selecionado, poderá selecionar uma das opções para corrigir o erro por meio do menu de contexto: Você também pode descobrir o motivo da execução de uma inspeção específica . Em alguns casos, isto reduz o tempo de pesquisa: Você pode executar a análise manualmente selecionando “Analisar → Verificar Código”. Ou você pode executar uma verificação individual usando “Analisar → Executar verificação por nome”. Antes de fazer isso, especifique o escopo da análise (para um projeto, módulo ou arquivo individual). Ao executar uma análise dessa maneira, ficam disponíveis algumas inspeções que não funcionam no modo de edição devido à complexidade. Após análise, os resultados serão agrupados por categoria/diretório em janela separada. Nesta janela você pode navegar até um gatilho de validação específico: o IntelliJ só permite salvar o resultado da análise nos formatos HTML e XML. Infelizmente, na minha opinião, é mais conveniente trabalhar com os problemas detectados no próprio IDE. Observação. A maioria dos recursos do analisador estático está disponível no IntelliJ IDEA Community Edition gratuito.

SonarJava

SonarJava é um analisador de código estático para Java da SonarSource. A lista de suas funções inclui:

• Mais de 150 regras de detecção de erros;
• Mais de 350 regras para reconhecer cheiros de código;
• Mais de 40 regras para detectar vulnerabilidades potenciais ;
• Integração com Maven, Gradle, Ant, Eclipse, IntelliJ IDEA, VS Code;
• Expansível com regras de diagnóstico personalizadas;
• Ferramenta SAST especializada: a maioria das regras de diagnóstico são compiladas de acordo com CWE , CERT , OWASP .

Você pode executar a análise em vários IDEs (por meio do plugin SonarLint ) e separadamente no SonarQube . SonarLint pode trabalhar lado a lado com o analisador de código IntelliJ IDEA integrado. Se você passar o mouse sobre um trecho de código destacado, muitas vezes poderá ver avisos de ambos os analisadores: Claro, você pode visualizar o aviso em uma janela separada: No geral, a capacidade de executar o SonarJava de maneiras diferentes o torna atraente. Isso dá aos desenvolvedores a liberdade de escolher uma ferramenta ao escrever código.

EncontrarBugs/SpotBugs

Infelizmente, FindBugs não é atualizado há muito tempo; a última versão estável foi lançada em 2015. Mas ainda o lembramos e usamos, pois é talvez o mais famoso analisador de código Java estático gratuito. Se você perguntar a um desenvolvedor Java sobre análise estática, ele provavelmente pensará imediatamente em FindBugs. O analisador de código aberto SpotBugs tornou-se uma continuação lógica do FindBugs abandonado. Tem todas as vantagens e desvantagens do FindBugs. O tempo dirá se isso é bom ou ruim. Enquanto isso, a comunidade de analisadores está desenvolvendo-o ativamente. Principais recursos do SpotBugs:

• Mais de 400 regras de detecção de erros;
• Integração em Ant, Maven, Gradle, Eclipse, IntelliJ IDEA;
• Expansível com regras de diagnóstico personalizadas.

Para encontrar códigos suspeitos, são utilizadas as mesmas metodologias: correspondência de padrões e análise de fluxo de dados. O analisador detecta vários tipos de erros relacionados a multithreading, desempenho, vulnerabilidades, ofuscação de código e assim por diante. No IntelliJ IDEA, a janela de alerta é semelhante a esta: Os alertas podem ser agrupados por categoria, classe, diretório e nível de confiança. Você pode visualizar simultaneamente alertas e documentação para qualquer regra de diagnóstico. A análise é iniciada manualmente. Após a análise, todos os fragmentos de código problemáticos são destacados junto com outros avisos do IntelliJ IDEA e SonarLint. No entanto, há um problema. Você deve executar novamente a análise para atualizar os avisos para refletir as alterações feitas no arquivo. Existem também muitos avisos de aconselhamento, portanto o analisador deve ser configurado antes do uso ativo.

Estúdio PVS

PVS-Studio é baseado na biblioteca de código aberto Spoon. Ele pega o código-fonte como entrada e constrói um modelo AST bem projetado com informações semânticas. Com base neste modelo, o analisador utiliza técnicas modernas como:

• Análise de fluxo de dados;
• Desempenho simbólico;
• Anotações de método;
• Análise baseada em padrões.

Atualmente, o analisador utiliza mais de 105 regras de diagnóstico que identificam diversas falhas de código. Isso inclui correções de erros de digitação, renomeação de referências nulas, código inacessível, índice de array fora dos limites, violação do uso do contrato de método e outros erros. Você pode descobrir todos os recursos das regras de diagnóstico aqui . Principais funções do PVS-Studio:

• O analisador está focado em encontrar erros reais;
• Além da versão CLI, há também integração com IntelliJ IDEA, Maven, Gradle, Jenkins, SonarQube;
• Capacidade de executar o analisador em modo incremental;
• O analisador identifica possíveis problemas de compatibilidade com a API Java SE ao migrar um projeto do Java 8 para versões mais recentes;
• O PVS-Studio converte o relatório em vários formatos fáceis de usar: JSON, XML, HTML, TXT;
• Ferramenta SAST especializada: a maioria das regras de diagnóstico são compiladas de acordo com CWE , CERT , OWASP .

PMD

PMD é um analisador estático de código aberto. Identifica erros comuns de desenvolvimento: variáveis ​​não utilizadas, blocos vazios, criação de objetos desnecessários e outros problemas. O analisador usa código-fonte como entrada. Atualmente, o PMD analisa um arquivo de origem por processo, o que impõe limitações à integridade da análise. Os autores do PMD aconselham a montagem do projeto antes da análise. Isso permite extrair informações sobre os tipos usados ​​no código que está sendo analisado. Principais funções do PMD:

• Integração com diversos IDEs (IntelliJ IDEA, Eclipse, NetBeans) e sistemas de build (Maven, Gradle, Ant);
• Suporta vários formatos de relatório do analisador: SARIF, CSV, IDEA, JSON, texto (padrão), XML, HTML, TextColor e assim por diante;
• Possui mais de 300 modelos de regras de diagnóstico. Categorias: estilo de codificação, melhores práticas, bugs, multithreading, desempenho e assim por diante;
• Fornece um CPD (Copy-Paste Detector) junto com um PMD que detecta duplicatas no código.

Se observarmos todas as regras de diagnóstico, o PMD está mais focado em resolver problemas de estilo de codificação e detectar erros óbvios. As regras de diagnóstico podem entrar em conflito entre si, portanto devem ser configuradas antes de usar o analisador. Você também pode executar a análise por meio de um plugin para IntelliJ IDEA, mas não pode selecionar arquivos individuais para análise. A janela de aviso fica assim: Na minha opinião trabalhar com avisos não é muito conveniente, pois eles não podem ser agrupados por arquivos e mensagens não óbvias. Eles só aparecem quando você passa o mouse sobre o aviso.

Conclusão

Claro que, além dos analisadores discutidos acima, existem outras soluções. Existem programas pagos (Coverity, Klockwork, JArchitect) e gratuitos (Error Prone, Infer, Checkstyle). Todos eles se concentram em uma coisa: evitar que códigos incorretos ou potencialmente cheios de bugs cheguem à produção. Não tenho o direito de julgar qual analisador é mais adequado para esta tarefa. Mas os analisadores que desenvolvem análise de fluxo de dados e execução simbólica têm maior probabilidade de encontrar um bug real no código. Se você escolher um analisador estático, preste atenção em:

• integração em vários IDEs;
• integração em sistemas de montagem;
• facilidade de lançamento do analisador no servidor;
• a capacidade de detectar erros no modo de edição de código;
• a capacidade de trabalhar convenientemente com avisos;
• Orientação SAST;
• porcentagem de falsos positivos;
• complexidade da configuração.
• A combinação de todos os prós e contras o levará ao número de analisadores estáticos que você considera os melhores.

Observação: forneci exemplos de integração ao IntelliJ IDEA, pois o utilizo com frequência.

Erros de memória de heap e pilha Java

Fonte: DZone Veremos agora os principais erros que podem ocorrer na memória heap ou stack Java, mas primeiro vamos lembrar o que esses dois termos significam.

• A memória heap é uma área especial de memória na qual os objetos Java são armazenados.
• A memória de pilha é uma área de memória temporária para armazenar variáveis ​​ao chamar um método.

A principal exceção que descreve um problema de memória heap é java.lang.OutOfMemoryError .

Espaço de pilha Java

Este erro ocorre quando um programa Java não consegue alocar um novo objeto em uma área de memória heap.

Limite de sobrecarga do GC excedido

Um programa Java gasta muito tempo coletando lixo. Este erro aparece quando a coleta de lixo ocupa 98% do tempo do programa e recupera menos de 2% do espaço de memória.

public class OutOfMemoryErrorDemo {
    public static void main(String[] args) {
        int i = 0;
        List<String> stringList = new ArrayList<>();
        while (i < Integer.MAX_VALUE) {
            i++;
            String generatedString = new String( "Some string generated to show out of memory error example " + i);
            stringList.add(generatedString);
        }
    }
}

Aqui stringList contém uma referência às nossas strings geradas, portanto o coletor de lixo não pode remover as strings geradas da memória, mas tenta remover qualquer outro lixo no aplicativo. Mas isto não é o suficiente.

O tamanho da matriz solicitada excede o limite da VM

O erro ocorre quando você tenta alocar um array quando não há espaço suficiente no heap.

public class OutOfMemoryErrorDemo {
    public static void main(String[] args) {
        // we try to create too long array
        long[] array = new long[Integer.MAX_VALUE];
    }
}

Metaespaço

Uma exceção é lançada com esta mensagem quando não há espaço na região do metaespaço para informações de dados de classe.

Sem espaço de troca (solicitação de bytes de tamanho por motivo. Sem espaço de troca?)

O erro aparece quando a memória não pode ser alocada no heap nativo ou seu tamanho é insuficiente.

motivo stack_trace_with_native_method

Uma interface Java nativa ou um método nativo falhou ao alocar memória no heap. StackOverFlowError – quando há muitas chamadas de método. Normalmente uma exceção é lançada por um método que possui recursão dentro dela.

public class StackOverFlowErrorDemo {

    public static void main(String[] args) {
        recursiveMethod(2);
    }

    public static int recursiveMethod(int i) {
      	// it will never stop and it allocates all stack memory
        return recursiveMethod(i);
    }
}