Utiliser .clear() ou laisser le GC s'en charger

Question

Dans une partie de mon code, deux LinkedHashMaps sont créées, comme suit :

Map<Byte, Integer> hash1 = new LinkedHashMap<Byte, Integer>();
Map<Byte, Integer> hash2 = new LinkedHashMap<Byte, Integer>();

Ensuite, une boucle for est exécutée pour ajouter des valeurs dans leurs cartes de hachage respectives, puis les cartes de hachage sont exécutées dans une autre boucle utilisée pour la création de paquets. Serait-il préférable d'appeler .clear() après l'appel de la seconde boucle, ou de laisser le garbage collector s'en charger ?

Answer 1

Si vous n'appelez pas clear(), le GC ne s'en occupera pas, car les objets seront toujours référencés par le hashmap jusqu'à ce qu'il sorte du champ d'application.

Si le hashmap sort de toute façon du champ d'application, vous pouvez laisser le GC s'en occuper. Il n'y aura probablement pas de différence mesurable à l'effacer d'abord.

Answer 2

Appel clear() sur ces cartes est probablement une perte de temps coûteuse, du point de vue du ramassage des ordures.

Trois cas sont à considérer :

• Si les variables contenant les (seules) références à la table de hachage sont sur le point de sortir du champ d'application, l'appel à la fonction clear() sur eux est une perte de temps. Même l'attribution de null aux variables est une (minuscule) perte de temps.

  Les HashMap seront collectés lors de la prochaine exécution du GC sur le tas qui les contient. Appel clear() n'accélérera pas les choses et ne réduira pas le travail effectué par le GC.

• Si les variables ne sont pas sur le point de sortir du champ d'application, mais que vous n'avez pas l'intention de réutiliser l'élément HashMaps puis en affectant null à eux peut rendent les HashMaps éligibles au GC un peu plus tôt, mais la JVM peut de traiter cette affaire de toute façon. Appel clear() est une perte de temps, comme indiqué ci-dessus.

• Si les variables ne sortent pas du champ d'application, et que vous allez réutiliser la fonction HashMaps Il peut alors s'avérer judicieux de les éliminer. Toutefois, l'objectif réel de l'appel clear() serait de se débarrasser des anciennes entrées de la carte (probablement indésirables) qui sont susceptibles de ralentir les opérations de la table de hachage et d'entraîner des résultats incorrects.

(Il s'agit d'un développement des commentaires sur la réponse de @squacknull).

---

Pour comprendre pourquoi appeler clear n'aide pas le GC, vous devez comprendre comment fonctionnent les collecteurs HotSpot. Les collecteurs HotSpot sont des collecteurs de "copie" qui copient d'un espace "from" vers un espace "to". Le travail est effectué en traçant récursivement les objets atteignables dans l'espace "from" et en les copiant dans l'espace "to". Ensuite, tous les objets restants sont vérifiés pour voir s'ils doivent être finalisés, et les objets finalisables sont récursivement tracés et copiés dans l'espace "to". Enfin, l'espace "from" est mis à zéro et le GC est terminé. (C'est plus compliqué que cela, si l'on tient compte des générations, des collecteurs concurrents, etc.)

En supposant que la HashMap soit inaccessible et non finalisable, les deux phases de marquage ne trouveront ni elle, ni ses objets internes (c'est-à-dire le tableau de hachage ou les chaînes), ni les clés et les valeurs de la carte ... en supposant que ces dernières ne soient pas accessibles par une autre voie. Ainsi, l'effacement du tableau de hachage (qui est ce que clear() ) ne fait qu'effacer des éléments d'un objet qui n'allait pas être tracé de toute façon. Cela n'a aucun effet sur ce que le GC doit faire.