Java Singleton vs statique : y a-t-il un réel avantage en termes de performances ?

Question

Je fusionne une branche CVS et l'un des changements les plus importants est le remplacement, partout où il se produit, d'un modèle Singleton par des classes abstraites dotées d'un bloc d'initialisation statique et de toutes les méthodes statiques.

Est-ce quelque chose qui vaut la peine d'être conservé car cela nécessitera de fusionner de nombreux conflits, quel genre de situation devrais-je envisager pour que cette refactorisation en vaille la peine ?

Nous exécutons cette application sous Weblogic 8.1 (donc JDK 1.4.2)

---

désolé Thomas, laisse-moi clarifier..

la version HEAD a le modèle singleton traditionnel (constructeur privé, getInstance() etc)

la version branche n'a pas de constructeur, est une « classe abstraite publique » et a modifié toutes les méthodes de l'objet pour qu'elles soient « statiques ».Le code qui existait dans le constructeur privé est déplacé dans un bloc statique.

Ensuite, toutes les utilisations de la classe sont modifiées, ce qui provoque plusieurs conflits lors de la fusion.

Il existe quelques cas où ce changement a été effectué.

Answer 1

D’un strict point de vue des performances d’exécution, la différence est vraiment négligeable.La principale différence entre les deux réside dans le fait que le cycle de vie « statique » est lié au classloader, alors que pour le singleton il s'agit d'un cycle de vie d'instance régulier.Habituellement, il est préférable de rester à l'écart du business ClassLoader, vous évitez certains problèmes délicats, notamment lorsque vous essayez de recharger l'application Web.

Answer 2

J'utiliserais un singleton s'il avait besoin de stocker n'importe quel état, et des classes statiques sinon.Cela ne sert à rien d'instancier quelque chose, même une seule instance, à moins qu'il ne soit nécessaire de stocker quelque chose.

Answer 3

La statique est mauvaise pour l'extensibilité puisque les méthodes et les champs statiques ne peuvent pas être étendus ou remplacés par des sous-classes.

C'est également mauvais pour les tests unitaires.Dans un test unitaire, vous ne pouvez pas empêcher les effets secondaires des différents tests de se propager puisque vous ne pouvez pas contrôler le chargeur de classe.Les champs statiques initialisés dans un test unitaire seront visibles dans un autre, ou pire, l'exécution de tests simultanément donnera des résultats imprévisibles.

Singleton est généralement un modèle correct lorsqu’il est utilisé avec parcimonie.Je préfère utiliser un framework DI et le laisser gérer mes instances pour moi (éventuellement dans différentes portées, comme dans Guice).

Answer 4

Si mon message d'origine était la bonne compréhension et que la discussion de Sun à laquelle elle était liée est exacte (ce qui, je pense, pourrait être le cas), alors je pense que vous devez faire un compromis entre clarté et performances.

Posez-vous ces questions :

1. L'objet Singleton rend-il plus clair ce que je fais ?
2. Ai-je besoin d’un objet pour effectuer cette tâche ou est-il plus adapté aux méthodes statiques ?
3. Ai-je besoin des performances que je peux gagner en n’utilisant pas de Singleton ?

Answer 5

D'après mon expérience, la seule chose qui compte est de savoir lequel est le plus facile à simuler dans les tests unitaires.J'ai toujours pensé que Singleton était plus facile et naturel à ridiculiser.Si votre organisation vous permet d'utiliser JMockit, cela n'a pas d'importance puisque vous pouvez surmonter ces problèmes.

Answer 6

Cette discussion est-elle utile ?(Je ne sais pas si c'est tabou de créer un lien vers un autre forum de programmation, mais je préfère ne pas simplement citer toute la discussion =) )

Soleil Discussion à ce sujet

Le verdict semble être que cela ne fait pas suffisamment de différence pour avoir de l'importance dans la plupart des cas, même si techniquement les méthodes statiques sont plus efficaces.

Answer 7

Écrivez du code pour mesurer les performances.La réponse dépendra de la JVM (le JDK de Sun peut fonctionner différemment de JRockit) et des indicateurs de VM utilisés par votre application.