TUTORIEL : UN CODE JAVA PLUS RAPIDE
boulbo
Messages postés
9
Date d'inscription
samedi 8 avril 2006
Statut
Membre
Dernière intervention
21 novembre 2010
-
21 nov. 2010 à 12:01
cs_Julien39 Messages postés 6414 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 29 juillet 2020 - 31 mai 2011 à 12:36
cs_Julien39 Messages postés 6414 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 29 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.
https://codes-sources.commentcamarche.net/source/52488-tutoriel-un-code-java-plus-rapide
https://codes-sources.commentcamarche.net/source/52488-tutoriel-un-code-java-plus-rapide
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