Java中的String,StringBuilder熔任,StringBuffer三者的區(qū)別

最近在學習Java的時候唁情,遇到了這樣一個問題,就是String,StringBuilder以及StringBuffer這三個類之間有什么區(qū)別呢惦费,自己從網(wǎng)上搜索了一些資料抢韭,有所了解了之后在這里整理一下,便于大家觀看刻恭,也便于加深自己學習過程中對這些知識點的記憶,如果哪里有誤鞍匾,懇請指正骑科。

這三個類之間的區(qū)別主要是在兩個方面,即運行速度和線程安全這兩方面咆爽。

首先說運行速度,或者說是執(zhí)行速度掰茶,在這方面運行速度快慢為:StringBuilder > StringBuffer > String

String最慢的原因:

String為字符串常量蜜笤,而StringBuilder和StringBuffer均為字符串變量,即String對象一旦創(chuàng)建之后該對象是不可更改的,但后兩者的對象是變量瓮顽,是可以更改的围橡。以下面一段代碼為例:

1 String str="abc";
2 System.out.println(str);
3 str=str+"de";
4 System.out.println(str);

如果運行這段代碼會發(fā)現(xiàn)先輸出“abc”,然后又輸出“abcde”拣播,好像是str這個對象被更改了,其實贮配,這只是一種假象罷了塞赂,JVM對于這幾行代碼是這樣處理的,首先創(chuàng)建一個String對象str圆存,并把“abc”賦值給str,然后在第三行中沦辙,其實JVM又創(chuàng)建了一個新的對象也名為str税产,然后再把原來的str的值和“de”加起來再賦值給新的str,而原來的str就會被JVM的垃圾回收機制(GC)給回收掉了,所以阐斜,str實際上并沒有被更改,也就是前面說的String對象一旦創(chuàng)建之后就不可更改了谒出。所以,Java中對String對象進行的操作實際上是一個不斷創(chuàng)建新的對象并且將舊的對象回收的一個過程为居,所以執(zhí)行速度很慢杀狡。

而StringBuilder和StringBuffer的對象是變量,對變量進行操作就是直接對該對象進行更改,而不進行創(chuàng)建和回收的操作碑隆,所以速度要比String快很多蹬音。

另外,有時候我們會這樣對字符串進行賦值

1 String str="abc"+"de";
2 StringBuilder stringBuilder=new StringBuilder().append("abc").append("de");
3 System.out.println(str);
4 System.out.println(stringBuilder.toString());

這樣輸出結果也是“abcde”和“abcde”劫狠,但是String的速度卻比StringBuilder的反應速度要快很多,這是因為第1行中的操作和

String str="abcde";

是完全一樣的永部,所以會很快,而如果寫成下面這種形式

1 String str1="abc";
2 String str2="de";
3 String str=str1+str2;

那么JVM就會像上面說的那樣阐肤,不斷的創(chuàng)建讲坎、回收對象來進行這個操作了。速度就會很慢晨炕。

2. 再來說線程安全

在線程安全上,StringBuilder是線程不安全的削罩,而StringBuffer是線程安全的

如果一個StringBuffer對象在字符串緩沖區(qū)被多個線程使用時费奸,StringBuffer中很多方法可以帶有synchronized關鍵字,所以可以保證線程是安全的愿阐,但StringBuilder的方法則沒有該關鍵字,所以不能保證線程安全以蕴,有可能會出現(xiàn)一些錯誤的操作辛孵。所以如果要進行的操作是多線程的,那么就要使用StringBuffer魄缚,但是在單線程的情況下,還是建議使用速度比較快的StringBuilder伴鳖。

3. 總結一下
  String:適用于少量的字符串操作的情況

StringBuilder:適用于單線程下在字符緩沖區(qū)進行大量操作的情況

StringBuffer:適用多線程下在字符緩沖區(qū)進行大量操作的情況

?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市榜聂,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌匿乃,老刑警劉巖豌汇,帶你破解...
    沈念sama閱讀 217,734評論 6 505
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異宛徊,居然都是意外死亡,警方通過查閱死者的電腦和手機闸天,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,931評論 3 394
  • 文/潘曉璐 我一進店門斜做,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人笼吟,你說我怎么就攤上這事“云欤” “怎么了?”我有些...
    開封第一講書人閱讀 164,133評論 0 354
  • 文/不壞的土叔 我叫張陵皿桑,是天一觀的道長。 經(jīng)常有香客問我镀虐,道長,這世上最難降的妖魔是什么刮便? 我笑而不...
    開封第一講書人閱讀 58,532評論 1 293
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上坝疼,老公的妹妹穿的比我還像新娘谆沃。我一直安慰自己,他們只是感情好唁影,可當我...
    茶點故事閱讀 67,585評論 6 392
  • 文/花漫 我一把揭開白布据沈。 她就那樣靜靜地躺著,像睡著了一般锌介。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上孔祸,一...
    開封第一講書人閱讀 51,462評論 1 302
  • 那天融击,我揣著相機與錄音,去河邊找鬼尊浪。 笑死,一個胖子當著我的面吹牛拇涤,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播鹅士,決...
    沈念sama閱讀 40,262評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼掉盅,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了趾痘?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,153評論 0 276
  • 序言:老撾萬榮一對情侶失蹤卵贱,失蹤者是張志新(化名)和其女友劉穎滥沫,沒想到半個月后兰绣,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,587評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡缀辩,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,792評論 3 336
  • 正文 我和宋清朗相戀三年雌澄,在試婚紗的時候發(fā)現(xiàn)自己被綠了杯瞻。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,919評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡睬涧,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出畦浓,到底是詐尸還是另有隱情检疫,我是刑警寧澤讶请,帶...
    沈念sama閱讀 35,635評論 5 345
  • 正文 年R本政府宣布夺溢,位于F島的核電站烛谊,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏丹禀。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,237評論 3 329
  • 文/蒙蒙 一双泪、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧焙矛,春花似錦、人聲如沸薄扁。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,855評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽日缨。三九已至,卻和暖如春匣距,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背毅待。 一陣腳步聲響...
    開封第一講書人閱讀 32,983評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留吱涉,地道東北人。 一個月前我還...
    沈念sama閱讀 48,048評論 3 370
  • 正文 我出身青樓怎爵,卻偏偏與公主長得像鳖链,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子芙委,可洞房花燭夜當晚...
    茶點故事閱讀 44,864評論 2 354

推薦閱讀更多精彩內(nèi)容