Par nature, les programmes Java créent et détruisent des objets qui consomment des ressources système, plus précisément de la CPU et de la mémoire. Malheureusement, beaucoup de programmeurs Java ne suivent pas de bonnes règles de conception et finissent par encombrer leurs systèmes d'objets nouveaux et détruits.
C'est le cas,
par exemple, quand un
programmeur choisit de créer des objets
alors que des types Java primitifs
sont appropriés. Par exemple : extraire
des colonnes de base de données non
caractères comme des objets String.
JDBC demande aux programmeurs
de choisir un type de donnée particulier
pour chaque colonne sélectionnée
quand ils extraient des données de la
base de données. JDBC permet d’extraire
des données non caractères
comme un objet String. En fait, de
nombreux programmeurs apprécient
cette technique pour traiter les données
résultantes. Mais l’utilisation de
getString() entraîne la création d’un
nouvel objet. En revanche, si les données
sont extraites comme un objet
primitif (par exemple, comme un entier
avec la méthode getInt(), vous
pouvez éviter une création d’objet (et éventuellement, une destruction
d’objet).
Les programmeurs provoquent
aussi de l’encombrement lorsqu’au
lieu d’essayer de réutiliser des objets
existants, ils en créent de nouveaux.
Par exemple, en utilisant des objets
StringBuffer au lieu d’objets String
pour des objets susceptibles de modification.
Les objets String sont immuables
: Si l’objet est modifié, un
nouveau est créé et l’original est détruit.
Un StringBuffer n’est pas immuable.
Vous pouvez l’utiliser pour
fournir la même fonction qu’un objet
String et pour alléger l’overhead.
L’utilisation de StringBuffer a aussi
pour effet secondaire de voir ses méthodes
synchronisées. L’excès de création
d’objets a une autre conséquence
fâcheuse : le ramasse-miettes résultant
sur le système. Pour être certain de libérer
la mémoire gaspillée, le JVM doit
nettoyer les objets non référencés. Le
ramasse-miettes fonctionne comme un
thread séparé et, malgré son efficacité,
il consomme néanmoins des ressources
de CPU. Une méthode efficace
de création/destruction d’objets
espace davantage les opérations
ramasse-miettes.
On peut aussi réduire l’overhead
du ramasse-miettes sur la plupart
des systèmes en augmentant la
valeur de taille initiale de la pile de ramasse-miettes (GCHINL, garbage
collection heap initial size). La valeur
par défaut est de 2 048 K. 32 Mo (une
valeur GCHINL de 32 000) constitue un
bon point de départ pour des applications
Java. Les applications ou environnements
Java complexes comme
WebSphere Application Server peuvent
nécessiter des valeurs initiales supérieures
à 32 Mo. Il ne faut pas que
cette valeur soit trop élevée pour des
systèmes limités en mémoire.
Pour définir la taille maximale de la
pile, utilisez la valeur GCHMAX. La plupart
des applications/environnements
iSeries doivent laisser ce paramètre à la
valeur par défaut *NOMAX, qui indique
au système que la pile JVM peut
encore grandir avant que l’on ne déclenche
un cycle ramasse-miettes. On
réduit ainsi le nombre total de cycles à
effectuer par le ramasse-miettes.
D’une manière générale, ne concevez
pas les applications iSeries en prévoyant l’exécution manuelle du
ramasse-miettes au moyen de la commande
System.gc(). Vous risqueriez
d’alourdir inutilement le traitement.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
