StringBuilder vs concaténation de Chaîne dans toString() en Java

Donné le 2 toString() implémentations ci-dessous, qui est préférée:

public String toString(){
    return "{a:"+ a + ", b:" + b + ", c: " + c +"}";
}

public String toString(){
    StringBuilder sb = new StringBuilder(100);
    return sb.append("{a:").append(a)
          .append(", b:").append(b)
          .append(", c:").append(c)
          .append("}")
          .toString();
}

Plus important, étant donné que nous n'avons que 3 biens qu'il ne peut pas faire une différence, mais à quel point voulez-vous passer de + concat à StringBuilder?

À quel point pensez-vous passer à StringBuilder? Quand il les effets de la mémoire ou de la performance. Ou quand il peut. Si vous êtes vraiment seulement faire cela pour un couple de chaînes une fois, pas de soucis. Mais si vous allez faire encore et encore, vous devriez voir une différence mesurable lors de l'utilisation de StringBuilder.
quelle est la moyenne de 100 en paramètre?
100 est la taille initiale de StringBuilder
De sorte que le nombre de caractères maximum sera de 100?
non seulement la taille initiale, si vous savez la taille approximative de la chaîne que vous faites affaire avec, alors vous pouvez dire StringBuilder la taille à allouer l'avance sinon il sera, si elle est à court d'espace, de doubler la taille par la création d'une nouvelle char[] tableau puis copier les données de plus - ce qui est coûteux. Vous pouvez tricher en donnant la taille et il n'est pas nécessaire pour cette création de la matrice - donc, si vous pensez que votre chaîne sera de ~100 caractères vous pouvez ensuite régler le StringBuilder de cette taille et il ne sera jamais amené à développer en interne.
Documents connexes: stackoverflow.com/documentation/java/109/strings/5280/...
c'est même intellij-support.jetbrains.com/hc/en-us/community/posts/...

InformationsquelleAutor non sequitor | 2009-10-07

927

La Version 1 est préférable car il est plus court et le compilateur va en effet tourner vers la version 2 - pas de différence de performances que ce soit.

Plus important encore, étant donné que nous n'avons que 3
les propriétés qu'elle ne pourrait pas faire un
différence, mais à quel point pensez-vous
commutateur de concat pour builder?

Au point où vous êtes la concaténation dans une boucle - c'est généralement lorsque le compilateur ne peut pas se substituer StringBuilder par lui-même.
- C'est vrai, mais la langue de référence précise également que c'est facultatif. En fait, j'ai juste fait un test simple avec le JRE 1.6.0_15 et je ne vois pas l'optimisation du compilateur dans le décompilé classe.
- Je Viens d'essayer le code à partir de la question (compilé sur JDK 1.6.0_16) et a trouvé l'optimisation comme prévu. Je suis sûr que tous les compilateurs modernes de le faire.
- Vous êtes correct. En regardant le bytecode je peux clairement voir le StringBuilder d'optimisation. J'ai été en utilisant un décompilateur et, d'une façon, c'est de le convertir en concat. +1
- Je suppose que le decompiler essayé d'être plus intelligent dans la restauration le code source d'origine 🙂 j'ai utilisé (probablement l'ancienne version de l') JAD.
- Eh bien, je suppose que cette révélation fait ma question discutable acclamations.
- La seule différence est la taille de paramètre donné dans l'initialisation.
- la différence entre les deux les plus utilisés décompilation existe pour la concaténation de chaîne: JAD montre StringBuilder, JD-GUI montre la concaténation. Si vous ouvrez le .fichier de classe dans n'importe quel éditeur vous verrez StringBuilder références, ainsi que l'optimisation sera fait, c'est juste JD-GUI montrant plus "conviviaux" - comme la concaténation
- Je crois que plus de considération dans l'optimisation de l'utilisation de StringBuilder vs concaténation (en dehors d'une boucle) si vous êtes à la construction de plusieurs Chaînes de caractères. Est le compilateur assez intelligent pour réutiliser le StringBuilder il ajoute avec setLength(0)? Si elle n'est pas le cas, alors vous pouvez le faire manuellement au lieu de le compilateur optimisant la concaténation, mais manquant de l'optimisation de la réutilisation des StringBuilder.
- Pas de battre un cheval mort, mais le libellé de la spec est: To increase the performance of repeated string concatenation, a Java compiler _may_ use the StringBuffer class or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression. Le mot-clé qu'il soit peut. Étant donné que c'est officiellement en option (bien que probablement mis en œuvre) devrions-nous pas nous protéger?
- Non, nous ne devrions pas. Si le compilateur décide de ne pas effectuer cette optimisation, c'est parce qu'il n'est pas la peine. Dans 99% des cas, le compilateur sait mieux d'optimisation qui en vaut la peine, donc, en règle générale, les dev ne doit pas interférer. Bien sûr, votre situation peut automne dans l'autre 1%, mais qui ne peut être vérifié par (prudent) d'analyse comparative.
- Je ne pense pas que vous avez raison. Le compilateur a une capacité limitée de trouver de possibles optimisations. Il ne le fera pas penser pour vous.
- Merci, est-ce vrai aussi pour Visual Basic?
- Le byte code peut être vu ici: bpaste.net/show/Z8o0hdiCerkFUXhaeU7L notez que les numéros de ligne ne correspondent pas, mais il EST le code est correct
- J'ai une question de suivi sur le dernier paragraphe de votre réponse. Alors pourquoi ne pas le compilateur d'optimiser la boucle cas? Vous avez dit généralement il ne peut pas. Pouvez-vous expliquer?
- Les gars dans la documentation, il dit StringBuffer pas StringBuilder et tampon est certainement plus lent que le constructeur qu'il est synchronisé et chaque opération est l'ajout de verrouillage aquireing et en libérant les opérations avec elle... Dois-je comprendre que c'est? ou il me manque quelque chose?
- la spec dit "peut utiliser la classe StringBuffer ou une technique similaire". Mentionner StringBuffer est un peu un anachronisme (surtout depuis qu'il est toujours resté inchangé dans le courant de JLS pour Java 8) mais c'est tout. En outre, un moderne JVM pouvez souvent éliminer les serrures de synchroniser le code si il peut déterminer qu'un objet ne peut jamais être consulté par différents threads.
- Est-il un outil pour montrer ce + pour le Générateur de Chaîne de traduction ? Je sais que c'est évident, à partir du bytecode, mais si il y a un outil qui peut montrer cela, ce serait génial 🙂
- est exactement l'outil dont vous avez besoin. Voir stackoverflow.com/a/47628/632951
- href="http://www.pellegrino.link/2015/08/22/string-concatenation-with-java-8.html" >blog c'est la peine de lire. Il explique pourquoi StringBuilder est plus rapide, ne nous en avons besoin dans Java 8, etc... dans le détail. Recommande fortement.
- Je ne pense pas que cela soit toujours vrai. Récemment, j'ai optimisé un morceau de code dans une boucle, par la suppression de tous les "+"et de les remplacer par un stringbuilder, et le rendement est passé de ~500 itérations en 20 secondes à 35 000 itérations dans les 5 secondes. J'ai été vraiment choqué par la différence. Il y avait aussi des concaténations d'entiers que j'ai remplacé avec de la Ficelle.format des appels, ce qui a probablement ajouté à l'amélioration de la performance; honnêtement, je ne suis pas sûr de laquelle le changement a eu le plus grand impact. Mais en supposant que le "+" est toujours juste l'amende est une erreur.
- Ce ne peut pas être plus vrai et pour tous les cas - par défaut, StringBuilder est initialisé avec une capacité de 16. Si la dynamique arguments sont assez longues, alors la totalité de la chaîne de caractères qui sera peut-être plus longue, auquel cas chaque ajout nécessiterait interne de la matrice de redimensionnement, ce qui aurait une incidence sur les performances. La deuxième approche, cependant, initialise le générateur avec une capacité de 100, ce qui augmente de beaucoup la durée potentielle d'arguments imprimé, et n'a donc pas d'impact sur les performances si plus de cas.
- Cette réponse doit être modifié - Si vous passez par la mutable conteneurs logique - StringBuilder est mieux adapté pour les Grandes Opérations.
- J'ai utilisé de la Chaîne pour concaténer 18MO de données avec Java 1.8. L'algorithme a pris 15 minutes. J'ai changé de Chaîne pour StringBuilder et le même algorithme a pris 500 millisecondes. Donc, il n'ya AUCUNE garantie que le compilateur optimise.
- lire l'intégralité de la réponse. Y compris la dernière phrase.
InformationsquelleAutor Michael Borgwardt
239

La clé est de savoir si vous êtes l'écriture d'une simple concaténation de tous dans un endroit, ou accumuler au fil du temps.

Pour l'exemple que vous avez donné, il n'y a aucun point en utilisant explicitement StringBuilder. (Regardez le code compilé pour votre premier cas.)

Mais si vous êtes la construction d'une chaîne de caractères par exemple à l'intérieur d'une boucle, utiliser StringBuilder.

De préciser, en supposant que hugeArray contient des milliers de chaînes de caractères, le code comme ceci:
```
...
String result = "";
for (String s : hugeArray) {
    result = result + s;
}
```
beaucoup de temps et de mémoire de gaspillage par rapport à:
```
...
StringBuilder sb = new StringBuilder();
for (String s : hugeArray) {
    sb.append(s);
}
String result = sb.toString();
```
- Oui, StringBuilder n'a pas besoin de re-créer la Chaîne de l'objet à plusieurs reprises.
- Zut j'ai utilisé ces 2 la fonction de test d'une chaîne de caractères, je suis en train de travailler. 6.51 min vs 11secs
- Par la façon dont vous pouvez utiliser result += s; ainsi (dans le premier exemple)
- combien d'objet sera créé par cette déclaration? "{a:"+ a + ", b:" + b + ", c: " + c +"}";
- Juste une. Si vous compilez et regardez-le byte code, vous verrez un StringBuilder l'instanciation, une série de append appels, et un toString appel (la séquence exacte est trop long pour moi de coller dans un commentaire).
- Que penser de quelque chose comme: String str = (a == null) ? null : a' + b == null) ? null : b' + (c == null) ? c : c' + ...; ? Volonté qui empêchent l'optimisation de passe?
- J'ai effectivement vérifié (recherche javap, vous pouvez analyser le bytecode avec elle) et, avec un peu modifié l'exemple (String str = ((a == null) ? a1 : a) + ((b == null) ? b1 : b) + ((c == c1) ? null : c);), il produit encore des optimisations, en cours d'Exécution avec un javac 1.8.0_102.
- Je voudrais revenir à mon premier critère: "...si vous écrivez une simple concaténation..." Même si vous avez des sous-expressions (qui contiennent des opérateurs ternaires), l'ensemble de la concaténation processus est dans un état unique, connaissable au moment de la compilation.
- C'est un exemple, lorsque vous ne pouvez pas attendre les optimisations du compilateur, et la raison pour laquelle vous devez être prudent au sujet de votre code
- Je me demande pourquoi le compilateur ou JIT ne pas l'optimiser dans ce cas.
InformationsquelleAutor joel.neely
74

Que je préfère:
```
String.format( "{a: %s, b: %s, c: %s}", a, b, c );
```
...parce que c'est court et facile à lire.

Je pas optimiser ce pour la vitesse, sauf si vous l'utilisez à l'intérieur d'une boucle avec un très grand nombre de répétitions et ont mesuré la différence de performances.

Je suis d'accord, que si vous avez à la sortie de beaucoup de paramètres, ce formulaire peut prêter à confusion (comme l'un des commentaires dire). Dans ce cas, j'aimerais passer à une forme plus lisible (peut-être en utilisant ToStringBuilder de apache commons - extrait de la réponse de matt b) et d'ignorer les performances de nouveau.
- C'est plus long, contient plus de symboles et a des variables d'un texte de la séquence.
- Donc vous diriez que c'est moins lisible que l'un de l'autre aproaches?
- Je préfère l'écriture, parce que c'est plus facile d'ajouter plus de variables, mais je ne suis pas sûr que c'est plus lisible, surtout que le nombre d'arguments est grande. Il ne fonctionne pas pour les moments où vous avez besoin d'ajouter des morceaux à des moments différents.
- Semble plus difficile à lire (pour moi). Maintenant, je dois d'analyse en arrière-et-vient entre {...} et les paramètres.
- Je préfère cette forme, parce qu'il est sûr, si l'un des paramètre est null
- Nope, plaine de concaténation a+b fait la même chose exacte que format si b est null. Les deux méthodes se traduire par l'ajout de la chaîne de la valeur "null".
- en effet. null + "issimo" produit "nullissimo".
- C'est moins lisible, car il y a plus de caractères à lire, par rapport à la Question de l'option 1, et il y a une complexité supplémentaire pour comprendre la fonction format (par rapport à littérale de concaténation).
- Je déteste vraiment cette. Pour ceux d'entre nous qui ne l'utilisez pas, il est plus difficile à traiter que d'un simple +. À côté, vous ne pouvez pas lire de gauche à droite comme en anglais. Nom de dieu. Je suis fou
- Il est plus lisible dans certains cas, mais vous pouvez facilement oublier l'un des %s ou params et à vérifier l'ensemble du code à l'aide de FindBugs ou de certains IDE fonctionnalité (comme pour les journaux).
- J'ai utiliser des chaînes de caractères.format à l'occasion (qui, rappelons-le, n'était pas disponible dans les premières versions de Java). Il y a certains avantages par rapport à la simple concaténation: le format peut être ré-utilisé, il permet simple contrôle de largeurs (y compris les fractions chiffres), une fois que vous devenez utilisé pour le % de la notation, il peut être plus facile de visualiser le résultat (surtout lors du rendu avec des combinaisons de signes de ponctuation).
- YMMV, mais je l'ai lu de gauche à droite par la pensée de la chaîne de format comme un pochoir et de la suite des expressions de peinture et de contenu. Alors... "Format/remplir [dans] cette chaîne [avec] ces valeurs".
- Ouais, il pourrait être plus facile une fois que vous vous habituez à elle
- Si Oracle pourrait enfin bouger son cul, ils ne pouvaient tout simplement le soutien de la chaîne de interpolaton comme la plupart des autres langues modernes n': "Bonjour, $nom,$, vous devez les messages.size() questions."
- Chaîne de caractères.le format n'est pas courte, ni lisible(omi). Je me souviens de l'apprentissage de cette dans CS1 et va wtf? Je préfère de beaucoup de concaténation ou même l'utilisation de StringBuilder. Peut-être qu'un jour nous serons bénis avec de la Ficelle de l'interpolation en Java.
- Dommage qu'il n'est pas en C#: $"{a}, {b}, {c}". 🙂
InformationsquelleAutor tangens
71

Dans la plupart des cas, vous ne pourrez pas voir une réelle différence entre les deux approches, mais il est facile de construire un scénario du pire des cas comme celui-ci:
```
public class Main
{
    public static void main(String[] args)
    {
        long now = System.currentTimeMillis();
        slow();
        System.out.println("slow elapsed " + (System.currentTimeMillis() - now) + " ms");

        now = System.currentTimeMillis();
        fast();
        System.out.println("fast elapsed " + (System.currentTimeMillis() - now) + " ms");
    }

    private static void fast()
    {
        StringBuilder s = new StringBuilder();
        for(int i=0;i<100000;i++)
            s.append("*");      
    }

    private static void slow()
    {
        String s = "";
        for(int i=0;i<100000;i++)
            s+="*";
    }
}
```
La sortie est:
```
slow elapsed 11741 ms
fast elapsed 7 ms
```
Le problème, c'est que pour += ajouter à une chaîne reconstruit une nouvelle chaîne, si il en coûte quelque chose de linéaire de la longueur de vos chaînes (somme des deux).

Donc à votre question:

La deuxième approche serait plus rapide, mais c'est moins lisible et plus difficile à maintenir.
Comme je l'ai dit, dans votre cas particulier, vous ne serait probablement pas voir la différence.
- De ne pas l'oublier .concat(). Je voudrais estimer le temps écoulé pour être n'importe où de 10 à 18 ms rendant négligeable lors de l'utilisation de chaînes courtes comme le post original exemple.
- Alors vous avez raison à propos de +=, l'exemple d'origine était une séquence de +, que le compilateur transforme d'un seul string.concat appel. Vos résultats ne s'appliquent pas.
- Droo :- Vous tous les deux ont raison.À l'aide de .concate dans un tel scénario est la meilleure solution de contournement,comme += crée un nouvel objet à chaque fois que la boucle routine s'exécute.
- savez-vous que son toString() n'est pas appelée dans une boucle?
- J'ai essayé cet exemple pour tester la vitesse. Si mes résultats sont: lent écoulé 29672 ms; rapide écoulé 15 ms. Donc, la réponse est évidente. Mais si il serait de 100 itérations en temps est le même - 0 ms. Si 500 itérations - 16 ms et 0 ms. Et ainsi de suite.
- Chaîne de caractères.la concaténation de deux fois plus rapide que StringBuffer.ajouter
- peut très bien être, cette réponse est en avant de la Chaîne.concat existé. mais ne démontrent avec code à la place des mots 🙂
- La différence de temps est venue parce que votre code pour qu'il boucle à l'intérieur de lent() compile de ce-- str = new StringBuilder().append(str).append("*").toString();
- La concaténation est compilé par défaut pour StringBuilder seulement. Mais, dans le cas des boucles de la toString est appelée plusieurs fois.
InformationsquelleAutor Omry Yadan

J'ai aussi eu un clash avec mon patron sur le fait de savoir si l'utilisation d'ajout ou +.Comme ils sont en utilisant Append(je ne peux pas comprendre comme ils le disent à chaque fois qu'un nouvel objet est créé).
J'ai donc pensé à faire quelques R&D. Bien que j'aime Michael Borgwardt explication mais je voulais juste montrer une explication si quelqu'un en aura vraiment besoin de savoir à l'avenir.

/**
 *
 * @author Perilbrain
 */
public class Appc {
    public Appc() {
        String x = "no name";
        x += "I have Added a name" + "We May need few more names" + Appc.this;
        x.concat(x);
        //x+=x.toString(); --It creates new StringBuilder object before concatenation so avoid if possible
        //System.out.println(x);
    }

    public void Sb() {
        StringBuilder sbb = new StringBuilder("no name");
        sbb.append("I have Added a name");
        sbb.append("We May need few more names");
        sbb.append(Appc.this);
        sbb.append(sbb.toString());
        //System.out.println(sbb.toString());
    }
}

et le démontage de la classe ci-dessus en tant que

 .method public <init>()V //public Appc()
.limit stack 2
.limit locals 2
met001_begin:                                  ; DATA XREF: met001_slot000i
.line 12
aload_0 ; met001_slot000
invokespecial java/lang/Object.<init>()V
.line 13
ldc "no name"
astore_1 ; met001_slot001
.line 14
met001_7:                                      ; DATA XREF: met001_slot001i
new java/lang/StringBuilder //1st object of SB
dup
invokespecial java/lang/StringBuilder.<init>()V
aload_1 ; met001_slot001
invokevirtual java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lan\
g/StringBuilder;
ldc "I have Added a nameWe May need few more names"
invokevirtual java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lan\
g/StringBuilder;
aload_0 ; met001_slot000
invokevirtual java/lang/StringBuilder.append(Ljava/lang/Object;)Ljava/lan\
g/StringBuilder;
invokevirtual java/lang/StringBuilder.toString()Ljava/lang/String;
astore_1 ; met001_slot001
.line 15
aload_1 ; met001_slot001
aload_1 ; met001_slot001
invokevirtual java/lang/String.concat(Ljava/lang/String;)Ljava/lang/Strin\
g;
pop
.line 18
return //no more SB created
met001_end:                                    ; DATA XREF: met001_slot000i ...
; ===========================================================================
;met001_slot000                                ; DATA XREF: <init>r ...
.var 0 is this LAppc; from met001_begin to met001_end
;met001_slot001                                ; DATA XREF: <init>+6w ...
.var 1 is x Ljava/lang/String; from met001_7 to met001_end
.end method
;44-1=44
; ---------------------------------------------------------------------------
; Segment type: Pure code
.method public Sb()V //public void Sb
.limit stack 3
.limit locals 2
met002_begin:                                  ; DATA XREF: met002_slot000i
.line 21
new java/lang/StringBuilder
dup
ldc "no name"
invokespecial java/lang/StringBuilder.<init>(Ljava/lang/String;)V
astore_1 ; met002_slot001
.line 22
met002_10:                                     ; DATA XREF: met002_slot001i
aload_1 ; met002_slot001
ldc "I have Added a name"
invokevirtual java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lan\
g/StringBuilder;
pop
.line 23
aload_1 ; met002_slot001
ldc "We May need few more names"
invokevirtual java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lan\
g/StringBuilder;
pop
.line 24
aload_1 ; met002_slot001
aload_0 ; met002_slot000
invokevirtual java/lang/StringBuilder.append(Ljava/lang/Object;)Ljava/lan\
g/StringBuilder;
pop
.line 25
aload_1 ; met002_slot001
aload_1 ; met002_slot001
invokevirtual java/lang/StringBuilder.toString()Ljava/lang/String;
invokevirtual java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lan\
g/StringBuilder;
pop
.line 28
return
met002_end:                                    ; DATA XREF: met002_slot000i ...
;met002_slot000                                ; DATA XREF: Sb+25r
.var 0 is this LAppc; from met002_begin to met002_end
;met002_slot001                                ; DATA XREF: Sb+9w ...
.var 1 is sbb Ljava/lang/StringBuilder; from met002_10 to met002_end
.end method
;96-49=48
; ---------------------------------------------------------------------------

De ces deux codes, vous pouvez voir Michael est à droite.Dans chaque cas, une seule SB objet est créé.

InformationsquelleAutor perilbrain

26

Depuis Java 1.5, simple ligne d'enchainement avec "+" et StringBuilder.append() de générer exactement le même bytecode.

Donc pour le souci de la lisibilité du code, utilisez "+".

2 exceptions :
- environnement multithread : StringBuffer
- concaténation en boucle : StringBuilder/StringBuffer
InformationsquelleAutor Zofren

L'aide de la dernière version de Java(1.8) le démontage(javap -c) montre l'optimisation introduit par le compilateur. + ainsi sb.append() va avoir le même code. Cependant, il vaut la peine d'inspecter le comportement si nous sommes à l'aide de + dans une boucle for.

Ajouter les chaînes de caractères à l'aide de + dans une boucle for

Java:

public String myCatPlus(String[] vals) {
String result = "";
for (String val : vals) {
result = result + val;
}
return result;
}

ByteCode:(for boucle extrait)

12: iload         5
14: iload         4
16: if_icmpge     51
19: aload_3
20: iload         5
22: aaload
23: astore        6
25: new           #3                  //class java/lang/StringBuilder
28: dup
29: invokespecial #4                  //Method java/lang/StringBuilder."<init>":()V
32: aload_2
33: invokevirtual #5                  //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
36: aload         6
38: invokevirtual #5                  //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
41: invokevirtual #6                  //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
44: astore_2
45: iinc          5, 1
48: goto          12

Ajouter les chaînes de caractères à l'aide de stringbuilder.ajouter

Java:

public String myCatSb(String[] vals) {
StringBuilder sb = new StringBuilder();
for(String val : vals) {
sb.append(val);
}
return sb.toString();
}

ByteCdoe:(for boucle extrait)

17: iload         5
19: iload         4
21: if_icmpge     43
24: aload_3
25: iload         5
27: aaload
28: astore        6
30: aload_2
31: aload         6
33: invokevirtual #5                  //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
36: pop
37: iinc          5, 1
40: goto          17
43: aload_2

Il y a un peu de flagrante différence bien. Dans le premier cas, où + a été utilisé, de nouvelles StringBuilder est créé pour chaque pour chaque itération de boucle et de résultat généré est stocké en faisant un toString() appel(29 à 41). Donc, vous êtes la génération intermédiaire des Chaînes qui vos n'avez pas vraiment besoin tout en utilisant + opérateur dans for boucle.

Est-ce Oracle JDK ou OpenJDK ?

InformationsquelleAutor ring bearer

10

En Java 9 de la version 1 devrait être plus rapide, car il est converti invokedynamic appel. Plus de détails peuvent être trouvés dans JEP-280:

L'idée est de remplacer l'ensemble de la classe StringBuilder ajouter de la danse avec un simple invokedynamic appel à java.lang.invoquer.StringConcatFactory, qui permettra d'accepter les valeurs de la nécessité de concaténation.

InformationsquelleAutor ZhekaKozlov

Pour des raisons de performance, l'utilisation de += (String concaténation) est déconseillé. La raison en est: Java String est immuable, chaque fois qu'un nouveau concaténation est fait un nouveau String est créé (le nouveau est différent de l'empreinte digitale de l'ancienne déjà dans la Chaîne de la piscine ). La création de nouvelles chaînes met la pression sur la GC et ralentit le programme: création d'un objet est cher.

Code ci-dessous devrait la rendre plus pratique et clair en même temps.

public static void main(String[] args) 
{
//warming up
for(int i = 0; i < 100; i++)
RandomStringUtils.randomAlphanumeric(1024);
final StringBuilder appender = new StringBuilder();
for(int i = 0; i < 100; i++)
appender.append(RandomStringUtils.randomAlphanumeric(i));
//testing
for(int i = 1; i <= 10000; i*=10)
test(i);
}
public static void test(final int howMany) 
{
List<String> samples = new ArrayList<>(howMany);
for(int i = 0; i < howMany; i++)
samples.add(RandomStringUtils.randomAlphabetic(128));
final StringBuilder builder = new StringBuilder();
long start = System.nanoTime();
for(String sample: samples)
builder.append(sample);
builder.toString();
long elapsed = System.nanoTime() - start;
System.out.printf("builder - %d - elapsed: %dus\n", howMany, elapsed / 1000);
String accumulator = "";
start = System.nanoTime();
for(String sample: samples)
accumulator += sample;
elapsed = System.nanoTime() - start;
System.out.printf("concatenation - %d - elapsed: %dus\n", howMany, elapsed / (int) 1e3);
start = System.nanoTime();
String newOne = null;
for(String sample: samples)
newOne = new String(sample);
elapsed = System.nanoTime() - start;
System.out.printf("creation - %d - elapsed: %dus\n\n", howMany, elapsed / 1000);
}

Résultats pour une course sont rapportés ci-dessous.

builder - 1 - elapsed: 132us
concatenation - 1 - elapsed: 4us
creation - 1 - elapsed: 5us
builder - 10 - elapsed: 9us
concatenation - 10 - elapsed: 26us
creation - 10 - elapsed: 5us
builder - 100 - elapsed: 77us
concatenation - 100 - elapsed: 1669us
creation - 100 - elapsed: 43us
builder - 1000 - elapsed: 511us
concatenation - 1000 - elapsed: 111504us
creation - 1000 - elapsed: 282us
builder - 10000 - elapsed: 3364us 
concatenation - 10000 - elapsed: 5709793us
creation - 10000 - elapsed: 972us

Ne pas considérer les résultats de 1 concaténation (JIT n'était pas encore fait son travail), même pour 10 concaténations de la dégradation des performances est pertinente; pour des milliers de concaténations, la différence est énorme.

Enseignements tirés de cette expérience rapide (facilement reproductible avec le code ci-dessus): ne jamais utiliser le += pour concaténer des chaînes, même très basique cas où quelques enchaînements sont nécessaires (comme l'a dit, la création de nouvelles chaînes est cher de toute façon et met la pression sur le GC).

InformationsquelleAutor Paolo Maresca

7

Apache Commons-Lang a une ToStringBuilder classe qui est super facile à utiliser. Il fait un excellent travail à la fois de la manipulation de l'ajout de la logique ainsi que la mise en forme de la façon dont vous voulez que votre toString pour look.
```
public void toString() {
ToStringBuilder tsb =  new ToStringBuilder(this);
tsb.append("a", a);
tsb.append("b", b)
return tsb.toString();
}
```
Sera de retour de sortie qui ressemble à com.blah.YourClass@abc1321f[a=whatever, b=foo].

Ou sous une forme plus condensée en utilisant le chaînage:
```
public void toString() {
return new ToStringBuilder(this).append("a", a).append("b", b").toString();
}
```
Ou si vous souhaitez utiliser la réflexion pour inclure tous les champs de la classe:
```
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
```
Vous pouvez également personnaliser le style de la ToString si vous le souhaitez.

InformationsquelleAutor matt b
6

Voir l'exemple ci-dessous:
```
static final int MAX_ITERATIONS = 50000;
static final int CALC_AVG_EVERY = 10000;
public static void main(String[] args) {
printBytecodeVersion();
printJavaVersion();
case1();//str.concat
case2();//+=
case3();//StringBuilder
}
static void case1() {
System.out.println("[str1.concat(str2)]");
List<Long> savedTimes = new ArrayList();
long startTimeAll = System.currentTimeMillis();
String str = "";
for (int i = 0; i < MAX_ITERATIONS; i++) {
long startTime = System.currentTimeMillis();
str = str.concat(UUID.randomUUID() + "---");
saveTime(savedTimes, startTime);
}
System.out.println("Created string of length:" + str.length() + " in " + (System.currentTimeMillis() - startTimeAll) + " ms");
}
static void case2() {
System.out.println("[str1+=str2]");
List<Long> savedTimes = new ArrayList();
long startTimeAll = System.currentTimeMillis();
String str = "";
for (int i = 0; i < MAX_ITERATIONS; i++) {
long startTime = System.currentTimeMillis();
str += UUID.randomUUID() + "---";
saveTime(savedTimes, startTime);
}
System.out.println("Created string of length:" + str.length() + " in " + (System.currentTimeMillis() - startTimeAll) + " ms");
}
static void case3() {
System.out.println("[str1.append(str2)]");
List<Long> savedTimes = new ArrayList();
long startTimeAll = System.currentTimeMillis();
StringBuilder str = new StringBuilder("");
for (int i = 0; i < MAX_ITERATIONS; i++) {
long startTime = System.currentTimeMillis();
str.append(UUID.randomUUID() + "---");
saveTime(savedTimes, startTime);
}
System.out.println("Created string of length:" + str.length() + " in " + (System.currentTimeMillis() - startTimeAll) + " ms");
}
static void saveTime(List<Long> executionTimes, long startTime) {
executionTimes.add(System.currentTimeMillis() - startTime);
if (executionTimes.size() % CALC_AVG_EVERY == 0) {
out.println("average time for " + executionTimes.size() + " concatenations: "
+ NumberFormat.getInstance().format(executionTimes.stream().mapToLong(Long::longValue).average().orElseGet(() -> 0))
+ " ms avg");
executionTimes.clear();
}
}
```
De sortie:

bytecode java version:8

java.version: 1.8.0_144

[str1.concat(ch2)]

durée moyenne de 10000 concaténations: 0.096 mme avg

durée moyenne de 10000 concaténations: 0.185 mme avg

durée moyenne de 10000 concaténations: 0.327 mme avg

durée moyenne de 10000 concaténations: 0.501 mme avg

durée moyenne de 10000 concaténations: de 0,656 mme avg

Créé chaîne de caractères de longueur:1950000 dans 17745 ms

[str1+=ch2]

durée moyenne de 10000 concaténations: 0.21 mme avg

durée moyenne de 10000 concaténations: 0.652 mme avg

durée moyenne de 10000 concaténations: 1.129 mme avg

durée moyenne de 10000 concaténations: 1.727 mme avg

durée moyenne de 10000 concaténations: 2.302 mme avg

Créé chaîne de caractères de longueur:1950000 dans 60279 ms

[str1.append(ch2)]

durée moyenne de 10000 concaténations: 0.002 ms avg

durée moyenne de 10000 concaténations: 0.002 ms avg

durée moyenne de 10000 concaténations: 0.002 ms avg

durée moyenne de 10000 concaténations: 0.002 ms avg

durée moyenne de 10000 concaténations: 0.002 ms avg

Créé chaîne de caractères de longueur:1950000 dans 100 ms

Que la longueur de la chaîne augmente, la concaténation de temps.

C'est là que le StringBuilder est certainement nécessaire.

Comme vous le voyez, la concaténation: UUID.randomUUID()+"---", n'affecte pas vraiment le temps.

P. S.: je ne pense pas que Quand utiliser StringBuilder en Java est vraiment un duplicata de celui-ci.

Cette question parle toString() qui la plupart du temps ne permet pas de réaliser des enchaînements d'énormes chaînes.

2019 mise à Jour

Depuis java8 fois, les choses ont un peu changé. Il semble que maintenant(java13), la concaténation temps de += est pratiquement le même que str.concat(). Cependant StringBuilder concaténation temps est toujours constant. (Original post ci-dessus a été légèrement modifié pour ajouter plus de commentaires de sortie)

bytecode java version:13

java.version: 13.0.1

[str1.concat(ch2)]

durée moyenne de 10000 concaténations: 0.047 mme avg

durée moyenne de 10000 concaténations: 0,1 ms avg

durée moyenne de 10000 concaténations: 0.17 mme avg

durée moyenne de 10000 concaténations: 0.255 mme avg

durée moyenne de 10000 concaténations: 0.336 mme avg

Créé chaîne de caractères de longueur:1950000 dans 9147 ms

[str1+=ch2]

durée moyenne de 10000 concaténations: 0.037 mme avg

durée moyenne de 10000 concaténations: 0.097 mme avg

durée moyenne de 10000 concaténations: 0.249 mme avg

durée moyenne de 10000 concaténations: 0.298 mme avg

durée moyenne de 10000 concaténations: 0.326 mme avg

Créé chaîne de caractères de longueur:1950000 dans 10191 ms

[str1.append(ch2)]

durée moyenne de 10000 concaténations: 0.001 ms avg

durée moyenne de 10000 concaténations: 0.001 ms avg

durée moyenne de 10000 concaténations: 0.001 ms avg

durée moyenne de 10000 concaténations: 0.001 ms avg

durée moyenne de 10000 concaténations: 0.001 ms avg

Créé chaîne de caractères de longueur:1950000 dans 43 ms

Intéressant de noter également bytecode:8/java.version:13 combinaison a une bonne performance d'avantages par rapport à bytecode:8/java.version:8
- Cela devrait être accepté réponse .. ça dépend de la taille de la Chaîne de Stream qui détermine le choix de la méthode concat ou StringBuilder
- Pour info: réponse mis à jour avec les résultats de la java13 qui sont différentes. Mais je pense que la principale conclusion reste la même.
InformationsquelleAutor Marinos An
4

Faire la méthode toString aussi lisible que possible!

La seule exception à cela dans mon livre, si vous pouvez prouver à moi qu'il consomme une quantité importante de ressources 🙂 (Oui, cela signifie que le profilage)

Également noter que le Java 5 compilateur génère plus rapide que le code manuscrite "StringBuffer" approche utilisée dans les versions antérieures de Java. Si vous utilisez "+" et les futures améliorations de est gratuit.

InformationsquelleAutor Thorbjørn Ravn Andersen
3

Il semble y avoir un débat à savoir si l'utilisation StringBuilder est toujours nécessaire avec les compilateurs gcc. J'ai donc pensé que je vais vous donner mon 2 cents de l'expérience.

J'ai un JDBC ensemble de résultats de 10k enregistrements (oui, j'ai besoin de tous en un seul lot.) À l'aide de l'opérateur + prend environ 5 minutes sur ma machine avec Java 1.8. À l'aide de stringBuilder.append("") prend moins d'une seconde pour la même requête.

Donc, la différence est énorme. L'intérieur d'une boucle StringBuilder est beaucoup plus rapide.
- Je pense que le débat est sur l'aide à l'extérieur de la boucle. Je pense qu'il y a un consensus, vous avez besoin de l'utiliser à l'intérieur d'une boucle.
InformationsquelleAutor Eddy
2

Performance sage la concaténation de Chaîne à l'aide de '+' est plus cher parce qu'il a à faire à une toute nouvelle copie de la Chaîne depuis les Chaînes sont immuables en java. Ceci joue un rôle particulier si l'enchaînement est très fréquent, par exemple: à l'intérieur d'une boucle.
Voici ce que mon IDÉE suggère quand je tente de faire une telle chose:

Règles Générales:
- L'intérieur d'une chaîne d'affectation, à l'aide de la concaténation de Chaîne est fine.
- Si vous êtes à la boucle de construire un grand bloc de données de caractère, optez pour StringBuffer.
- À l'aide de += sur une Chaîne de caractères est toujours moins efficace que l'utilisation d'un StringBuffer, de sorte qu'il devrait sonner des cloches d'avertissements - mais, dans certains cas, l'optimisation acquise sera négligeable par rapport à la lisibilité des questions, afin d'utiliser votre bon sens.
Ici est un nice Jon Skeet blog autour de ce sujet.
- Vous ne devez jamais utiliser StringBuffer, sauf si vous avez absolument besoin d'un accès synchronisé à partir de plusieurs threads. Sinon préférez StringBuilder qui n'est pas synchronisé et a donc moins de frais généraux.
InformationsquelleAutor Sudip Bhandari
1

Puis-je préciser que si vous allez effectuer une itération sur une collection et utiliser StringBuilder, vous voudrez peut-être vérifier Apache Commons Lang et StringUtils.join() (en différentes saveurs) ?

Indépendamment de la performance, il va vous éviter d'avoir à créer StringBuilders et pour les boucles pour ce qui semble être la millionième temps.

InformationsquelleAutor Brian Agnew

Voici ce que j'ai vérifié dans Java8

Utilisant la concaténation de Chaîne

Utiliser StringBuilder

long time1 = System.currentTimeMillis();
usingStringConcatenation(100000);
System.out.println("usingStringConcatenation " + (System.currentTimeMillis() - time1) + " ms");
time1 = System.currentTimeMillis();
usingStringBuilder(100000);
System.out.println("usingStringBuilder " + (System.currentTimeMillis() - time1) + " ms");
private static void usingStringBuilder(int n)
{
StringBuilder str = new StringBuilder();
for(int i=0;i<n;i++)
str.append("myBigString");    
}
private static void usingStringConcatenation(int n)
{
String str = "";
for(int i=0;i<n;i++)
str+="myBigString";
}

C'est vraiment un cauchemar si vous êtes en utilisant la concaténation de chaîne pour un grand nombre de chaînes.

usingStringConcatenation 29321 ms
usingStringBuilder 2 ms

InformationsquelleAutor nagendra547

-1

Je pense que nous devrions aller avec StringBuilder ajouter approche.
Raison d'être :
1. La Chaîne de concaténer va créer un nouvel objet string à chaque fois (Que String est immuable de l'objet) , de sorte qu'il permettra de créer de 3 objets.
2. Avec le générateur de Chaîne à un seul objet sera créé[StringBuilder est mutable] et la poursuite de la chaîne est ajouté à la fin.
- Pourquoi cette réponse est downvoted ? docs.oracle.com/javase/8/docs/api/java/util/stream/... - Réduction Mutable
InformationsquelleAutor VishalTambe
-4

Pour de simples chaînes de caractères comme que je préfère utiliser
```
"string".concat("string").concat("string");
```
Dans l'ordre, je dirais que la méthode préférée de la construction d'une chaîne à l'aide de StringBuilder, String#concat(), puis la surcharge opérateur+. StringBuilder est une augmentation significative des performances lorsque vous travaillez grandes chaînes tout comme l'utilisation de l'opérateur + est une diminution importante des performances (de façon exponentielle diminution importante que la taille de la Chaîne augmente). Le seul problème avec l'aide de .concat() est qu'il peut jeter NullPointerExceptions.
- À l'aide de concat() est susceptible de faire pire que '+' depuis le JLS permet '+' être converti en un StringBuilder, et probablement toutes les JVM de faire ou d'utiliser une alternative plus efficace - même n'est pas susceptible d'être vrai de concat qui doit créer et de jeter au moins un complet intermédiaires de la chaîne dans votre exemple.
InformationsquelleAutor Droo

Vous devez vous connecter pour publier un commentaire.