TUTORIEL : UN CODE JAVA PLUS RAPIDE

Signaler
Messages postés
9
Date d'inscription
samedi 8 avril 2006
Statut
Membre
Dernière intervention
21 novembre 2010
-
cs_Julien39
Messages postés
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
-
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

cs_Julien39
Messages postés
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
266
Il y a le forum pour ca...
Utilisateur anonyme
Bonjour

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és
2
Date d'inscription
vendredi 29 décembre 2000
Statut
Membre
Dernière intervention
25 novembre 2010

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és
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
266
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és
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
266
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és
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
266
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és
2
Date d'inscription
vendredi 29 décembre 2000
Statut
Membre
Dernière intervention
25 novembre 2010

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.

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);
}
}
}
cs_Julien39
Messages postés
6413
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
17 mai 2018
266
Voilà une information intéressante, j'ignorais tout ça, je l'ajouterai au tutoriel.

Merci
uhrand
Messages postés
491
Date d'inscription
samedi 20 mai 2006
Statut
Membre
Dernière intervention
15 juillet 2012
9
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és
9
Date d'inscription
samedi 8 avril 2006
Statut
Membre
Dernière intervention
21 novembre 2010

merci pour ce petit tuto, mais pertinent ;)