La différence entre String et StringBuilder en Java

Je pense que tout le monde comprend bien la différence entre String et StringBuffer, mais on estime qu'il y a encore de nombreux camarades qui ne comprennent pas clairement les principes de fonctionnement de ces deux classes. Aujourd'hui, je vais passer en revue ce concept pour tout le monde, et par. la façon dont J2SE 5.0 apporte une nouvelle classe de manipulation de caractères - StringBuilder (ne vous précipitez pas pour me jeter des briques, je suis toujours sobre, je ne parle pas de C# ici, Java a aussi une classe StringBuilder). Alors, quelles sont les différences entre ce StringBuilder et StringBuffer et la classe String que nous avons rencontrée pour la première fois ? Lequel devrions-nous utiliser dans différentes situations ? J'aimerais partager mon point de vue sur ces catégories, et j'espère aussi que chacun pourra donner son avis. Tout le monde a fait des erreurs, et en les corrigeant, c'est une bonne opportunité d'apprendre.

En bref, la principale différence de performances entre le type String et le type StringBuffer est en fait que String est un objet immuable (Pourquoi ? Demandez aux concepteurs de Java, pourquoi String n'est-il pas un type natif ?) Par conséquent, chaque fois que le type String est modifié , En fait, cela équivaut à générer un nouvel objet String, puis à pointer le pointeur vers le nouvel objet String. Par conséquent, il est préférable de ne pas utiliser String pour les chaînes qui changent fréquemment de contenu, car chaque fois qu'un objet est généré, il est généré. aura un impact sur les performances du système, en particulier lors de l'utilisation de la mémoire. Lorsqu'il y a trop d'objets non référencés, le GC de la JVM commencera à fonctionner et la vitesse sera certainement assez lente. Voici un exemple qui n'est pas très approprié :

Chaîne S1 = "abc" ;
For(int I = 0; I < 10000; I ++) // For simule plusieurs appels du programme
{
S1 + = "déf" ;
S1 = "abc" ;
}

Si tel est le cas, une fois la boucle for terminée, si les objets en mémoire n'ont pas été effacés par le GC, il y en aura plus de 20 000 en mémoire, un nombre étonnant, et s'il s'agit d'un système utilisé par de nombreuses personnes les gens, alors Le nombre n'est pas très grand, donc tout le monde doit être prudent lorsqu'il l'utilise.

Si vous utilisez la classe StringBuffer, les résultats seront différents à chaque fois, le résultat sera une opération sur l'objet StringBuffer lui-même, au lieu de générer un nouvel objet puis de modifier la référence de l'objet. Donc, en général, nous recommandons d'utiliser StringBuffer, en particulier lorsque les objets chaîne changent fréquemment. Dans certains cas particuliers, la concaténation de chaînes d'objets String est en fait interprétée par la JVM comme la concaténation d'objets StringBuffer, donc dans ces cas, la vitesse des objets String ne sera pas plus lente que celle des objets StringBuffer, et en particulier les objets chaîne suivants sont généré Parmi eux, l'efficacité de String est beaucoup plus rapide que StringBuffer :

Chaîne S1 = « Ceci n'est qu'un » + « simple » + « test » ;
StringBuffer Sb = new StringBuilder("Ceci n'est qu'un").append("simple").append("test");

Vous serez surpris de constater que la vitesse de génération des objets String S1 est tout simplement trop rapide et qu'à l'heure actuelle, StringBuffer n'a aucun avantage en termes de vitesse. En fait, c'est une astuce de la JVM. Aux yeux de la JVM, c'est cela.

String S1 = « Ceci n’est qu’un » + « simple » + « test » ; En fait, c’est : String S1 = « Ceci n’est qu’un simple test » Alors bien sûr, cela ne prend pas beaucoup de temps. Mais ce que tout le monde devrait noter ici, c'est que si votre chaîne provient d'un autre objet String, la vitesse ne sera pas si rapide, par exemple :

Chaîne S2 = « Ceci n'est qu'un » ;
Chaîne S3 = « simple » ;
Chaîne S4 = "test" ;
Chaîne S1 = S2 +S3 + S4 ;

À ce stade, la JVM se comportera de la manière originale et la vitesse de génération des objets S1 ne sera pas aussi rapide qu'avant. Nous pourrons faire un test pour le vérifier plus tard.

De là, nous obtenons la première conclusion : dans la plupart des cas, StringBuffer > String

Et comment StringBuilder se compare-t-il à eux ? Permettez-moi d'abord de le présenter brièvement. StringBuilder est une classe nouvellement ajoutée dans JDK5.0. La différence entre elle et StringBuffer est la suivante (source : JavaWorld) :

Java.lang.StringBuffer Séquence de caractères mutables thread-safe. Un tampon de chaîne similaire à String, mais ne peut pas être modifié. Les tampons de chaînes peuvent être utilisés en toute sécurité par plusieurs threads. Ces méthodes peuvent être synchronisées si nécessaire, de sorte que toutes les opérations sur une instance particulière semblent se produire dans un ordre sériel cohérent avec l'ordre des appels de méthode effectués par chaque thread impliqué.

Chaque tampon de chaîne a une certaine capacité. Tant que la longueur de la séquence de caractères contenue par le tampon de chaîne ne dépasse pas cette capacité, il n'est pas nécessaire d'allouer un nouveau tableau de tampon interne. Cette capacité est automatiquement augmentée en cas de débordement du buffer interne. À partir du JDK 5.0, une classe équivalente pour une utilisation avec un seul thread a été ajoutée à cette classe, à savoir StringBuilder. La classe StringBuilder doit généralement être utilisée de préférence à cette classe car elle prend en charge toutes les mêmes opérations mais est plus rapide car elle n'effectue pas de synchronisation.

Mais il n'est pas sûr d'utiliser une instance de StringBuilder avec plusieurs threads. Si une telle synchronisation est requise, il est recommandé d'utiliser StringBuffer.

Cela dit, je pense que tout le monde peut comprendre la différence entre eux, faisons donc une dérivation générale ci-dessous :

Dans la plupart des cas StringBuilder > StringBuffer

Donc, selon le théorème de transfert de cette inégalité : dans la plupart des cas StringBuilder > StringBuffer > String (plus le nombre d'opérations est grand, plus il est stable).

Obtenez l'heure système long start = System.currentTimeMillis(); long end = System.currentTimeMillis(); pour connaître la valeur en millisecondes en cours d'exécution.