不斷地學(xué)習(xí)，不斷地填充自己的技術(shù)庫，學(xué)習(xí)Java已經(jīng)有一段時間了，由一開始的不適應(yīng)到后來的足以靈活應(yīng)對，不僅僅取決于老師的精致講課，還有就是依靠我的學(xué)習(xí)秘籍：記錄自己的學(xué)習(xí)筆記。今天給大家分享的技術(shù)學(xué)習(xí)筆記是JAVAString,StringBuilder以及StringBuffer這三個類之間的區(qū)別。
從以下三個方面來總結(jié)的：
????1.首先說運行速度，或者說是執(zhí)行速度。
在這方面運行速度快慢為：StringBuilder > StringBuffer > String，其原因在于：
????1)String最慢的原因：
String為字符串常量，而StringBuilder和StringBuffer均為字符串變量，即String對象一旦創(chuàng)建之后該對象是不可更改的，但后兩者的對象是變量，是可以更改的。以下面一段代碼為例：?
????String str="abc";
System.out.println(str);
str=str+"de";
????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的垃圾回收機(jī)制（GC）給回收掉了，所以，str實際上并沒有被更改，也就是前面說的String對象一旦創(chuàng)建之后就不可更改了。所以，Java中對String對象進(jìn)行的操作實際上是一個不斷創(chuàng)建新的對象并且將舊的對象回收的一個過程，所以執(zhí)行速度很慢。
而StringBuilder和StringBuffer的對象是變量，對變量進(jìn)行操作就是直接對該對象進(jìn)行更改，而不進(jìn)行創(chuàng)建和回收的操作，所以速度要比String快很多。
另外，有時候我們會這樣對字符串進(jìn)行賦值:
String str="abc"+"de"; StringBuilder
stringBuilder=new StringBuilder().append("abc").append("de");
System.out.println(str);
System.out.println(stringBuilder.toString());
這樣輸出結(jié)果也是“abcde”和“abcde”，但是String的速度卻比StringBuilder的反應(yīng)速度要快很多，這是因為第1行中的操作和String str="abcde";是完全一樣的，所以會很快，而如果寫成下面這種形式:
????String str1="abc";
String str2="de";
String str=str1+str2;
那么JVM就會像上面說的那樣，不斷的創(chuàng)建、回收對象來進(jìn)行這個操作了。速度就會很慢。
2. 再來說線程安全
在線程安全上，StringBuilder是線程不安全的，而StringBuffer是線程安全的。如果一個StringBuffer對象在字符串緩沖區(qū)被多個線程使用時，StringBuffer中很多方法可以帶有synchronized關(guān)鍵字，所以可以保證線程是安全的，但StringBuilder的方法則沒有該關(guān)鍵字，所以不能保證線程安全，有可能會出現(xiàn)一些錯誤的操作。所以如果要進(jìn)行的操作是多線程的，那么就要使用StringBuffer，但是在單線程的情況下，還是建議使用速度比較快的StringBuilder。
3. 簡單總結(jié)
String：適用于少量的字符串操作的情況。
StringBuilder：適用于單線程下在字符緩沖區(qū)進(jìn)行大量操作的情況。
StringBuffer：適用多線程下在字符緩沖區(qū)進(jìn)行大量操作的情況。
????知識框架需要用清晰的思路抽絲剝繭，細(xì)致的理順才能起到事半功倍的效果，推薦大家可以用一下我的學(xué)習(xí)方法，很多一開始不消化的知識點，在你總結(jié)之后都會迎刃而解！
---------------------
作者：肖曉曉
來源：CSDN
原文：https://blog.csdn.net/xx666zz/article/details/84563634
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！
