Pause café #94. Examen de cinq analyseurs de code Java statiques. Erreurs de mémoire de tas et de pile Java

Examen de cinq analyseurs de code Java statiques

Source : DZone Les développeurs ont souvent besoin de divers programmes, notamment des analyseurs de code statique, capables de détecter et de corriger le code erroné dès le début du développement. Bien que les révisions de code soient un outil inestimable dans cette entreprise, le nombre de réviseurs de code doit parfois être intimidant. Cela demande beaucoup de temps et d'efforts. Cela conduit également au fait que les réviseurs ne prêtent souvent attention qu'aux fragments de code essentiels au fonctionnement du programme. Alors que les outils d’analyse statique vérifient tout le code avec la même précision. J'ai rassemblé plusieurs analyseurs de code compatibles avec IntelliJ IDEA. J'espère que cela vous aidera dans votre travail.

Analyseur IntelliJ IDEA intégré

L'analyseur de code Java statique intégré à IntelliJ IDEA n'est en aucun cas inférieur aux outils d'analyse statique spécialisés. La recherche de fragments de code suspects, encombrés ou incorrects s'effectue à l'aide de diverses méthodes d'analyse statique : analyse des flux de données et correspondance de modèles. IntelliJ IDEA dispose d'un grand nombre d'inspections. En vérité, beaucoup d’entre eux ne signalent pas toujours l’erreur avec précision. Ils indiquent plutôt une négligence dans le code ou la possibilité de le modifier avec une alternative intéressante. Après avoir étudié un peu « Inspections → Java », j'ai remarqué une chose. Les inspections dans les catégories d'erreurs probables, de problèmes numériques et de problèmes de sérialisation sont plus susceptibles de détecter des erreurs réelles. Dans tous les cas, vous devez réaliser vous-même les tests et déterminer lesquels seront utiles à votre projet. Étant donné que l'analyse statique est effectuée en mode édition de code, dans IntelliJ IDEA, vous pouvez corriger les erreurs quelques secondes après leur apparition. L'éditeur met immédiatement en évidence le fragment de code incorrect. C'est vraiment pratique et cool ! De plus, si vous utilisez la combinaison « Alt + Entrée » sur un morceau de code sélectionné, vous pouvez sélectionner l'une des options pour corriger l'erreur via le menu contextuel : Vous pouvez également connaître la raison de l'exécution d'une inspection particulière . Dans certains cas, cela réduit le temps de recherche : Vous pouvez exécuter l'analyse manuellement en sélectionnant « Analyser → Vérifier le code ». Ou vous pouvez exécuter une vérification individuelle en utilisant « Analyser → Exécuter la vérification par nom ». Avant de procéder, précisez le périmètre d'analyse (pour un projet, un module ou un dossier individuel). Lorsque vous exécutez une analyse de cette manière, certaines inspections deviennent disponibles et ne fonctionnent pas en mode édition en raison de leur complexité. Après analyse, les résultats seront regroupés par catégorie/répertoire dans une fenêtre séparée. Depuis cette fenêtre, vous pouvez accéder à un déclencheur de validation spécifique : IntelliJ vous permet uniquement d'enregistrer le résultat de l'analyse aux formats HTML et XML. Malheureusement, à mon avis, il est plus pratique de travailler avec des problèmes détectés dans l'EDI lui-même. Note. La plupart des fonctionnalités de l'analyseur statique sont disponibles dans l'édition gratuite IntelliJ IDEA Community.

SonarJava

SonarJava est un analyseur de code statique pour Java de SonarSource. La liste de ses fonctions comprend :

• Plus de 150 règles de détection d'erreurs ;
• Plus de 350 règles pour reconnaître les odeurs de code ;
• Plus de 40 règles pour détecter les vulnérabilités potentielles ;
• Intégration avec Maven, Gradle, Ant, Eclipse, IntelliJ IDEA, VS Code ;
• Extensible avec des règles de diagnostic personnalisées ;
• Outil SAST spécialisé : la plupart des règles de diagnostic sont compilées conformément aux normes CWE , CERT , OWASP .

Vous pouvez exécuter l'analyse à la fois dans différents IDE (via le plugin SonarLint ) et séparément dans SonarQube . SonarLint peut fonctionner côte à côte avec l'analyseur de code IntelliJ IDEA intégré. Si vous survolez un morceau de code en surbrillance, vous pouvez souvent voir des avertissements des deux analyseurs : Bien sûr, vous pouvez afficher l'avertissement dans une fenêtre séparée : Dans l'ensemble, la possibilité d'exécuter SonarJava de différentes manières le rend attrayant. Cela donne aux développeurs la liberté de choisir un outil lors de l'écriture du code.

Rechercher des bogues/SpotBugs

Malheureusement, FindBugs n'a pas été mis à jour depuis longtemps ; la dernière version stable a été publiée en 2015. Mais nous nous en souvenons toujours et l'utilisons, car il s'agit peut-être de l'analyseur de code Java statique gratuit le plus célèbre. Si vous interrogez un développeur Java sur l'analyse statique, il pensera probablement immédiatement à FindBugs. L'analyseur open source SpotBugs est devenu une suite logique des FindBugs abandonnés. Il présente tous les avantages et inconvénients de FindBugs. Le temps nous dira si c’est bon ou mauvais. En attendant, la communauté des analyseurs le développe activement. Principales fonctionnalités de SpotBugs :

• Plus de 400 règles de détection d'erreurs ;
• Intégration dans Ant, Maven, Gradle, Eclipse, IntelliJ IDEA ;
• Extensible avec des règles de diagnostic personnalisées.

Pour trouver du code suspect, les mêmes méthodologies sont utilisées : la mise en correspondance de modèles et l'analyse des flux de données. L'analyseur détecte différents types d'erreurs liées au multithreading, aux performances, aux vulnérabilités, à l'obscurcissement du code, etc. Dans IntelliJ IDEA, la fenêtre d'alerte ressemble à ceci : Les alertes peuvent être regroupées par catégorie, classe, répertoire et niveau de confiance. Vous pouvez afficher simultanément les alertes et la documentation pour n'importe quelle règle de diagnostic. L'analyse est lancée manuellement. Après analyse, tous les fragments de code problématiques sont mis en évidence avec d'autres avertissements d'IntelliJ IDEA et SonarLint. Cependant, il y a un problème. Vous devez réexécuter l'analyse pour mettre à jour les avertissements afin de refléter les modifications que vous avez apportées au fichier. Il existe également de nombreux avertissements, l'analyseur doit donc être configuré avant une utilisation active.

PVS-Studio

PVS-Studio est basé sur la bibliothèque open source Spoon. Il prend le code source en entrée et construit un modèle AST bien conçu avec des informations sémantiques. Sur la base de ce modèle, l'analyseur utilise des techniques modernes telles que :

• Analyse des flux de données ;
• Performance symbolique ;
• Annotations de méthode ;
• Analyse basée sur des modèles.

Actuellement, l'analyseur utilise plus de 105 règles de diagnostic qui identifient diverses failles de code. Ceux-ci incluent des corrections de fautes de frappe, le renommage des références nulles, un code inaccessible, un index de tableau hors limites, une violation de l'utilisation du contrat de méthode et d'autres erreurs. Vous pouvez découvrir toutes les fonctionnalités des règles de diagnostic ici . Principales fonctions de PVS-Studio :

• L'analyseur se concentre sur la recherche d'erreurs réelles ;
• En plus de la version CLI, il existe également une intégration avec IntelliJ IDEA, Maven, Gradle, Jenkins, SonarQube ;
• Possibilité d'exécuter l'analyseur en mode incrémentiel ;
• L'analyseur identifie les problèmes potentiels de compatibilité avec l'API Java SE lors de la migration d'un projet de Java 8 vers des versions plus récentes ;
• PVS-Studio convertit le rapport dans différents formats conviviaux : JSON, XML, HTML, TXT ;
• Outil SAST spécialisé : la plupart des règles de diagnostic sont compilées conformément aux normes CWE , CERT , OWASP .

PMD

PMD est un analyseur statique open source. Il identifie les erreurs courantes de développement : variables inutilisées, blocs vides, création d'objets inutiles et autres problèmes. L'analyseur utilise le code source comme entrée. Actuellement, PMD analyse un fichier source par processus, ce qui impose des limites à l'exhaustivité de l'analyse. Les auteurs de PMD conseillent d'assembler le projet avant l'analyse. Cela vous permet d'extraire des informations sur les types utilisés dans le code en cours d'analyse. Principales fonctions de PMD :

• Intégration avec divers IDE (IntelliJ IDEA, Eclipse, NetBeans) et systèmes de build (Maven, Gradle, Ant);
• Prend en charge divers formats de rapport d'analyseur : SARIF, CSV, IDEA, JSON, texte (par défaut), XML, HTML, TextColor, etc. ;
• Contient plus de 300 modèles de règles de diagnostic. Catégories : style de codage, bonnes pratiques, bugs, multithreading, performances, etc. ;
• Fournit un CPD (Copy-Paste Detector) ainsi qu'un PMD qui détecte les doublons dans le code.

Si nous examinons toutes les règles de diagnostic, PMD se concentre davantage sur la résolution des problèmes de style de codage et sur la détection des erreurs évidentes. Les règles de diagnostic peuvent entrer en conflit les unes avec les autres, elles doivent donc être configurées avant d'utiliser l'analyseur. Vous pouvez également exécuter l'analyse via un plugin pour IntelliJ IDEA, mais vous ne pouvez pas sélectionner des fichiers individuels pour l'analyse. La fenêtre d'avertissement ressemble à ceci : À mon avis, travailler avec des avertissements n'est pas très pratique, car ils ne peuvent pas être regroupés par fichiers et messages non évidents. Ils n'apparaissent que lorsque vous survolez l'avertissement.

Conclusion

Bien entendu, en plus des analyseurs évoqués ci-dessus, il existe d'autres solutions. Il existe des programmes payants (Coverity, Klockwork, JArchitect) et gratuits (Error Prone, Infer, Checkstyle). Ils se concentrent tous sur une seule chose : empêcher qu’un code incorrect ou potentiellement bogué n’atteigne la production. Je n'ai pas le droit de juger quel analyseur est le mieux adapté à cette tâche. Mais les analyseurs qui développent l'analyse des flux de données et l'exécution symbolique sont plus susceptibles de trouver un véritable bug dans le code. Si vous choisissez un analyseur statique, faites attention à :

• intégration dans divers IDE ;
• intégration dans les systèmes d'assemblage;
• facilité de lancement de l'analyseur sur le serveur ;
• la capacité de détecter les erreurs en mode édition de code ;
• la capacité de travailler facilement avec les avertissements ;
• Orientation SAST ;
• pourcentage de faux positifs ;
• complexité de la configuration.
• La combinaison de tous les avantages et inconvénients vous mènera au nombre d’analyseurs statiques que vous considérez comme les meilleurs.

Remarque : j'ai fourni des exemples d'intégration dans IntelliJ IDEA, car je l'utilise souvent.

Erreurs de mémoire de tas et de pile Java

Source : DZone Nous allons maintenant examiner les principales erreurs qui peuvent survenir dans la mémoire du tas ou de la pile Java, mais rappelons d'abord ce que signifient ces deux termes.

• La mémoire tas est une zone de mémoire spéciale dans laquelle les objets Java sont stockés.
• La mémoire de pile est une zone de mémoire temporaire permettant de stocker des variables lors de l'appel d'une méthode.

La principale exception qui décrit un problème de mémoire tas est java.lang.OutOfMemoryError .

Java heap space

Cette erreur se produit lorsqu'un programme Java ne parvient pas à allouer un nouvel objet dans une zone de mémoire tas.

Limite de frais généraux du GC dépassée

Un programme Java passe trop de temps à effectuer le garbage collection. Cette erreur apparaît lorsque le garbage collection occupe 98 % du temps du programme et récupère moins de 2 % de l'espace mémoire.

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);
        }
    }
}

Ici, stringList contient une référence à nos chaînes générées, de sorte que le ramasse-miettes ne peut pas supprimer les chaînes générées de la mémoire, mais essaie de supprimer tout autre déchet dans l'application. Mais ce n'est pas assez.

La taille de la baie demandée dépasse la limite de la machine virtuelle

L'erreur se produit lorsque vous essayez d'allouer un tableau alors qu'il n'y a pas suffisamment d'espace dans le tas.

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

Métaespace

Une exception est levée avec ce message lorsqu'il n'y a pas de place dans la région métaspatiale pour les informations sur les données de classe.

Pas d'espace d'échange (Demande de taille en octets pour raison. Espace d'échange épuisé ?)

L'erreur apparaît lorsque la mémoire n'a pas pu être allouée sur le tas natif ou que sa taille est insuffisante.

raison stack_trace_with_native_method

Une interface Java native ou une méthode native n'a pas réussi à allouer de la mémoire sur le tas. StackOverFlowError - lorsqu'il y a trop d'appels de méthode. Habituellement, une exception est levée par une méthode qui contient une récursion.

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);
    }
}