private static final String vs inline

Bonjour à tous,

J'ai une question au sujet du comportement mémoire de la JVM sur deux utilisations de String.
Entre les deux bouts de code suivants:

Code:

---

1 2 3 4 5 6 7 8

private static final String CONSTANT_NAME = "untel";   (...)   if (var.equalsIgnoreCase(CONSTANT_NAME)) { (...) }

---

et

Code:

---

1 2 3 4

if (var.equalsIgnoreCase("untel")) { (...) }

---

Y en a t'il un qui est plus performant que l'autre ? Comment se passe la gestion de ces deux String en mémoire ? Il me semble qu'elles devraient toutes les deux arriver dans le même pool de String, mais du coup, je n'arrive pas à voir si le comportement à l'éxécution est le même ou pas.

J'ai fait un tour du côté du forum de Sun, mais je n'ai pas trouvé la réponse à cette question (d'où la ressemblance au sujet http://forum.java.sun.com/thread.jsp...5686&tstart=60 )

Merci d'avance

Reeter

Un string est considéré comme constant s'il est défini avec des guillemets ou s'il est défini avec les mot clé final static. S'il est constant, alors une seule instance du string existe en mémoire, il est écrit en dur dans le bytecode.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class A { public static final String MON_STRING = "mon_string"; }   public class B { public static final String MON_AUTRE_STRING = "mon_string"; }   public class Main { public static void main (String... args) { String a = A.MON_STRING.substring(0); // a = "mon_string", mais a est une instance créée au runtime et non à la compilation, donc ce n'est pas la même instance. System.out.println(A.MON_STRING == B.MON_AUTRE_STRING); // true System.out.println(a == A.MON_STRING); // false; } }

---

Dans l'exemple que tu donnes, aucun n'est plus optimisé que l'autre, tous deux donneront le même bytecode (à l'exception de la constante CONSTANT_NAME qui existe dans l'un et pas dans l'autre).

Salut,


Dans ce cas précis les deux codes sont équivalents, puisque CONSTANT_NAME est une "variable constante". C'est à dire un attribut static final auquel on assigne une expression constante évaluable à la compilation.

Le compilateur remplace ainsi toutes les occurrences de CONSTANT_NAME par sa valeur lors de la compilation.


Plus d'info : Qu'est-ce qu'une constante ?

a++

PS à noter que c'est également le cas pour les variables locales finales.

OK.

Par conséquent, si j'ai, dans plusieurs objets, un appel à une fonction du type:

Code:

---

1 2	var.setName("lenom");

---

Ca ne sert à rien (au niveau des perfs) de déclarer une static final string dans un coin pour l'utiliser de la sorte:

Code:

---

1 2	var.setName(CONSTANT_NAME);

---

Je ne parle qu'au niveau des performances.

C'est bien ça ?



EDIT: Passé en résolu suite à la seconde réponse.

Au niveau des perfs, non. Au niveau sémantique, il est toujours préférable d'utiliser les constantes ;)

Salut,

Je me suis posé la même question... mais pas tout a fait de la même manière:

quel est la différence entre:
1) methodTraitanLesString("mon_string");
et
2 ) public static final char MON_STRING[] = "mon_string"; 8O
et
3) public static final String MON_STRING = "mon_string";

J'ai un peu tourné en rond avant de trouver une...

Réponse:
1) le compilateur associe un numero d'entrée dans le constant pool à la string qui sera référencé par ce numéro si elle est utilisé plusieurs fois. Donc c'est la solution qui consome le moins de mémoire (fichier.class tout comme JVM RAM)

2) Le compilateur associe deux string dans le constant pool: "MON_STRING" et "mon_string". A l'initialisation de la class, "MON_STRING" sera chargé ainsi que "mon_string". Donc une memoire consommée plus grande fichier.class tout comme JVM RAM)

3) pareil que en 2 sauf que "mon_string" est alors un objet de type String qui contiens un tableau de char.

NB: la plus part des JVM on des tables de hachage. Donc toute déclaration du type 2) ou 3) engendre un traitement supplémentaire, le temps de ranger la donnée dans la table de hachage. :aie:

Conclusion: Pour une optimisation de tout type de mémoire et de temps CPU, ne créez pas de fields avec un nom.
Par contre niveau relecture de code, c'est vachement plus propore. :mrgreen:
Et comme le java est un langage qui a été créé dans un but de faciliter la vie du programmeur tout en perdant de la capacité mémoire et du temps de calcul... :mouarf: Alors arrêtez de vous prendre le choux, et pensez à quand vous vous relirez: utilisez des final string. :yaisse2: