Comment écrire du code pour aider le garbage collector

Le garbage collector est très efficace et adroit dans son travail mais nous pouvons améliorer sa capacité à collecter les ordures en pointant les variables et les objets sur null, qui ne sont plus utilisés et il n'y a plus de références à eux. Pendant la gestion des fichiers, utilisez les méthodes close () et flush (). Et dans la gestion des threads, détruit le thread lorsqu'il n'est pas utilisé.

Le Garbage Collector est une "tâche" qui scanne périodiquement vos objets pour détecter ce qui n'est pas utilisé (en réalité, c'est un mécanisme pour émuler une machine avec une mémoire infinie).

Pour cette raison, lorsque vous êtes contenant une référence à une instance d'objet dont vous n'avez plus besoin, vous devez la définir sur null afin de faire savoir au Garbage Collector que vous n'êtes plus intéressé par cette instance (et éventuellement ses descendants).

Cela ne signifie pas que vous devez définir chaque variable sur null après utilisation, mais vous devez surveiller les champs. Comme Java n'a pas de modèle de suppression (voir ici pour plus d'informations), vous devez concevoir vos API pour l'imiter: lorsque vous avez fini d'utiliser une instance d'objet contenant une référence que vous souhaitez libérer, vous devez ajouter une méthode appropriée pour effectuer une telle action.

Prenons l'exemple suivant:

XXX

Si une instance de MyClass2 est conservée mais une autre instance accessible de votre programme (par exemple un singleton, ou une instance actuellement dans la pile), vous ne libérerez jamais la mémoire associée à MyClass1 car elle est toujours référencé par m_MyReference.

Est-ce mauvais? Cela dépend de ce que MyClass2 et MyClass1 font vraiment.

Si vous savez que MyClass2 pourrait avoir une très longue durée de vie et que vous souhaitez conserver la référence à MyClass2 mais pour libérer la mémoire associée à MyClass1, vous devez faites quelque chose de similaire au code ci-dessous:

class MyClass2
{
    private MyClass1 m_MyReference;

    public MyClass2()
    {
        m_MyReference = new MyClass1();
    }

    public void DoSomething()
    {
        // do something here that uses m_MyReference.
    }

    public void Dispose()
    {
        m_MyReference = null;
    }

}

De cette façon, vous exposez à l'appelant un moyen de signaler que vous ne détenez plus de référence à des instances dont vous n'avez pas besoin.

N'oubliez pas que le simple fait d'affecter null à une variable ou un champ ne libère pas automatiquement la mémoire. Le garbage collector est asynchrone et s'exécute lorsqu'il le décide. J'espère avoir donné l'idée sans aller trop loin.

La question est formulée bizarrement. Le GC n'a pas besoin d'aide dans son travail. Il fonctionnera avec toutes les contraintes qui lui sont imposées ou échouera si les contraintes ne peuvent pas être satisfaites.

Bien sûr, le travail peut être modifié, mais cela ne se fait pas par désir d'alléger le fardeau du GC - ce n'est pas un être humain qui peut s'ennuyer par son travail - mais en raison d'une arrière-pensée, telle que améliorer les performances globales du programme.

Ces éléments sont normalement définis comme des optimisations de latence, de consommation d'énergie, de débit ou d'empreinte mémoire. Mais ce ne sont pas les seules mesures qui intéressent un programmeur. La simplicité et la lisibilité du code sont également importantes.

Le code naïf peut être plus lisible mais moins performant. Si votre objectif est un code facile à lire, effectuer des optimisations complexes qui réduisent la charge du GC pourrait être contre-productif et donc "aider le GC" n'est pas un objectif en soi.

Maintenant, si votre objectif est d'améliorer certaines métriques de performances, certaines optimisations impliquent également l'écriture de code qui réduit le travail effectué par le sous-système de gestion de la mémoire (allocation + GC). Certaines optimisations possibles consistent à éviter les finaliseurs, à trouver des fuites de mémoire, à réduire les allocations inutiles, à éviter les énormes tableaux Object [], à régler les paramètres GC, à acheter un meilleur matériel et à réduire la durée de vie des objets. L'optimisation applicable dépend de l'application et peut être mieux identifiée avec les profileurs, la journalisation GC et autres