Sur le garbage collector Java, on trouve beaucoup d’articles, et beaucoup sont anciens : PermGen, CMS, -XX:+PrintGCDetails… Ce guide résume ce qui est vrai en Java 25, en quelques lignes par sujet. Chaque partie renvoie à un article plus complet, où chaque fait est vérifié dans la documentation officielle ou sur une vraie JVM. Je mets ce guide à jour quand la série avance, ou quand une nouvelle version de Java change les règles. ...
Sur le garbage collector, on lit encore beaucoup de conseils. Certains étaient faux dès le départ, d’autres ne sont plus vrais aujourd’hui. Voici cinq idées reçues, et ce que disent la documentation officielle et une vraie JVM en Java 25. « System.gc() force un GC » Non : c’est une demande, pas un ordre. La javadoc dit que System.gc() « suggère » à la JVM de libérer de la mémoire, sans aucune garantie sur la quantité libérée, ni même que le travail soit fait. ...
Vous reprenez un vieux script de démarrage, vous passez à Java 25, et la JVM ne démarre plus : Unrecognized VM option 'PrintGCDateStamps' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Beaucoup d’options mémoire et GC qu’on trouve encore sur le web ont changé ou disparu. Certaines sont juste ignorées, d’autres empêchent la JVM de démarrer. Et les options utiles aujourd’hui tiennent en quelques lignes. ...
Votre application tourne peut-être avec un autre GC que celui que vous croyez. En Java 25, G1 est le garbage collector par défaut. Mais la JVM en propose d’autres, chacun pour un besoin. Et sur une petite machine, elle en choisit un autre toute seule. Les GC disponibles en Java 25 GC Ce qu’en dit le guide d’Oracle Option Serial Un seul thread pour tout le travail du GC. Pour un petit jeu de données (jusqu’à 100 Mo environ) ou un seul processeur -XX:+UseSerialGC Parallel Le « throughput collector » : comme Serial, mais avec plusieurs threads. Si la performance brute compte le plus, et que des pauses d’une seconde ou plus sont acceptables -XX:+UseParallelGC G1 Un GC « en grande partie concurrent » : il fait une partie du travail pendant que l’application tourne. Si le temps de réponse compte plus que le débit -XX:+UseG1GC ZGC Des pauses de moins d’une milliseconde, au prix d’un peu de débit. Si la latence est la priorité -XX:+UseZGC Shenandoah Un GC à pauses courtes, lui aussi. Le guide d’Oracle n’en parle pas ; il fonctionne avec Temurin 25 -XX:+UseShenandoahGC Et un cas à part : Epsilon. Il alloue la mémoire, mais ne la libère jamais. Quand le heap est plein, la JVM s’arrête. Il sert pour des tests (mesurer une application sans GC, vérifier qu’un test ne crée pas trop d’objets) ou des tâches très courtes. En Java 25, il est encore expérimental : il faut -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC. ...
Minor GC, Major GC, Full GC : des mots qu’on lit partout, mais pas toujours avec le sens que leur donne la documentation officielle. La plupart des objets meurent jeunes. La JVM range donc les objets récents dans la Young, et ceux qui durent dans la Old. Un GC qui ne nettoie que la Young est rapide, et il passe souvent. Pourquoi des générations Le guide officiel d’Oracle sur le garbage collector part d’une observation : la plupart des objets ne vivent que très peu de temps. On l’appelle l’hypothèse générationnelle. Un objet créé pour une requête, une boucle ou un calcul devient inutile presque tout de suite. ...
Votre vieille configuration Java ne démarre plus en Java 17 ? La réponse est dans la mémoire de la JVM. En Java, chaque thread a sa stack, pour ses variables locales. Les objets vivent dans le heap, la zone que le garbage collector nettoie. Les classes sont décrites dans le Metaspace, hors du heap. Et la JVM utilise encore d’autres zones de mémoire, qu’on oublie souvent. Trois zones à connaître La mémoire d'un processus Java : les stacks des threads, le heap, le Metaspace et les autres zones natives Processus Java tout ce qui est hors du heap est de la mémoire native Stacks une par thread · -Xss Thread main traiter() · client main() Thread 2 lire() run() frames, variables locales Heap partagé · géré par le GC · -Xmx Client String List byte[] les objets créés avec new les chaînes internées les champs statiques des classes Metaspace mémoire native sans limite par défaut Client champs, méthodes… String champs, méthodes… la description des classes -XX:MaxMetaspaceSize Et aussi, en mémoire native Code cache le code compilé par le JIT 240 Mo au maximum par défaut Direct memory ByteBuffer.allocateDirect() -XX:MaxDirectMemorySize Structures internes du garbage collector, du compilateur… La stack : une par thread Chaque thread a sa propre stack. À chaque appel de méthode, la JVM y ajoute une frame : les paramètres et les variables locales de la méthode. Quand la méthode se termine, sa frame disparaît. Pas besoin du garbage collector pour libérer cette mémoire. ...
Toute la journée, j’ai deux Chrome ouverts : mon profil perso (Gmail, mes comptes) et mon profil pro (un compte Google Workspace pour l’entreprise). Et sur macOS, c’est pénible. Le problème Sur macOS, tous les profils Chrome sont dans une seule application. Le Dock et Cmd+Tab regroupent les fenêtres par application. Résultat : le Dock affiche une seule icône Chrome pour tous les profils ; Cmd+Tab affiche un seul Chrome. Pour passer de la fenêtre perso à la fenêtre pro, il faut Cmd+`, le menu Fenêtre ou Mission Control ; dans Mission Control, les fenêtres perso et pro sont mélangées. Je voulais quelque chose de simple : une icône par compte dans le Dock, et une entrée par compte dans Cmd+Tab. ...