Le code référencé dans cet article provient d'un exemple de code disponible sur le blog Oracle concernant Epsilon GC.
Dans cet article, nous explorons une option particulièrement intrigante de Java Garbage Collection (GC) connue sous le nom d'Epsilon GC. Cet algorithme de garbage collection se distingue par sa particularité : il n’effectue aucun garbage collection. Le garbage collector (GC) Epsilon a été inclus dans JDK 11.
Mais à quoi sert un éboueur s'il ne collecte pas ? (pigiste hein !!)
Non, c'est en fait très utile, un cas d'utilisation tel que celui fourni par le blog Oracle, que j'ai légèrement amélioré pour être plus utile.
Pour plus de détails, veuillez vous référer au billet de blog original :
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector
Le cas d'utilisation : Epsilon GC est bénéfique pour les développeurs qui doivent évaluer l'allocation de mémoire pour un segment particulier de code sans l'aide d'un outil de profilage.
Défi principal Les garbage collector traditionnels peuvent masquer les mesures précises d'utilisation de la mémoire en effaçant continuellement les objets. Cette interférence rend difficile la détermination de la véritable consommation de mémoire de votre code.
Epsilon GC résout ce problème en agissant en tant que non-collectionneur. Bien qu'il ne s'agisse pas d'un algorithme de garbage collection en soi, il sert d'outil pour comprendre l'allocation de mémoire en s'abstenant d'effectuer un garbage collection, fournissant ainsi une image claire de l'utilisation de la mémoire.
Remarque : Il est important de savoir que comme Epsilon GC ne récupère pas de mémoire, une allocation excessive peut conduire à une OutOfMemoryError (OOM) dans la JVM.
Vous trouverez ci-dessous l'exemple de code qui sera utilisé pour démontrer l'efficacité d'Epsilon GC. :
public class EpsilonDemo { public static String formatSize(long v) { if (v < 1024) return v + " B"; int z = (63 - Long.numberOfLeadingZeros(v)) / 10; return String.format("%.1f %sB", (double)v / (1L << (z*10)), " KMGTPE".charAt(z)); } public static void printmem(){ System.out.println("*** Free MEM = "+formatSize(Runtime.getRuntime().freeMemory())); } public static void main(String[] args) { final int MEGAABYTE = 1024 * 1024; final int ITERATIONS = 80; System.out.println("Starting allocations..."); printmem(); // allocate memory 1MB at a time for (int i = 0; i < ITERATIONS; i++) { var array = new byte[MEGAABYTE]; } System.out.println("Completed successfully"); printmem(); } }
Attente :
Le code alloue 80 Mo d'objets de type octet. Nous devrions pouvoir observer la même chose avec les instructions print lorsque nous exécutons le code.
Maintenant, pour exécuter la version compilée avec/sans EpsilonGC :
java -Xms100m -Xmx100m -XX:+UseG1GC EpsilonDemo Starting allocations... *** Free MEM = 102.2 MB Completed successfully *** Free MEM = 74.2 MB
Donc, avec G1GC, nous voyons une image d'allocation incorrecte de 28 Mo d'utilisation
java -Xms100m -Xmx100m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC EpsilonDemo [0.004s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups Starting allocations... *** Free MEM = 99.4 MB Completed successfully *** Free MEM = 18.7 MB
Ici, vous pouvez voir clairement l'utilisation de 80,7 Mo
J'espère que cela vous aidera à voir comment EpsilonGC peut être très pratique pour repérer les modèles d'utilisation de la mémoire dans votre code. Acclamations! ?
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!