Maintenant, j'ai récemment rencontré une recommandation que vous devriez utiliser le mot-clé final aussi large que possible. C'est bon afin d'empêcher un programmeur de tirer sur sa propre jambe - c'est-à-dire de réaffecter la variable qui ne doit pas être réaffectée.
Mais, cela dessert-il un autre objectif? C'est-à-dire que la JVM peut-elle utiliser des informations sur les variables finales afin d'optimiser la bytecode en quelque sorte, de sorte qu'elle serait plus rapide (construisant une meilleure pipeline ou l'utiliser dans un environnement multithread)? Ou est juste un sucre syntaxique qui minimise la possibilité d'erreurs pendant le développement de code?
4 Réponses :
En ce qui concerne les variables Go, Java est suffisamment intelligente pour comprendre qu'une variable n'est modifiée nulle part dans la méthode et utilisez ces connaissances à des fins d'optimisation. Il n'a pas besoin de vous pour marquer une variable Les méthodes sont une histoire légèrement différente: lorsque vous marquez une méthode Généralement, cependant, cette recommandation est destinée à rendre votre code plus facile à lire et à comprendre par d'autres: faire une variable finale vous dit des lecteurs que vous faites une constante; Faire une finale de classe indique à vos lecteurs que la classe n'est pas conçue pour l'héritage; Faire une méthode finale indique à vos lecteurs que la logique de cette méthode devrait rester invariante dans la hiérarchie de l'héritage. À long terme, ces informations sont plus utiles que le potentiel d'optimisation de votre code d'exécution. finale afin de savoir que.
finale , Java peut invoquer une telle méthode plus rapidement, car elle n'a plus besoin de vérifier ses dérogations. Néanmoins, Hotspot est suffisamment intelligent pour comprendre qu'il n'y a pas de remplacement, avec ou sans l'utilisation de final .
Qu'en est-il des méthodes privées? Ont-ils besoin d'un mot clé final? Après tout, ils ne peuvent certainement pas être remplacés.
@ Spirit_1984 Les méthodes privées n'ont pas besoin d'être marquées finale - ils bénéficient de la même optimisation que les méthodes finales ( statique méthodes d'obtention aussi, car Ils ne peuvent pas être remplacés dans Java).
"Java" (Hotspot Vraiment) est généralement assez intelligent pour comprendre si une méthode n'est jamais écrasée et que ces optimisations, de toute façon, donc ouais, le dernier paragraphe.
Les méthodes finales peuvent ou non être inlinées par la JVM jusqu'à ce qu'elles soient chargées par la JVM. Donc, si vous êtes sûr que la méthode ne sera pas redéfinie, marquez-la comme finale.
Les constantes doivent toujours être finales statiques car elles seront immuables et JVM n'a pas besoin de garder une trace de ces variables car elles ne changeront jamais.
Si vous êtes sûr que la méthode ne sera pas redéfinie, marquez-la comme finale. Je ne le sentirais jamais de cela à moins que je ne connaissais une raison pour laquelle la méthode doit ne pas être redéfini (par exemple, s'il est appelé d'un constructeur). Ce n'est pas parce que je ne peux pas penser à une raison de remplacer une méthode ne signifie pas qu'un autre programmeur ne pensera pas à une raison.
@ James-Large, généralement lorsque vous construisez une bibliothèque et que vous souhaitez contrôler les classes et les méthodes "autorisés" à être remplacés, le mot clé final vous donne simplement un mécanisme à le faire. C'est ce que je voulais dire par ma déclaration.
Droite, et je ne voudrais jamais contrôler cela à moins que je ne connaissais un cas particulier où une dérogation client pourrait empêcher l'une des classes Mes de se comporter de la manière dont j'ai promis cela se comporterait.
Je pense que cette recommandation est un peu trop non spécifique.
Par exemple; Je recommanderais d'éviter d'utiliser la finale sur les classes et les méthodes par défaut (car les tests de classes de classes finales vous obligent à vous obliger à utiliser des frameworks de test d'unité spécifiques pour surmonter les méthodes / classes des finales.
Je trouve également que l'utilisation de paramètres de méthode finale n'est qu'une perte de "espace d'écran" (et donc: gaspiller "énergie" sur le côté du lecteur).
D'autre part, n'ayant que des attributs finaux pour les classes peuvent transformer des objets de ces classes dans des trucs immuables; et c'est une bonne chose.
comme vous le voyez; Il y a beaucoup de pros et de contre sur l'utilisation de la finale; et je pense que la "lisibilité" gagne le plus souvent sur des améliorations de performance "potentielles".
Comme beaucoup de mythes sur la performance Java, la croyance erronée selon laquelle déclarer des cours ou des méthodes en tant que résultats finaux en meilleure performance est largement détenue mais rarement examinée. L'argument va que la déclaration de méthode ou de classe en tant que final signifie que le compilateur peut appelle la méthode en ligne d'appels de manière plus agressive, car elle sait qu'au moment de l'exécution, il s'agit certainement de la version de la méthode qui va être appelée. Mais ce n'est tout simplement pas vrai. Juste parce que la classe X est compilée contre la classe finale Y ne signifie pas que la même version de la classe Y sera chargée au moment de l'exécution. Donc, le compilateur ne peut pas entrer en ligne de cette méthode de la classe intervalle d'appels en toute sécurité, finale ou non. Seulement si une méthode est privée, le compilateur peut-il l'aligner librement, et dans ce cas, le mot clé final serait redondant.
finale ou vous pouvez dire des optimisations de l'aide constante dans le compilateur. E.g: - Pliage constant, propagation constante
Related: Stackoverflow.com/Questtions/3961881/...
"Ou est juste un sucre syntaxique qui minimise la possibilité d'erreurs pendant le développement du code?" La pensée intelligente réelle minimise les erreurs. Sans cela, le dernier mot clé n'est pas seulement syntaxique sucre, mais un placebo aussi.