Autant que je sache, en Java si nous voulons appeler manuellement le collectionneur des ordures que nous pouvons faire système.gc ().
1. Quelles sont les opérations que nous faisons à l'intérieur de notre méthode de finalisation de la nervation ()?
2.Est-ce qu'il faut remplacer la méthode finaliser () si nous voulons appeler manuellement le collecteur de poubelles JVM?
8 Réponses :
1.Quelles sont les opérations que nous faisons à l'intérieur de notre méthode de remplacement de la nervation ()?
Nettoyage des ressources qui ne peuvent pas être gérées par la collecte des ordures.
2.is il est nécessaire de remplacer la méthode finaliser () si nous voulons appeler manuellement le collecteur de poubelles JVM?
Non, ces deux choses ne sont pas liées.
finaliser ne doit certainement pas appeler le collecteur des ordures lui-même. En fait, finaliser s'appelle par le collecteur des ordures (mais n'est pas garanti d'être appelé du tout).
Remplacer la méthode de finale est souvent effectué si vous devez libérer manuellement des ressources (en particulier celles qui utiliseraient de grandes quantités de mémoire ou causer des serrures, s'ils n'étaient pas libérés). Par exemple, si vous avez un objet qui dispose d'un verrou sur un fichier ou une table de base de données, vous souhaiterez peut-être remplacer votre méthode de finalisation afin de libérer ces objets à utiliser lorsque votre objet est recruté.
Quant à savoir si la finalisation prépondérante est requise ou non, elle n'est absolument pas. Vous pouvez appeler system.gc () sans jamais remplacer une méthode de finalisation. Un mot de prudence, cependant - appeler system.gc () ne dicte pas absolument que le collecteur des ordures fera n'importe quoi. Considérez cela plus d'une «recommandation» à la JVM de gérer la collecte des ordures, par opposition à un «mandat».
La seule chose que j'ajouterais, c'est que vous devriez essayer aussi fort que possible de libérer toutes les ressources sans jamais utiliser finaliser () car il peut blesser la performance, et il n'y a pas de garanties sur le moment où elle sera appelée.
Je suis d'accord avec Adam pour quelques raisons. En effet, l'utilisation finale peut nuire à votre performance, mais il est difficile d'utiliser en raison du fait que vous ne savez jamais vraiment quand il sera appelé. La collecte des ordures est effectuée sur son propre horaire et, même si vous appelez system.gc (), vous ne pouvez pas force cela se produira. En tant que telle, la libération des ressources dans votre méthode de finalisation peut entraîner toutes sortes de choses étranges qui se produisent car il est plus difficile de suivre le flux de votre application. Je suggérerais fortement de libérer des ressources dès que possible et aussi explicitement que possible afin de faciliter votre vie.
Merci beaucoup pour la réponse ... Si je remplace la finalisation () dans ma classe, alors comment appeler cette méthode ?? Ou JVM elle-même au moment de la collection de la poubelle appellera ma substitution Finailze () ??
Vous pouvez l'appeler comme n'importe quelle méthode d'instance. Cela dit, l'ensemble de la méthode de finalisation est que vous n'avez pas à l'appeler. Lorsque le JVM exécute son processus de collecte des ordures, cela appellera finaliser sur chaque objet qu'il a l'intention de prendre des ordures. Le JVM invoquera votre méthode finalisée une seule fois, jamais. Cependant, si vous l'appelez directement, vous pouvez l'invoquer autant de fois que vous le souhaitez. Si vous avez l'intention d'appeler la méthode vous-même, n'utilisez pas finaliser - simplement faire une méthode et utilisez-la. Utilisez finaliser si vous souhaitez exploiter le collecteur des ordures.
Pour des cas très rares, il peut être utile ou nécessaire d'implémenter Peut être utile si vous travaillez avec un code natif et que vous devez libérer des ressources allouées dans la zone de code natif.
mais utilisez-le avec précaution, car implémenter finaliser pour libérer des ressources allouées. Cette méthode est toujours appelée quand une instance est détruite enfin.
enfin ralentira considérablement le collecteur des ordures et tuera les performances.
Finaliser la répartition (l'objet est ajouté à une liste liée avant que le C-Tor ne soit appelé), pas la collection à la poubelle. finaliser () est également exécuté dans un fil séparé aussi.
1) Tout nettoyage que vous souhaitez faire sur la destruction de l'objet (si vous gardez des poignées ouvertes et que personne n'a été explicite de près par exemple). Gardez à l'esprit que vous ne savez pas quand cela se produira car le JVM appellera le GC et non vous.
2) Nope.
Note latérale, vous ne devez pas appeler manuellement le collecteur des ordures, voir la réponse ici, Pourquoi ne pas expliquer explicitement finaliser () ou démarrer le collecteur des ordures?
Je continue à entendre qu'il n'y a aucune garantie que finalisera () sera appelée, mais quelle est la probabilité que Java n'appellera pas finaliser () pour un objet dans un programme de longue date, à l'exception des cas d'arrêt JVM avant de se déplacer à cela? ... ou devrait-il être une question distincte?
Il sera appelé au moins une fois. Eh bien, j'ai signalé un bogue à JBoss l'année dernière parce que je manquais de poignées de fichier. Ils fermaient leurs ressources de fichiers dans la méthode finalisée () et j'ai manifesté avant que une finalisation n'ait été appelée. Il se résume à la taille de l'application, aux paramètres de la mémoire et à l'alignement des planètes. Il est bon de garder à l'esprit que cela pourrait ne pas arriver et peut-être une fermeture explicite est meilleure.
Non, cela peut être jamais appelé. Et relâcher des poignées dans finaliser la méthode est une programmation erro. Ils doivent être réélinés manuellement quand ils ne sont plus nécessaires ( essayez enfin pour les ressources de nettoyage)
@Tataeusz wow, en fait, vous êtes correct. Passé Java.Lang.Shutdown, vous devez explicitement dire à la JVM de faire fonctionner les finaliseurs à la sortie. Donc, ils pourraient ne pas être appelé du tout!
Mais quelle est la probabilité? Si j'écris une application Java Swing (disons un IDE) et que l'utilisateur est proche de l'application et que les ressources Syoustems ne seront pas à maxe, etc. dans ce type de scénario sont des finaliseurs à proximité de Garantie pour être exécutées?
Ceux qui sont entre le dernier GC et l'arrêt ne seront pas exécutés. Voir System.RunFinalizersonExit () Javadoc, ils l'avaient laissé cela, mais maintenant marqué comme non sûr et donc obsolète.
Il n'y a aucune garantie que le finaliseur sera appelé rapidement, vous ne devez rien faire de manière critique dans votre méthode de finalisation.
D'autres ont déjà expliqué la méthode finalisée.
Notez toutefois que les meilleures pratiques sont de concevoir une méthode "fermeture" / "nettoyage" / "terminaison" pour fermer / nettoyer l'objet et demander au développeur d'appeler cette méthode explicitement. Les finaliseurs ne doivent être utilisés que comme filet de sécurité. (Voir "Point 7: Évitez les finaliseurs" de "Java efficace" de Joshua Bloch)
Dans ce cas, envisagez également d'implémenter autoclotionable pour supporter des blocs d'essai avec ressources.
Quelles sont les opérations que nous faisons à l'intérieur de notre méthode de finalisation ultérieure ()?
Mémoire libre alociée manuellement (à travers des appels autochtones), c'est-à-dire non géré par GC. C'est une situation vraiment rare. Certaines personnes y installent également un chèque, que d'autres ressources liées à l'objet ont déjà été publiées - mais ce n'est que pour le débogage et ce n'est pas très fiable.
Vous devez vous rappeler que:
finaliser est sur la mémoire et la seule mémoire.- Vous n'avez aucun contrôle quand il sera invoqué et même si est invoqué.
SO
JAMAIS Mettez là libérer toute autre ressource (comme poignées de fichier, serrures). Toutes ces ressources doivent être libérées manuellement.
Et le remplacement de la finalisation n'a rien à voir avec l'appelantsystem.gc () .
@andreas_d: Je suis d'accord avec quel récif dit et ce qu'il implique est que, si finaliser () contient du code qui rend l'instance actuelle inéligible à GC, c'est-à-dire la ramener à la vie en donnant une référence à cet exemple. , puis la prochaine fois que cette instance devient admissible à GC, ne vous attendez pas à ce que la finalisation () soit appelée à nouveau par la JVM. En ce qui concerne la JVM, elle a fait son devoir en appelant finaliser () une fois et ne peut pas être dérangé de le faire à nouveau et encore parce que vous continuez à revenir à la vie. S'il l'a fait, cet objet ne serait jamais gc. (Bien sûr, vous voudrez peut-être que l'instance ne soit jamais GC'ed. Ensuite, il suffit de faire une référence à une référence. Si aucun thread en direct n'a référence à l'instance, l'instance est aussi bonne que morte, de toute façon.)
Plus probablement, vous n'aurez jamais besoin de finaliser () en plus de vous connecter à la trace des fuites, gardez à l'esprit que finaliser () ralentit (considérablement) les objets et nécessite la mise en œuvre correctement de la synchronisation.
Et remarquez que votre méthode
finaliser () est appelée, sera appelée une seule fois.Ici vous supposez que system.gc () permet à GC manuel. En réalité, ce n'est pas "manuel" dans le sens JVM pourrait ou non pas suivre cette demande. Cet appel n'est qu'un indice à la VM.