Champs d'Instance, les éléments du tableau
Si il y a une référence à un objet, il ne peut pas être nettoyée. Surtout si cet objet (et de tout le graphe derrière elle) est grand, il y a seulement un ouvrage de référence qui est l'arrêt de la collecte des ordures, et que la référence n'est pas vraiment besoin de plus, c'est une situation regrettable.
Des cas pathologiques, sont l'objet qui conserve une unnessary exemple à l'ensemble du DOM XML arbre qui a été utilisé pour le configurer, le MBean qui n'a pas été enregistré, ou de la seule référence à un objet à partir d'un non-déployée application web qui empêche tout un chargeur de classe déchargé.
Donc, sauf si vous êtes sûr que l'objet qui contient la référence elle-même sera nettoyée de toute façon (ou même à l'époque), vous devez null tout ce que vous n'avez plus besoin.
Portée des variables:
Si vous envisagez de définition d'une variable locale à null avant la fin de son champ d'application , de sorte qu'il peut être récupéré par le ramasse-miettes et de le marquer comme "inutilisable à partir de maintenant", vous devriez envisager de le mettre dans un champ plus restreint à la place.
{
BigObject obj = ...
doSomethingWith(obj);
obj = null; // <-- explicitly set to null
doSomethingElse();
}
devient
{
{
BigObject obj = ...
doSomethingWith(obj);
} // <-- obj goes out of scope
doSomethingElse();
}
Long, plat étendues sont généralement mauvais pour la lisibilité du code, trop. L'introduction de méthodes privées de casser des choses juste pour que le but n'est pas rare, trop.
