Java Language
Réglage des performances Java

Approche générale

Internet regorge de conseils pour améliorer les performances des programmes Java. Peut-être le conseil numéro un est la sensibilisation. Cela signifie:

• Identifier les problèmes de performance et les goulots d'étranglement possibles.
• Utilisez des outils d'analyse et de test.
• Connaître les bonnes pratiques et les mauvaises pratiques.

Le premier point devrait être fait lors de la phase de conception si vous parlez d'un nouveau système ou module. Si vous parlez de code hérité, des outils d'analyse et de test apparaissent. L'outil le plus fondamental pour analyser vos performances JVM est JVisualVM, qui est inclus dans le JDK.

Le troisième point concerne surtout l’expérience et les recherches approfondies, et bien sûr les astuces brutes qui apparaîtront sur cette page et d’autres, comme ceci .

Réduire la quantité de cordes

En Java, il est trop "facile" de créer de nombreuses instances de String qui ne sont pas nécessaires. Cela et d'autres raisons peuvent amener votre programme à avoir beaucoup de chaînes que le GC est en train de nettoyer.

Voici quelques façons de créer des instances de chaîne:

myString += "foo";

Ou pire, en boucle ou en récursion:

for (int i = 0; i < N; i++) {
    myString += "foo" + i;
}

Le problème est que chaque + crée une nouvelle chaîne (généralement, puisque les nouveaux compilateurs optimisent certains cas). Une optimisation possible peut être faite en utilisant StringBuilder ou StringBuffer :

StringBuffer sb = new StringBuffer(myString);
for (int i = 0; i < N; i++) {
    sb.append("foo").append(i);
}
myString = sb.toString();

Si vous générez souvent de longues chaînes (SQL par exemple), utilisez une API de génération de chaînes.

Autres choses à considérer:

• Réduire l'utilisation de replace , substring - substring etc.
• Évitez String.toArray() , en particulier dans le code fréquemment String.toArray() .
• Les impressions de journal destinées à être filtrées (en raison du niveau de journalisation, par exemple) ne doivent pas être générées (le niveau de journalisation doit être vérifié au préalable).
• Utilisez des bibliothèques comme celle-ci si nécessaire.
• StringBuilder est préférable si la variable est utilisée d'une manière non partagée (à travers les threads).

Une approche basée sur des preuves pour l'optimisation des performances Java

Donald Knuth est souvent cité comme disant ceci:

« Les programmeurs gaspillent des quantités énormes de temps à penser à, ou se soucier, la vitesse des parties non critiques de leurs programmes, et ces tentatives d'efficacité ont en fait un fort impact négatif lorsque sont considérés comme le débogage et la maintenance. Il faut oublier les petits gains d' efficacité, disent 97% du temps : l'optimisation prématurée est la racine de tous les maux. Pourtant, nous ne devrions pas laisser passer nos opportunités dans ces 3% critiques. "

la source

Compte tenu de ce conseil avisé, voici la procédure recommandée pour optimiser les programmes:

1. Tout d'abord, concevez et codez votre programme ou votre bibliothèque en mettant l'accent sur la simplicité et l'exactitude. Pour commencer, ne consacrez pas beaucoup d'efforts à la performance.

2. Mettez-le en état de marche et, idéalement, développez des tests unitaires pour les éléments clés du code.

3. Développer un benchmark de performance au niveau applicatif. Le test de performance doit couvrir les aspects critiques de votre application en termes de performances, et effectuer une série de tâches typiques de l’utilisation de l’application en production.

4. Mesurer la performance.

5. Comparez les performances mesurées à vos critères pour déterminer la rapidité avec laquelle l'application doit être. (Évitez les critères irréalistes, irréalisables ou non quantifiables tels que "aussi vite que possible".)

6. Si vous avez satisfait aux critères, STOP. Votre travail est terminé. (Tout effort supplémentaire est probablement une perte de temps.)

7. Profil de l'application pendant qu'elle exécute votre test de performances.

8. Examinez les résultats du profilage et sélectionnez les "zones sensibles de performance" les plus importantes (non optimisées). c'est-à-dire des sections du code où l'application semble passer le plus de temps.

9. Analysez la section de code du hotspot pour essayer de comprendre pourquoi il s’agit d’un goulot d’étranglement et réfléchissez à un moyen de le rendre plus rapide.

10. Implémentez cela comme un changement de code proposé, testez et déboguez.

11. Réexécutez le test pour voir si le changement de code a amélioré les performances:

    • Si oui, retournez à l'étape 4.
    • Si non, abandonner le changement et retourner à l'étape 9. Si vous ne faites aucun progrès, choisissez un autre point sensible pour votre attention.

Finalement, vous arriverez à un point où l'application est soit assez rapide, soit vous avez considéré tous les points chauds significatifs. À ce stade, vous devez arrêter cette approche. Si une section de code consomme (disons) 1% du temps total, alors même une amélioration de 50% ne fera que rendre l'application 0,5% plus rapide.

Clairement, il existe un point au-delà duquel l’optimisation des points d’accès est une perte de temps. Si vous arrivez à ce stade, vous devez adopter une approche plus radicale. Par exemple:

• Regardez la complexité algorithmique de vos algorithmes de base.
• Si l'application consacre beaucoup de temps à la récupération de place, recherchez des moyens de réduire le taux de création d'objets.
• Si des parties clés de l'application consomment beaucoup de ressources processeur et sont à thread unique, recherchez les opportunités de parallélisme.
• Si l'application est déjà multithread, recherchez les goulots d'étranglement de concurrence.

Mais dans la mesure du possible, utilisez des outils et des mesures plutôt que l'instinct pour diriger votre effort d'optimisation.