boulbo
Messages postés9Date d'inscriptionsamedi 8 avril 2006StatutMembreDernière intervention21 novembre 2010
-
21 nov. 2010 à 12:01
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020
-
31 mai 2011 à 12:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
Je ne suis pas d'accord avec certaines choses que tu avances, notamment sur la JVM de Sun, tu pourrais au moins argumenter, avancer des éléments de preuve.
Le passage sur le singleton ne distingue pas la "lazy instantiation" et l'instantiation au démarrage. Ton implémentation n'est pas thread-safe.
L'"object pooling" est déconseillé depuis Java 1.4 comme il ne permet plus d'améliorer les performances donc la partie 1.5 n'est pas d'une grande utilité.
La partie 1.6 est fausse. Mettre les références à null n'est pas suffisant. Si tu appelles System.gc() sans lancer la finalisation des objets avec System.runFinalization(), ça ne va pas servir à grand chose. Appeler System.gc() trop souvent est très dangereux et peut causer des problèmes de gestion du cache de la machine virtuelle. Tu aurais mieux fait de parler des paramétrages de la JVM et du choix du ramasse-miettes, notamment du G1.
Ton tutoriel ne permet pas d'améliorer nettement les performances, ton approche est très naïve. Bon courage.
ag050276
Messages postés2Date d'inscriptionvendredi 29 décembre 2000StatutMembreDernière intervention25 novembre 2010 25 nov. 2010 à 09:44
Salut,
Le plus important dans ce que j'ai rajouté, c'est :
1 - Initialiser les attributs par l'instanciation de la classe dans la méthode newInstance(), cela permet de garder toujours les bonnes pratique en programmation objet.
2 - L'instanciation se fait dans une méthode synchronisée (très important), car on peut considérer que le corps de la méthode getInstance() comme section critique. L'instance peut être sollicitée par plusieurs threads en même temps ce qui peut provoquer un inter-blocage (sujet très vaste et riche à la fois), ici la méthode newInstance() sert de verrou.
J'espère te convainre...
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020371 24 nov. 2010 à 05:57
Enfin, on peut presque faire comme tu le fais, si on utilise des attributs à la classe, on s'orientera plutôt vers le design pattern poids mouche avec une HashMap pour conserver tous les objets créés. Je vais bientot poster une nouvelle version et j'explique cette méthode.
Merci
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020371 24 nov. 2010 à 05:55
Ha non, je vois ce que tu veux dire, c'est utiliser le constructeur avec deux attributs, oui, c'est vrai, j'ai instancié les variables directement par facilité mais on peut aussi faire comme tu le fais.
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020371 24 nov. 2010 à 05:53
Je suis désolé mais je ne vois pas l'amélioration apportée, surtout que tu vérifie deux fois si l'instance est nulle avec ta méthode...
ag050276
Messages postés2Date d'inscriptionvendredi 29 décembre 2000StatutMembreDernière intervention25 novembre 2010 23 nov. 2010 à 17:22
Je voudrais juste rajouter une petite amélioration pour l'histoire des singletons :
1 - Avoir le constructeur Singleton() avec les deux attributs attribut1 et attribut2
2 - Avoir la méthode getInstance(String attribut1, String attribut2) au lieu de getInstance() et au même temps elle fera appel à une méthode synchronisée afin d'initialiser l'instance ainsi que les variables d'instances.
public static Singleton getInstance(String attribut1, String attribut2){
if (Singleton.instance == null){
newInstance(attribut1, attribut2);
}
return Singleton.instance;
}
private synchronized static void newInstance(String attribut1, String attribut2){
if (Singleton.instance == null){
Singleton.instance = new Singleton(attribut1, attribut2);
}
}
}
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020371 22 nov. 2010 à 17:46
Voilà une information intéressante, j'ignorais tout ça, je l'ajouterai au tutoriel.
Merci
uhrand
Messages postés491Date d'inscriptionsamedi 20 mai 2006StatutMembreDernière intervention15 juillet 20129 22 nov. 2010 à 12:23
Utilisez la nouvelle classe StringBuilder dans la mesure du possible.
* StringBuilder a été introduit dans le JDK 1.5 pour remplacer StringBuffer dans l'usage "single-threaded".
* StringBuffer est conçu pour être "thread-safe" et toutes les méthodes publiques dans StringBuffer sont synchronisées. StringBuilder ne gère pas la question de sécurité des threads et aucune de ses méthodes est synchronisée.
* StringBuilder a de meilleures performances que StringBuffer dans la plupart des cas.
La classe parente de StringBuilder et de StringBuffer s'appelle "AbstractStringBuilder" et contient un attribut de type char[] de taille par défaut 16, qui est utilisé pour le stockage des caractères. C'est donc un tableau qui n'est pas dynamique et il est important de spécifier la taille des StringBuilder si on la connait d'avance (comparer avec le paragraphe "Initialiser la taille des ArrayList").
Salutations,
André
boulbo
Messages postés9Date d'inscriptionsamedi 8 avril 2006StatutMembreDernière intervention21 novembre 2010 21 nov. 2010 à 12:01
31 mai 2011 à 12:36
8 déc. 2010 à 14:46
Je ne suis pas d'accord avec certaines choses que tu avances, notamment sur la JVM de Sun, tu pourrais au moins argumenter, avancer des éléments de preuve.
Le passage sur le singleton ne distingue pas la "lazy instantiation" et l'instantiation au démarrage. Ton implémentation n'est pas thread-safe.
L'"object pooling" est déconseillé depuis Java 1.4 comme il ne permet plus d'améliorer les performances donc la partie 1.5 n'est pas d'une grande utilité.
La partie 1.6 est fausse. Mettre les références à null n'est pas suffisant. Si tu appelles System.gc() sans lancer la finalisation des objets avec System.runFinalization(), ça ne va pas servir à grand chose. Appeler System.gc() trop souvent est très dangereux et peut causer des problèmes de gestion du cache de la machine virtuelle. Tu aurais mieux fait de parler des paramétrages de la JVM et du choix du ramasse-miettes, notamment du G1.
Ton tutoriel ne permet pas d'améliorer nettement les performances, ton approche est très naïve. Bon courage.
25 nov. 2010 à 09:44
Le plus important dans ce que j'ai rajouté, c'est :
1 - Initialiser les attributs par l'instanciation de la classe dans la méthode newInstance(), cela permet de garder toujours les bonnes pratique en programmation objet.
2 - L'instanciation se fait dans une méthode synchronisée (très important), car on peut considérer que le corps de la méthode getInstance() comme section critique. L'instance peut être sollicitée par plusieurs threads en même temps ce qui peut provoquer un inter-blocage (sujet très vaste et riche à la fois), ici la méthode newInstance() sert de verrou.
J'espère te convainre...
24 nov. 2010 à 05:57
Merci
24 nov. 2010 à 05:55
24 nov. 2010 à 05:53
23 nov. 2010 à 17:22
1 - Avoir le constructeur Singleton() avec les deux attributs attribut1 et attribut2
2 - Avoir la méthode getInstance(String attribut1, String attribut2) au lieu de getInstance() et au même temps elle fera appel à une méthode synchronisée afin d'initialiser l'instance ainsi que les variables d'instances.
Récapitulatifs :
public class Singleton {
private static Singleton instance;
private String attribut1;
private String attribut2;
private Singleton(String attribut1, String attribut2){
this.attribut1 = attribut1;
this.attribut2 = attribut2;
}
public static Singleton getInstance(String attribut1, String attribut2){
if (Singleton.instance == null){
newInstance(attribut1, attribut2);
}
return Singleton.instance;
}
private synchronized static void newInstance(String attribut1, String attribut2){
if (Singleton.instance == null){
Singleton.instance = new Singleton(attribut1, attribut2);
}
}
}
22 nov. 2010 à 17:46
Merci
22 nov. 2010 à 12:23
* StringBuilder a été introduit dans le JDK 1.5 pour remplacer StringBuffer dans l'usage "single-threaded".
* StringBuffer est conçu pour être "thread-safe" et toutes les méthodes publiques dans StringBuffer sont synchronisées. StringBuilder ne gère pas la question de sécurité des threads et aucune de ses méthodes est synchronisée.
* StringBuilder a de meilleures performances que StringBuffer dans la plupart des cas.
La classe parente de StringBuilder et de StringBuffer s'appelle "AbstractStringBuilder" et contient un attribut de type char[] de taille par défaut 16, qui est utilisé pour le stockage des caractères. C'est donc un tableau qui n'est pas dynamique et il est important de spécifier la taille des StringBuilder si on la connait d'avance (comparer avec le paragraphe "Initialiser la taille des ArrayList").
Salutations,
André
21 nov. 2010 à 12:01