Der Unterschied zwischen String und StringBuilder in Java

Ich glaube, dass jeder den Unterschied zwischen String und StringBuffer gut versteht, aber es wird geschätzt, dass es immer noch viele Kollegen gibt, denen die Arbeitsprinzipien dieser beiden Klassen nicht klar sind. Heute werde ich dieses Konzept für alle überprüfen Die Art und Weise, wie J2SE 5.0 eine neue Zeichenmanipulationsklasse mit sich bringt – StringBuilder (beeilen Sie sich nicht, mich mit Steinen zu bewerfen, ich bin immer noch nüchtern, ich spreche hier nicht von C#, Java hat auch eine StringBuilder-Klasse). Was sind also die Unterschiede zwischen diesem StringBuilder und StringBuffer und der String-Klasse, die wir zum ersten Mal kennengelernt haben? Welches sollten wir in verschiedenen Situationen verwenden? Ich möchte meine Ansichten zu diesen Kategorien mitteilen und hoffe auch, dass jeder seine Meinung äußern kann. Jeder hat Fehler gemacht und es ist eine gute Gelegenheit, etwas zu lernen.

Kurz gesagt besteht der Hauptleistungsunterschied zwischen dem String-Typ und dem StringBuffer-Typ tatsächlich darin, dass String ein unveränderliches Objekt ist (Warum? Fragen Sie die Designer von Java, warum String kein nativer Typ ist?). Daher wird der String-Typ jedes Mal geändert Tatsächlich entspricht dies dem Generieren eines neuen String-Objekts und dem anschließenden Zeigen des Zeigers auf das neue String-Objekt. Daher ist es am besten, String nicht für Zeichenfolgen zu verwenden, deren Inhalt sich häufig ändert, da dies bei jeder Generierung eines Objekts der Fall ist Dies wirkt sich auf die Systemleistung aus, insbesondere wenn zu viele nicht referenzierte Objekte vorhanden sind. Der GC der JVM beginnt zu arbeiten und die Geschwindigkeit ist definitiv recht langsam. Hier ist ein Beispiel, das nicht sehr passend ist:

Zeichenfolge S1 = „abc“;
For(int I = 0; I < 10000; I ++) // For simuliert mehrere Aufrufe des Programms
{
S1 + = "def";
S1 = „abc“;
}

Wenn dies der Fall ist, befinden sich nach Abschluss der for-Schleife und wenn die Objekte im Speicher nicht vom GC gelöscht wurden, mehr als 20.000 im Speicher, eine erstaunliche Zahl, und wenn dies ein System ist, das von vielen verwendet wird Leute, dann ist die Zahl nicht sehr groß, daher muss jeder bei der Verwendung vorsichtig sein.

Wenn Sie die StringBuffer-Klasse verwenden, sind die Ergebnisse jedes Mal unterschiedlich. Das Ergebnis ist eine Operation am StringBuffer-Objekt selbst, anstatt ein neues Objekt zu generieren und dann die Objektreferenz zu ändern. Daher empfehlen wir im Allgemeinen die Verwendung von StringBuffer, insbesondere wenn sich String-Objekte häufig ändern. In einigen Sonderfällen wird die String-Verkettung von String-Objekten von der JVM tatsächlich als die Verkettung von StringBuffer-Objekten interpretiert, sodass in diesen Fällen die Geschwindigkeit von String-Objekten nicht langsamer ist als die von StringBuffer-Objekten, insbesondere die folgenden String-Objekte Unter diesen ist die String-Effizienz viel schneller als die von StringBuffer:

String S1 = „Das ist nur ein“ + „einfach“ + „Test“;
StringBuffer Sb = new StringBuilder("This is only a").append("simple").append("test");

Sie werden überrascht sein, dass die Geschwindigkeit beim Generieren von String S1-Objekten einfach zu hoch ist und StringBuffer derzeit überhaupt keinen Geschwindigkeitsvorteil hat. Tatsächlich ist dies ein Trick der JVM. In den Augen der JVM

String S1 = „Dies ist nur ein“ + „einfacher“ + „Test“; Tatsächlich lautet es: String S1 = „Dies ist nur ein einfacher Test“; es dauert also natürlich nicht lange. Aber was hier jeder beachten sollte, ist, dass die Geschwindigkeit nicht so hoch sein wird, wenn Ihr String von einem anderen String-Objekt stammt, zum Beispiel:

String S2 = „Das ist nur ein“;
String S3 = „einfach“;
Zeichenfolge S4 = „test“;
Zeichenfolge S1 = S2 + S3 + S4;

Zu diesem Zeitpunkt verhält sich die JVM wie ursprünglich und die Generierungsgeschwindigkeit von S1-Objekten ist nicht mehr so ​​hoch wie zuvor. Wir können dies später durch einen Test überprüfen.

Daraus erhalten wir die erste Schlussfolgerung: In den meisten Fällen StringBuffer > String

Und wie schneidet StringBuilder im Vergleich dazu ab? Lassen Sie mich es zunächst kurz vorstellen. StringBuilder ist eine neu hinzugefügte Klasse in JDK5.0. Der Unterschied zwischen ihr und StringBuffer ist wie folgt (Quelle: JavaWorld):

Java.lang.StringBuffer Threadsichere veränderbare Zeichenfolge. Ein String-Puffer ähnlich wie String, der jedoch nicht geändert werden kann. String-Puffer können sicher von mehreren Threads verwendet werden. Diese Methoden können bei Bedarf synchronisiert werden, sodass alle Vorgänge auf einer bestimmten Instanz scheinbar in einer seriellen Reihenfolge ausgeführt werden, die mit der Reihenfolge der Methodenaufrufe jedes beteiligten Threads übereinstimmt.

Jeder String-Puffer hat eine bestimmte Kapazität. Solange die Länge der im Zeichenfolgenpuffer enthaltenen Zeichenfolge diese Kapazität nicht überschreitet, besteht keine Notwendigkeit, ein neues internes Pufferarray zuzuweisen. Diese Kapazität wird automatisch erhöht, wenn der interne Puffer überläuft. Ab JDK 5.0 wurde dieser Klasse eine äquivalente Klasse für die Verwendung in einem einzelnen Thread hinzugefügt, nämlich StringBuilder. Im Allgemeinen sollte die StringBuilder-Klasse dieser Klasse vorgezogen werden, da sie dieselben Vorgänge unterstützt, aber schneller ist, da sie keine Synchronisierung durchführt.

Es ist jedoch unsicher, eine Instanz von StringBuilder mit mehreren Threads zu verwenden. Wenn eine solche Synchronisierung erforderlich ist, wird die Verwendung von StringBuffer empfohlen.

Nachdem dies gesagt ist, denke ich, dass jeder den Unterschied zwischen ihnen verstehen kann, also lassen Sie uns unten eine allgemeine Ableitung vornehmen:

In den meisten Fällen StringBuilder > StringBuffer

Daher gilt nach dem Übertragungssatz dieser Ungleichung: in den meisten Fällen StringBuilder > StringBuffer > String (je größer die Anzahl der Operationen, desto stabiler).

Holen Sie sich die Systemzeit long start = System.currentTimeMillis(); long end = System.currentTimeMillis(); um den laufenden Millisekundenwert zu erfahren.