StringBuilder為何比String節(jié)省效率

通常說StringBuilder比String節(jié)省效率一般是指在對字符串進行一定的操作，比如拼接、反轉等，那么究竟為什么節(jié)省效率呢，本篇將從字符串拼接的原理來講述

字符串拼接的兩種實現(xiàn)

在Java中用加號對字符串進行拼接操作通常有兩種情況

1.沒有變量的字符串拼接

String s1 = "abc" + "123" + "xyz";

這種不涉及變量的字符串拼接是相當簡單的，在編譯階段，會觸發(fā)字符串的優(yōu)化機制，對于只是簡單字符串常量之間的拼接，編譯過后的結果就是他的最終值，也就是說，上面的s1在編譯時的值就已經(jīng)是"abc123xyz"了“

String s1 = "abc123xyz";

2.帶有變量的字符串拼接

String s1 = "abc";
String s2 = s1 + "123";

這種帶有變量的字符串拼接操作的實現(xiàn)就相對來說比較復雜一些，他的實現(xiàn)原理在JDK8前后也不同 

JDK8之前是創(chuàng)建一個StringBuilder進行操作

當給s1直接賦值”abc“時，在內存的字符串常量池中會生成一個”abc“，并且s1變量引用在串池中的地址，當為s2賦值時，由于拼接操作涉及到另一個變量，堆內存中會自動生成一個StringBuilder空對象，然后再將s1的內容與”123“全部拼接到這個StringBuilder的對象中，串池中也會留下”123“，然后再調用這個StringBuilder對象的toString方法將其轉換為字符串并賦值給s2

大致的過程等價于：

String s2 = new StringBuilder().append(s1).append("123").toString();

那么他的實現(xiàn)都使用了StringBuilder，為什么還說這種拼接方式效率不高呢？

假如說我們設計了多次的字符串拼接操作：

String s1 = "abc";
String s2 = s1 + "123";
String s3 = s2 + "xyz";
String s4 = s3 + "111";
...

每次涉及到變量的拼接操作都會在堆內存中生成一個StringBuilder對象和一個String對象來接收拼接后的字符串，如果連續(xù)使用這種拼接方式拼接10次，那么在內存中就需要開辟20個新的對象，顯然這種方式并不是我們想要的

在JDK8之后會使用預估字符串長度的方式來完成拼接

String s1 = "a";
String s2 = "b";
String s3 = "c";
String result = s1 + s2 + s3;

在進行字符串拼接之前，會先預估字符串拼接后的長度，并為其開辟一個等長的數(shù)組，再依次把數(shù)據(jù)放入數(shù)組中，最后再完成拼接操作，把數(shù)組轉換為一個字符串：

雖然說相比起JDK8之前，這種方法確實提高了拼接效率，但是同樣的問題也出現(xiàn)了：

String s1 = "abc";
String s2 = s1 + "123";
String s3 = s2 + "xyz";
String s4 = s3 + "111";

當設計到多次拼接時，就要進行多次預估長度，并且產生多個數(shù)組，同樣極其浪費空間

使用StringBuilder

使用 StringBuilder 拼接字符串比直接使用 String 更高效，主要是因為：

1. 可變性：而 StringBuilder 是可變的，它在內部維護一個字符數(shù)組，可以在原有的基礎上進行修改。
2. 性能開銷：使用 String 拼接時，每次都要復制原有字符串和新添加的部分，這在多次拼接時會顯著增加時間復雜度。StringBuilder 通過直接在內部數(shù)組中修改數(shù)據(jù)，避免了這些額外的復制操作。

也就是說，無論進行多少次拼接，他的操作永遠在一個StringBuilder容器內進行直接操作，不會額外開辟其他的空間

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論