Quelle est la différence entre SoftReference et WeakReference en Java?


811

Quelle est la différence entre java.lang.ref.WeakReferenceet java.lang.ref.SoftReference?


9
Les SoftReferences sont des types de WeakReferences (pas vraiment, mais pour la discussion) qui sont généralement collectées lorsque la JVM pense qu'il n'y a plus de mémoire.
Ajeet Ganga

5
@AjeetGanga, les références faibles et lâches sont toujours collectées à chaque exécution du GC. Voir stackoverflow.com/a/46291143/632951
Pacerier

Réponses:


927

De Comprendre les références faibles , par Ethan Nicholas:

Références faibles

Une référence faible , en termes simples, est une référence qui n'est pas assez forte pour forcer un objet à rester en mémoire. Les références faibles vous permettent de tirer parti de la capacité du garbage collector à déterminer l'accessibilité pour vous, vous n'avez donc pas à le faire vous-même. Vous créez une référence faible comme celle-ci:

WeakReference weakWidget = new WeakReference(widget);

puis ailleurs dans le code que vous pouvez utiliser weakWidget.get()pour obtenir l' Widgetobjet réel . Bien sûr, la référence faible n'est pas assez forte pour empêcher la récupération de place, vous pouvez donc trouver (s'il n'y a pas de références fortes au widget) qui weakWidget.get()commence soudainement à revenir null.

...

Références douces

Une référence douce est exactement comme une référence faible, sauf qu'elle est moins désireuse de jeter l'objet auquel elle se réfère. Un objet qui n'est que faiblement accessible (les références les plus fortes sont WeakReferences) sera jeté au prochain cycle de collecte des ordures, mais un objet qui est facilement accessible restera généralement un certain temps.

SoftReferencesne sont pas tenus de se comporter différemment WeakReferences, mais dans la pratique, les objets facilement accessibles sont généralement conservés tant que la mémoire est abondante. Cela en fait une excellente base pour un cache, tel que le cache d'image décrit ci-dessus, car vous pouvez laisser le garbage collector s'inquiéter à la fois de la façon dont les objets sont accessibles (un objet fortement accessible ne sera jamais supprimé du cache) et de sa gravité. a besoin de la mémoire qu'ils consomment.

Et Peter Kessler a ajouté dans un commentaire:

Le Sun JRE traite les SoftReferences différemment des WeakReferences. Nous essayons de nous accrocher à l'objet référencé par une SoftReference s'il n'y a pas de pression sur la mémoire disponible. Un détail: la stratégie pour les JRE "-client" et "-server" est différente: le JRE -client essaie de garder votre encombrement petit en préférant effacer les SoftReferences plutôt que de développer le tas, tandis que le JRE -server essaie de garder votre performances élevées en préférant étendre le tas (si possible) plutôt que d'effacer les références logicielles. Une taille unique ne convient pas à tous.


7
Le poste n'est plus disponible, vous pouvez le trouver sur la machine de retour: web.archive.org/web/20061130103858/http://weblogs.java.net/blog/…
riccardo.tasso

cette fois, l'archive n'est plus disponible
user1506104

209

Les références faibles sont collectées avec impatience. Si GC trouve qu'un objet est faiblement accessible (accessible uniquement via des références faibles), il effacera immédiatement les références faibles à cet objet. En tant que tels, ils sont bons pour conserver une référence à un objet pour lequel votre programme conserve également (fortement référencé) des "informations associées", comme les informations de réflexion mises en cache sur une classe, ou un wrapper pour un objet, etc. Tout ce qui fait aucun sens à garder après que l'objet auquel il est associé soit GC-ed. Lorsque la référence faible est effacée, elle est mise en file d'attente dans une file d'attente de référence que votre code interroge quelque part, et elle supprime également les objets associés. Autrement dit, vous conservez des informations supplémentaires sur un objet, mais ces informations ne sont pas nécessaires une fois que l'objet auquel il fait référence disparaît. Réellement, dans certaines situations, vous pouvez même sous-classer WeakReference et conserver les informations supplémentaires associées sur l'objet dans les champs de la sous-classe WeakReference. Une autre utilisation typique de WeakReference est en conjonction avec Maps pour conserver les instances canoniques.

Les références logicielles, d'autre part, sont bonnes pour la mise en cache des ressources externes et recréables car le GC retarde généralement leur effacement. Il est cependant garanti que toutes les SoftReferences seront effacées avant que OutOfMemoryError ne soit levée, donc elles ne peuvent théoriquement pas provoquer un OOME [*].

Un exemple typique de cas d'utilisation consiste à conserver une forme analysée d'un contenu à partir d'un fichier. Vous implémenteriez un système dans lequel vous chargeriez un fichier, l'analyseriez et conserveriez une SoftReference à l'objet racine de la représentation analysée. La prochaine fois que vous aurez besoin du fichier, vous essaierez de le récupérer via SoftReference. Si vous pouvez le récupérer, vous vous êtes épargné une autre charge / analyse, et si le GC l'a effacé entre-temps, vous le rechargez. De cette façon, vous utilisez de la mémoire libre pour l'optimisation des performances, mais ne risquez pas un OOME.

Maintenant pour le [*]. Garder une SoftReference ne peut pas provoquer un OOME en soi. Si, d'autre part, vous utilisez par erreur SoftReference pour une tâche, une WeakReference est destinée à être utilisée (à savoir, vous conservez les informations associées à un objet en quelque sorte fortement référencées et les jetez lorsque l'objet Reference est effacé), vous pouvez exécuter OOME comme votre code qui interroge la ReferenceQueue et rejette les objets associés peut ne pas s'exécuter en temps opportun.

Ainsi, la décision dépend de l'utilisation - si vous mettez en cache des informations coûteuses à construire, mais néanmoins reconstructibles à partir d'autres données, utilisez des références logicielles - si vous conservez une référence à une instance canonique de certaines données, ou si vous souhaitez avoir une référence à un objet sans le "posséder" (l'empêchant ainsi d'être GC'd), utiliser une référence faible.


14
Particulièrement utile pour expliquer quand des objets faibles seront utilisés.
Jack BeNimble

Un point clé à propos de l'utilisation appropriée de a WeakReferenceest que dans les endroits où l'on devrait l'utiliser, le fait que l'on puisse rester valide pendant un certain temps après que la référence soit hors de portée peut être tolérable, mais n'est pas souhaitable.
supercat

J'ai du mal à comprendre à quoi sert WeakHashMap s'il produit toujours une référence faible à son objet de valeur clé?

@supercat, Il n'y a qu'une seule utilisation appropriée WeakReferencepour observer les exécutions du GC. Voir l'élaboration: stackoverflow.com/a/46291143/632951
Pacerier

1
@Pacerier: L'auteur de ce message est tout simplement faux. Il néglige certains autres scénarios d'utilisation comme l'abonnement aux événements, son deuxième point est absurde et son troisième point suppose qu'un programmeur peut faire des choses qui ne sont peut-être pas possibles. Son premier point est raisonnable, mais il rejoint directement ce que j'ai dit. Si le code devra fréquemment construire et comparer grands objets immuables, par exemple, la partie de construction sera souvent moins chère si le code crée de nouveaux objets sans se soucier de savoir s'ils existent déjà, mais une comparaison entre un objet et lui-même (références identiques) sera ...
supercat

155

En Java ; ordre du plus fort au plus faible, il y a: fort, doux, faible et fantôme

Une référence forte est une référence normale qui protège l'objet référé de la collecte par GC. c.-à-d. ne jamais ramasser les ordures.

Une référence logicielle peut être collectée par le garbage collector, mais ne sera probablement pas collectée tant que sa mémoire n'est pas nécessaire. c.-à-d. les ordures ramassent avant OutOfMemoryError.

Une référence faible est une référence qui ne protège pas un objet référencé de la collecte par GC. c.-à-d. que les ordures se collectent lorsqu'aucune référence forte ou douce.

Une référence fantôme est une référence à un objet référencée fantôme après sa finalisation, mais avant que sa mémoire allouée ne soit récupérée.

La source

Analogie: Supposons qu'une JVM est un royaume, Object est un roi du royaume et GC est un attaquant du royaume qui essaie de tuer le roi (objet).

  • Lorsque King est fort , GC ne peut pas le tuer.
  • Quand King est mou , GC l'attaque mais King règne sur le royaume avec protection jusqu'à ce que la ressource soit disponible.
  • Quand King est faible , GC l'attaque mais gouverne le royaume sans protection.
  • Quand le roi est fantôme , GC l'a déjà tué mais le roi est disponible via son âme.

7
Une référence douce ... until memory is availablen'a pas de sens. Tu veux dire is eligible for collection by garbage collector, but probably won't be collected until its memory is needed for another use?
ToolmakerSteve

1
oui, le garbage collector ne collectera pas la référence tant que la mémoire n'est pas disponible.
Premraj

2
J'aime les trucs simples et expliqués, sans trop de bla bla bla +1 de ma part!
Adelin

3
Excellent résumé avec un exemple innovant
Ravindra babu


77

Référence faible http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/ref/WeakReference.html

Principe: weak reference est lié à la collecte des ordures. Normalement, un objet en ayant un ou plusieurs referencene sera pas éligible pour la récupération de place.
Le principe ci-dessus n'est pas applicable lorsqu'il l'est weak reference. Si un objet n'a qu'une référence faible avec d'autres objets, il est prêt pour la collecte des ordures.

Regardons l'exemple ci-dessous: Nous avons un Mapavec des objets où Key fait référence à un objet.

import java.util.HashMap;   
public class Test {

    public static void main(String args[]) {
        HashMap<Employee, EmployeeVal> aMap = new 
                       HashMap<Employee, EmployeeVal>();

        Employee emp = new Employee("Vinoth");
        EmployeeVal val = new EmployeeVal("Programmer");

        aMap.put(emp, val);

        emp = null;

        System.gc();
        System.out.println("Size of Map" + aMap.size());

    }
}

Maintenant, pendant l'exécution du programme que nous avons fait emp = null. La Maptenue la clé n'a pas de sens ici comme il est null. Dans la situation ci-dessus, l'objet n'est pas récupéré.

WeakHashMap

WeakHashMapest celui où les entrées ( key-to-value mappings) seront supprimées lorsqu'il ne sera plus possible de les récupérer à partir du Map.

Permettez-moi de montrer l'exemple ci-dessus avec WeakHashMap

import java.util.WeakHashMap;

public class Test {

    public static void main(String args[]) {
        WeakHashMap<Employee, EmployeeVal> aMap = 
                    new WeakHashMap<Employee, EmployeeVal>();

        Employee emp = new Employee("Vinoth");
        EmployeeVal val = new EmployeeVal("Programmer");

        aMap.put(emp, val);

        emp = null;

        System.gc();
        int count = 0;
        while (0 != aMap.size()) {
            ++count;
            System.gc();
        }
        System.out.println("Took " + count
                + " calls to System.gc() to result in weakHashMap size of : "
                + aMap.size());
    }
}

Sortie: a pris 20 calls to System.gc()pour résultat aMap size: 0.

WeakHashMapn'a que des références faibles aux clés, pas des références fortes comme les autres Mapclasses. Il y a des situations auxquelles vous devez faire attention lorsque la valeur ou la clé est fortement référencée bien que vous l'ayez utilisée WeakHashMap. Cela peut être évité en enveloppant l'objet dans une référence faible .

import java.lang.ref.WeakReference;
import java.util.HashMap;

public class Test {

    public static void main(String args[]) {
        HashMap<Employee, EmployeeVal> map = 
                      new HashMap<Employee, EmployeeVal>();
        WeakReference<HashMap<Employee, EmployeeVal>> aMap = 
                       new WeakReference<HashMap<Employee, EmployeeVal>>(
                map);

        map = null;

        while (null != aMap.get()) {
            aMap.get().put(new Employee("Vinoth"),
                    new EmployeeVal("Programmer"));
            System.out.println("Size of aMap " + aMap.get().size());
            System.gc();
        }
        System.out.println("Its garbage collected");
    }
}

Références souples.

Soft Referenceest légèrement plus fort que la référence faible. La référence logicielle permet le ramasse-miettes, mais demande au ramasse-miettes de l'effacer uniquement s'il n'y a pas d'autre option.

Le ramasse-miettes ne collecte pas de manière agressive les objets facilement accessibles comme il le fait avec les objets peu accessibles - au lieu de cela, il ne collecte les objets facilement accessibles que s'il "a vraiment besoin" de la mémoire. Les références souples sont une façon de dire au garbage collector: "Tant que la mémoire n'est pas trop serrée, je voudrais garder cet objet autour. Mais si la mémoire devient vraiment serrée, allez-y et récupérez-la et je traiterai avec ça." Le garbage collector est nécessaire pour effacer toutes les références logicielles avant de pouvoir lancer OutOfMemoryError.


5
Vous pouvez obtenir un NullPointerExceptiondansaMap.get().put(...) .
xehpuk

Votre premier exemple HashMap semble incorrect. Lorsque vous effectuez "aMap.put (emp, val);" 'emp' et 'val' sont des références fortes. En interne, une nouvelle variable est créée pour contenir 'emp' et 'val' donc quand vous faites "emp = null;" vous annulez simplement la variable "emp", mais pas la variable en interne à la carte de hachage (qui contient toujours l'objet Employee d'origine). Par conséquent, la carte de hachage contiendra toujours une référence forte à «emp», indépendamment de ce que vous faites avec la variable «emp» à l'extérieur.
Tiago

@Tiago. Non. Vraisemblablement par "premier exemple", vous faites référence à l' WeakHashMapexemple (puisque c'est le premier qui démontre un comportement faible). Regardez le document pour "WeakHashMap": "An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use. " L'intérêt de l'utilisation de WeakHashMap est que vous n'avez pas à déclarer / transmettre un WeakReference; le WeakHashMap le fait pour vous, en interne. docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
ToolmakerSteve

A pris 0 appels à System.gc () pour entraîner une taille de HashMap faible: 0 est la sortie de votre deuxième programme?
Adelin

1
Pour un autre exemple de WeakHashMapen action, avec un exemple d'application montrant comment les entrées sont supprimées uniquement après l' exécution de la récupération de place, voir ma réponse à la question, WeakHashMap est-il en constante croissance, ou efface-t-il les clés de récupération? .
Basil Bourque

50

La seule vraie différence entre une référence douce et une référence faible est que

le garbage collector utilise des algorithmes pour décider de récupérer ou non un objet facilement accessible, mais récupère toujours un objet faiblement accessible.


@ATorras, Samir. J'ai développé cette réponse ici: stackoverflow.com/a/46291143/632951
Pacerier

25

SoftReferenceest conçu pour les caches. Lorsqu'il est constaté qu'un a fait WeakReferenceréférence à un objet autrement inaccessible, il sera immédiatement effacé. SoftReferencepeut être laissé tel quel. En règle générale, il existe un algorithme relatif à la quantité de mémoire libre et au dernier temps utilisé pour déterminer si elle doit être effacée. L'algorithme Sun actuel consiste à effacer la référence si elle n'a pas été utilisée en autant de secondes qu'il y a de mégaoctets de mémoire libre sur le tas Java (configurable, le serveur HotSpot vérifie le maximum de tas possible défini par -Xmx). SoftReferences sera effacé avant OutOfMemoryErrorson lancement, sauf indication contraire.


9
Mais dans Android, il n'est pas conseillé pour les caches developer.android.com/reference/java/lang/ref/…
Yaroslav Mytkalyk

4
@DoctororDrive tbf la question portait sur java, pas sur dalvik! :-P
fabspro

2
@YaroslavMytkalyk, Franchement, si Android veut réécrire le comportement d'une classe, il devrait utiliser son propre espace de noms, non java.lang. Un tel abus de synonymes ne fait de bien à personne.
Pacerier

9

Cet article peut être très utile pour comprendre les références fortes, douces, faibles et fantômes.


Pour vous donner un résumé,

Si vous n'avez que des références faibles à un objet (sans références fortes), alors l'objet sera récupéré par GC lors du tout prochain cycle GC.

Si vous n'avez que des références logicielles à un objet (sans références fortes), l'objet ne sera récupéré par GC que lorsque JVM manque de mémoire.


Vous pouvez donc dire que les références fortes ont un pouvoir ultime (ne peuvent jamais être collectées par GC)

Les références souples sont puissantes que les références faibles (car elles peuvent échapper au cycle GC jusqu'à ce que JVM manque de mémoire)

Les références faibles sont encore moins puissantes que les références douces (car elles ne peuvent échapper à aucun cycle GC et seront récupérées si l'objet n'a pas d'autre référence forte).


Restaurant Analogy

  • Serveur - GC
  • Vous - Objet en tas
  • Espace / espace de restauration - Espace de stockage
  • Nouveau client - Nouvel objet qui veut une table au restaurant

Maintenant, si vous êtes un client fort (analogue à une référence forte), alors même si un nouveau client vient au restaurant ou quoi qu'il arrive, vous ne quitterez jamais votre table (la zone de mémoire sur le tas). Le serveur n'a pas le droit de vous dire (ni même de vous demander) de quitter le restaurant.

Si vous êtes un client doux (analogue à une référence douce), alors si un nouveau client vient au restaurant, le serveur ne vous demandera pas de quitter la table à moins qu'il ne reste plus de table vide pour accueillir le nouveau client. (En d'autres termes, le serveur vous demandera de quitter la table uniquement si un nouveau client intervient et qu'il n'y a plus d'autre table pour ce nouveau client)

Si vous êtes un client faible (analogue à une référence faible), le serveur, à sa guise, peut (à tout moment) vous demander de quitter le restaurant: P


7

La seule vraie différence

Selon le document , les WeakReferences lâches doivent être effacées par un GC en cours d'exécution.

Selon le document , les références logicielles lâches doivent être effacées avant que le MOO ne soit lancé.

C'est la seule vraie différence. Tout le reste ne fait pas partie du contrat. (Je suppose que les derniers documents sont contractuels.)

Les références logicielles sont utiles.Les caches sensibles à la mémoire utilisent des références logicielles, pas des références faibles.


La seule utilisation appropriée de WeakReference est d'observer le fonctionnement du GC. Pour ce faire, créez un nouveau WeakReference dont l'objet sort immédiatement de la portée, puis essayez d'en retirer null weak_ref.get(). Quand c'est le cas null, vous apprenez qu'entre cette durée, le GC a fonctionné.

Quant à une mauvaise utilisation de WeakReference, la liste est interminable:

  • un hack moche pour implémenter une référence souple de priorité 2 de sorte que vous n'ayez pas à en écrire une, mais cela ne fonctionne pas comme prévu car le cache serait effacé à chaque exécution du GC, même lorsqu'il y a de la mémoire disponible. Voir https://stackoverflow.com/a/3243242/632951 pour les phails. (D'ailleurs, que se passe-t-il si vous avez besoin de plus de 2 niveaux de priorité de cache? Vous auriez toujours besoin d'une vraie bibliothèque pour cela.)

  • un hack moche pour associer des données à un objet d'une classe existante, mais cela crée une fuite de mémoire (OutOfMemoryError) lorsque votre GC décide de faire une pause après la création de vos faibles références. En outre, c'est au-delà de la laideur: une meilleure approche consiste à utiliser des tuples.

  • un hack moche pour associer des données à un objet d'une classe existante, où la classe a le culot de se rendre non sous-classable, et est utilisé dans un code de fonction existant que vous devez appeler. Dans un tel cas, la solution appropriée consiste soit à éditer la classe et à la rendre sous-classable, soit à éditer la fonction et à lui faire prendre une interface à la place d'une classe, ou à utiliser une fonction alternative.


Qu'en est-il d'un cache où le type de clé equals()n'est qu'une identité d'objet? Les références logicielles semblent être un gaspillage là-bas, car une fois qu'un objet clé n'est plus fortement accessible, personne ne cherchera plus jamais ce mappage.
HighCommander4

Je ne suis pas d'accord. Utilisez WeakReference lorsque vous ne voulez pas influencer le GC de toute façon (vous voudrez peut-être enregistrer une référence d'objet, puis vérifier plus tard si elle existe toujours, sans aucune préférence). Utilisez SoftReference si vous voulez influencer le GC pour essayer de garder l'objet (c'est-à-dire quand vous préférez que le GC le garde).
David Refaeli

Un bon exemple où utiliser WeakReference est dans AsyncTask d'Android - pour conserver une instance du contexte. De cette façon, si le contexte meurt (si activité - rotation d'écran, etc.), la tâche AsyncTask n'aura aucune référence forte à elle, et elle peut donc être récupérée. Vérifiez youtu.be/…
David Refaeli

3

Les six types d'états d'accessibilité aux objets en Java:

  1. De fortes objets ly accessibles - GC ne Collect ( récupérer la mémoire occupée par ) ce genre d'objet. Ceux-ci sont accessibles via un nœud racine ou un autre objet fortement accessible (c'est-à-dire via des variables locales, des variables de classe, des variables d'instance, etc.)
  2. Doux ly objets accessibles - GC peuvent tenter de recueillir ce type d'objet en fonction de contention mémoire. Ceux-ci sont accessibles depuis la racine via un ou plusieurs objets de référence logicielle
  3. La faiblesse des objets ly accessibles - GC doivent recueillir ce genre d'objet. Ceux-ci sont accessibles depuis la racine via un ou plusieurs objets de référence faibles
  4. Objets ressuscitables - GC est déjà en train de collecter ces objets. Mais ils peuvent revenir à l'un des états - Fort / Doux / Faible par l'exécution de certains finaliseurs
  5. Objet fantôme accessible - GC est déjà en train de collecter ces objets et a déterminé qu'il ne peut être ressuscité par aucun finaliseur (s'il déclare lui-même une méthode finalize (), alors son finaliseur aura été exécuté) . Ceux-ci sont accessibles depuis la racine via un ou plusieurs objets de référence fantômes
  6. Objet inaccessible - Un objet n'est ni fortement, doucement, faiblement, ni fantôme accessible, et ne peut pas être ressuscité. Ces objets sont prêts à être récupérés

Pour plus de détails: https://www.artima.com/insidejvm/ed2/gc16.html «réduire


4
Pas une bonne description des références fantômes. Vous avez également répertorié les 4 types dans un ordre particulier. "fantôme" est le type le plus faible, pas le type le plus fort. L'ordre traditionnel de les énumérer est "fort, doux, faible, fantôme". Et je n'ai aucune idée d'où vous avez eu l'idée que les objets fantômes sont utilisés pour les mécanismes de mise en cache. AFAIK, ils sont un état temporaire vu uniquement par le GC, pas quelque chose avec lequel un programmeur ordinaire travaillerait.
ToolmakerSteve

@ToolmakerSteve et tous - Toutes mes excuses pour deux choses 1. la mauvaise explication des références Phantom dans la version précédente de ma réponse, et 2. Retard dans la correction des erreurs. Maintenant, la réponse a été améliorée en corrigeant les erreurs
V.Vidyasagar

1

Il faut savoir qu'un objet faiblement référencé ne sera collecté que s'il a UNIQUEMENT des références faibles. S'il a autant qu'une référence forte, il n'est pas collecté quel que soit le nombre de références faibles qu'il possède.


C'est du bon sens ... il en va de même pour softref et phantomref.
Pacerier

1

Pour donner un aspect d'utilisation de la mémoire en action, j'ai fait une expérience avec des références fortes, douces, faibles et fantômes sous forte charge avec des objets lourds en les conservant jusqu'à la fin du programme. Puis suivi de l'utilisation du tas et du comportement du GC . Ces mesures peuvent varier au cas par cas, mais donnent certainement une compréhension de haut niveau. Voici les résultats.

Comportement du tas et du GC sous une charge élevée

  • Strong / Hard Reference - Pendant la poursuite du programme, JVM n'a pas pu collecter d'objet référencé fort conservé. Finalement fini dans "java.lang.OutOfMemoryError: Java heap space"
  • Référence souple - Au fur et à mesure que le programme se poursuivait, l'utilisation du segment de mémoire continuait de croître, mais le VIEUX GC de génération s'est produit lorsqu'il était proche du segment de mémoire maximal. GC a démarré un peu plus tard après le démarrage du programme.
  • Référence faible - Au démarrage du programme, les objets ont commencé à finaliser et à être collectés presque immédiatement. La plupart des objets ont été collectés dans la collecte des ordures de la jeune génération.
  • Référence fantôme - Semblable à une référence faible, les objets référencés fantômes ont également commencé à être finalisés et les ordures collectées immédiatement. Il n'y avait pas de GC de l'ancienne génération et tous les objets étaient collectés dans la collecte des ordures de la jeune génération elle-même.

Vous pouvez obtenir des graphiques plus détaillés , des statistiques, des observations pour cette expérience ici .


0

WeakReference : les objets qui ne sont que faiblement référencés sont collectés à chaque cycle GC (mineur ou complet).

SoftReference : lorsque des objets qui sont uniquement référencés en douceur sont collectés, cela dépend:

  1. -XX: indicateur SoftRefLRUPolicyMSPerMB = N (la valeur par défaut est 1000, alias 1 seconde)

  2. Quantité de mémoire libre dans le tas.

    Exemple:

    • le tas dispose de 10 Mo d'espace libre (après GC complet);
    • -XX: SoftRefLRUPolicyMSPerMB = 1000

    Ensuite, l'objet qui n'est référencé que par SoftReference sera collecté si la dernière fois lors de son accès est supérieure à 10 secondes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.