Finalisation gracieusement du référent de softreufence

Toms Réponse est la bonne, cependant, le code qui a été ajouté à la question n'est pas le même que celui proposé par Tom. Ce que Tom proposait ressemble plus à ceci:

class Bloat {  // just a heap filler really
    public Reader res;
    private double a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;

    private final int ii;

    public Bloat(final int ii, Reader res) {
       this.ii = ii;
       this.res = res;
    }
 }

 // as recommended by Tom Hawtin
 class MySoftBloatReference extends SoftReference<Bloat> {
    public final Reader hardRef;

    MySoftBloatReference(Bloat referent, ReferenceQueue<Bloat> q) {
       super(referent, q);
       this.hardRef = referent.res;
    }
 }

 //...meanwhile, somewhere in the neighbouring galaxy...
 {
    ReferenceQueue<Bloat> rq = new ReferenceQueue<Bloat>();
    Set<SoftReference<Bloat>> set = new HashSet<SoftReference<Bloat>>();
    int i=0;

    while(i<50000) {
        set.add(new MySoftBloatReference(new Bloat(i, new StringReader("test")), rq));

        MySoftBloatReference polled = (MySoftBloatReference) rq.poll();

        if (polled != null) {
            // close the reference that we are holding on to
            try {
                polled.hardRef.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
        i++;
    }
}

AHM.
(Pour autant que je sache), vous ne pouvez pas tenir le bâton des deux extrémités. Soit vous tenez à votre information ou vous le laissez aller.
Cependant ... vous pouvez conserver certaines informations clés qui vous permettraient de finaliser. Bien entendu, les informations essentielles doivent être considérablement plus petites que les "informations réelles" et ne doivent pas avoir les informations réelles dans son graphique d'objet accessible (des références faibles pourraient vous aider là-bas).
Construire sur l'exemple existant (faites attention au champ Informations de clé): XXX

EDIT:
Je veux élaborer sur le "Tenir ton information ou le laisser aller". En supposant que vous ayez eu une façon de tenir votre information. Cela aurait forcé le GC à ne faire valoir que vos données, que les données ne soient réellement nettoyées qu'après que vous avez terminée, dans un deuxième cycle de GC. C'est possible - et c'est exactement ce que finaliser () est pour. Puisque vous avez déclaré que vous ne voulez pas que le deuxième cycle se produise, vous ne pouvez pas contenir vos informations (si A -> B! B ->! A). Ce qui signifie que vous devez le laisser partir.

Edit2:
En fait, un deuxième cycle se produirait - mais pour vos "données clés", pas vos "données de bloat majeur". Les données réelles seraient effacées sur le premier cycle.

Edit3:
De toute évidence, la solution réelle utiliserait un thread séparé pour éliminer de la file d'attente de référence (ne pas sonder (), retirer (), blocage sur le fil dédié).

@Paul - Merci beaucoup pour la réponse et la clarification.

@ran - Je pense que dans votre code actuel I ++ manque à la fin de la boucle. De plus, vous n'avez pas besoin de faire rq.remove () dans la boucle que Rq.Poll () supprime déjà la référence en haut, n'est-ce pas?

quelques points:

1) J'ai dû ajouter des instructions de thread.sleep (1) après i ++ dans la boucle (pour les deux solutions de Paul et Ran) pour éviter l'OMM mais qui n'est pas pertinente pour la grande image et que la plate-forme dépend également. Ma machine a un processeur quad-core et exécute Sun Linux 1.6.0_16 JDK.

2) Après avoir examiné ces solutions, je pense que je vais coller à l'aide de finaliseurs. Le livre de Bloch fournit des raisons suivantes:

• Il n'y a pas de finaliseurs de garantie ne sera exécuté rapidement, donc ne faisant rien de temps critique dans un finaliseur - ni de garanties pour SOFTRERERENCES!
• ne dépend jamais d'un finaliseur pour mettre à jour l'état persistant critique - je ne suis pas
• Il y a une pénalité de performance grave pour l'utilisation de finaliseurs - dans mon pire des cas, je finaliserais d'un seul objet par minute environ. Je pense que je peux vivre avec ça.
• Utilisez Essayez / enfin - oh oui, je vais certainement!

  Avoir une nécessité de créer une énorme quantité d'échafaudeuse juste pour ce qui semble qu'une tâche simple ne me semble pas raisonnable. Je veux dire, littéralement, le taux de WTF par minute serait assez élevé pour quiconque en regardant ce code.

  3) saddly, il n'y a aucun moyen de diviser les points entre Paul, Tom et Ran :( J'espère que Tom ne me dérangerait pas comme il en avait déjà beaucoup d'entre eux :) Juger entre Paul et Ran était beaucoup plus difficile - je pense que les deux réponses au travail et sont correctes. Je ne fixe que le drapeau à la réponse de Paul, car il a été jugé plus élevé (et a une explication plus détaillée), mais la solution de Ran n'est pas mauvaise du tout et serait probablement mon choix si j'avais choisi de le mettre en œuvre à l'aide de Softreferences. Merci gars!