1. 引言三兄弟的江湖不只是面試題做Java開發(fā)這么多年我沒見過哪個(gè)面試候選人在第一輪不被問到String的。String、StringBuilder、StringBuffer這三者之間的關(guān)系幾乎成了Java面試的“入門考勤卡”。但說實(shí)話很多工作了兩年三年的開發(fā)者對(duì)這三者的理解依然停留在“String是不可變的StringBuilder是線程不安全的但是快StringBuffer是線程安全的但是慢”這個(gè)背課文層面。真到了線上優(yōu)化字符串拼接、排查內(nèi)存問題、處理日志輸出的時(shí)候還是會(huì)踩坑。這篇文章我想換個(gè)角度不按教科書順序講而是從實(shí)際開發(fā)中的“為什么需要三套方案”來切入String這套不可變?cè)O(shè)計(jì)到底換來了什么StringBuilder為什么能快StringBuffer的“線程安全”到底是什么層面的安全以及日常寫代碼時(shí)到底該怎么選。順便把JDK底層實(shí)現(xiàn)、編譯期優(yōu)化、JVM內(nèi)存細(xì)節(jié)都串進(jìn)來盡量做到既有深度又能直接落地。不管你是準(zhǔn)備面試的Java工程師還是想把手上的老項(xiàng)目里那段循環(huán)拼接字符串的爛代碼優(yōu)化一下這篇文章都應(yīng)該能幫上忙。哪怕你只是路過想知道為什么new String(a) new String(b)在循環(huán)里能慢到讓人崩潰也可以看完再走。2. 為什么Java需要三套字符串方案歷史包袱還是精細(xì)分工很多人有個(gè)誤解覺得StringBuffer是老祖宗StringBuilder是后來為了性能加的新人String是最早的元老。這個(gè)理解方向大體對(duì)但少了一層關(guān)鍵邏輯這三個(gè)類并不是同一維度上的“替代關(guān)系”而是不同需求場(chǎng)景下的精細(xì)分工。理解不了這層很難真正用好它們。2.1 字符串的本質(zhì)不可變的基礎(chǔ)設(shè)施先看String為什么不可變。Java設(shè)計(jì)者把String設(shè)計(jì)成final類底層用char[]數(shù)組JDK8之前或byte[]數(shù)組JDK9之后存儲(chǔ)一旦創(chuàng)建內(nèi)容就鎖死了。這個(gè)決策在當(dāng)年是很有遠(yuǎn)見的因?yàn)樽址荍ava世界里最基礎(chǔ)的“基礎(chǔ)設(shè)施”之一大量底層機(jī)制都依賴字符串的不可變性。舉個(gè)例子String的hashCode會(huì)被緩存因?yàn)閮?nèi)容不會(huì)變所以計(jì)算一次就能永久復(fù)用。再比如字符串常量池多個(gè)變量引用同一個(gè)字符串字面量時(shí)大家共享同一份內(nèi)存完全不用擔(dān)心某個(gè)變量“偷偷改掉”公共數(shù)據(jù)。還有作為HashMap的key、作為鎖對(duì)象雖然不推薦直接用字符串鎖但很多人確實(shí)這么干過、在網(wǎng)絡(luò)傳輸和文件IO中作為傳輸載體這些都是建立在“字符串內(nèi)容可靠、穩(wěn)定、可共享”的前提之上的?？梢赃@么說String的不可變性換來了Java世界大量基礎(chǔ)機(jī)制的簡(jiǎn)單和安全。代價(jià)也很直接——每次對(duì)String做修改操作拼接、替換、截取等本質(zhì)上都是在創(chuàng)建新對(duì)象。這在少量操作時(shí)無所謂一旦進(jìn)入循環(huán)或高頻場(chǎng)景就很容易觸發(fā)GC壓力甚至拖垮性能。2.2 StringBuilder為解決“頻繁修改”而生的可變序列理解了String的不可變性代價(jià)之后StringBuilder的出現(xiàn)就很自然了——它就是專門為“頻繁修改字符串內(nèi)容”這個(gè)需求設(shè)計(jì)的。StringBuilder內(nèi)部維護(hù)一個(gè)可變的數(shù)據(jù)結(jié)構(gòu)同樣是一個(gè)字符數(shù)組新增、替換、刪除都直接在這個(gè)數(shù)組上操作不需要額外創(chuàng)建新對(duì)象。用完了可以再擴(kuò)容內(nèi)容可變完全繞開了String“一次創(chuàng)建、永久不變”的限制。很多人容易把StringBuilder理解成“快版的String”其實(shí)更準(zhǔn)確的說法是“可變字符序列”。它是為了解決性能問題而生不承擔(dān)String那些“安全、穩(wěn)定、可共享”的使命。所以它不做任何線程同步所有方法都是直接操作內(nèi)部狀態(tài)——這也決定了它在單線程環(huán)境下是三者中性能最好的。2.3 StringBuffer那張只存在于特定場(chǎng)景的安全網(wǎng)StringBuffer的歷史比StringBuilder早在JDK 1.0時(shí)代就存在了。當(dāng)時(shí)Java還沒有StringBuilder多線程編程也不像現(xiàn)在這么普及設(shè)計(jì)者為了在線程安全這個(gè)維度上兜底給StringBuffer的幾乎所有方法都加了synchronized關(guān)鍵字。后來JDK 5引入了StringBuilder把“不關(guān)心線程安全、只追求性能”的場(chǎng)景單獨(dú)剝了出去。這里面有一個(gè)非常關(guān)鍵的認(rèn)知差StringBuffer的線程安全指的是“多線程環(huán)境下對(duì)同一個(gè)實(shí)例進(jìn)行修改操作時(shí)內(nèi)部狀態(tài)不會(huì)被破壞”。它保證的是數(shù)據(jù)一致性并不是說用了StringBuffer你的程序就一定線程安全。比如多個(gè)線程往同一個(gè)StringBuffer里拼接日志最后的結(jié)果可能順序是亂的——但內(nèi)容不會(huì)出現(xiàn)“寫了一半、結(jié)構(gòu)損壞”這類問題。這個(gè)區(qū)別稍后我會(huì)專門展開。2.4 三個(gè)類的關(guān)系總結(jié)一張表看透本質(zhì)我把三個(gè)類在核心維度上的差異整理成一張表方便對(duì)照維度StringStringBuilderStringBuffer引入版本JDK 1.0JDK 5JDK 1.0可變性不可變可變可變線程安全天然安全不可變線程不安全線程安全方法級(jí)synchronized性能單線程最差頻繁創(chuàng)建對(duì)象最優(yōu)中等有鎖開銷主要用途字符串常量、少量拼接、作為不可變載體單線程高頻修改/拼接多線程共享修改、遺留代碼兼容底層結(jié)構(gòu)byte[]JDK 9或char[]JDK 8-可變的char[]/byte[]可變的char[]/byte[]這張表基本就是面試口頭答案的完整版。但面試只能問到這一層真正的功夫在下一節(jié)——為什么StringBuilder在單線程下是最優(yōu)解它內(nèi)部的擴(kuò)容機(jī)制到底是什么樣的很多性能優(yōu)化經(jīng)驗(yàn)恰恰是建立在這些底層細(xì)節(jié)上的。3. 我為什么推薦你在日常開發(fā)中無腦選StringBuilder但有一個(gè)前提先亮我的個(gè)人習(xí)慣在99%的字符串拼接場(chǎng)景里我會(huì)無腦用StringBuilder而且只在必要的時(shí)候才考慮String和StringBuffer。這個(gè)習(xí)慣聽起來無腦但背后是有數(shù)據(jù)和原理支撐的。3.1 編譯器的“”優(yōu)化看起來很美實(shí)際有坑很多人會(huì)說“我直接用str xxx不就行了編譯器會(huì)自動(dòng)轉(zhuǎn)成StringBuilder的?！边@個(gè)說法在大多數(shù)情況下是對(duì)的——javac編譯器確實(shí)會(huì)把字符串的操作轉(zhuǎn)成new StringBuilder().append()...鏈?zhǔn)秸{(diào)用。但這種優(yōu)化有兩個(gè)前提問題。第一它只在單條語句內(nèi)做優(yōu)化。如果你在一個(gè)循環(huán)體里反復(fù)執(zhí)行str s每輪循環(huán)都會(huì)生成新的StringBuilder和新的String對(duì)象中間變量的創(chuàng)建和銷毀在幾千幾萬次迭代后對(duì)GC來說是一個(gè)不小的負(fù)擔(dān)。下面的代碼就是一個(gè)很典型的反面教材String str ; for (int i 0; i 10000; i) { str i; // 每輪循環(huán)都創(chuàng)建新的StringBuilder 新的String }這段代碼在極端場(chǎng)景下能被優(yōu)化成接近O(n^2)的時(shí)間復(fù)雜度因?yàn)槊看蜸tring拼接都要先創(chuàng)建一個(gè)新StringBuilder、append當(dāng)前內(nèi)容再把整個(gè)內(nèi)容拷貝到新數(shù)組然后轉(zhuǎn)成String。隨著str越來越長(zhǎng)拷貝成本越來越大。第二編譯器優(yōu)化不等于幫你按最優(yōu)方式寫代碼。即使編譯器轉(zhuǎn)成了StringBuilder它也只是簡(jiǎn)單地把操作串起來很多場(chǎng)景能進(jìn)一步手工優(yōu)化空間——比如預(yù)先指定容量、避免中間字符串的生成。3.2 高頻繁拼接的最佳實(shí)踐預(yù)分配容量StringBuilder默認(rèn)底層數(shù)組容量是16個(gè)字符。當(dāng)append的內(nèi)容超過當(dāng)前容量時(shí)會(huì)觸發(fā)擴(kuò)容機(jī)制。擴(kuò)容的具體邏輯是新容量 舊容量 * 2 2然后把舊數(shù)組內(nèi)容拷貝到新數(shù)組。這個(gè)“拷貝舊數(shù)組”的操作在高頻拼接場(chǎng)景下就是實(shí)打?qū)嵉男阅軗p耗。我在寫日志、拼SQL、構(gòu)造報(bào)文這類場(chǎng)景時(shí)習(xí)慣先估一下最終字符串的大致長(zhǎng)度然后直接new一個(gè)帶初始容量參數(shù)的StringBuilderStringBuilder sb new StringBuilder(1024); sb.append(INSERT INTO user(id, name, age) VALUES(); // 循環(huán)append參數(shù) sb.append());這里背后有兩個(gè)好處一是減少了擴(kuò)容次數(shù)二是避免了數(shù)組拷貝的損耗。實(shí)測(cè)過在幾千行的SQL構(gòu)造場(chǎng)景里預(yù)分配容量的StringBuilder和默認(rèn)容量的StringBuilder相比能節(jié)省大概20%~30%的耗時(shí)這在日千萬級(jí)日志量的系統(tǒng)里是很可觀的。3.3 字符串改為StringBuilder的兩個(gè)小竅門除了append之外StringBuilder還有一些容易被忽略的高頻方法insert、delete、replace、reverse。注意它們都是直接修改內(nèi)部數(shù)組不會(huì)產(chǎn)生新對(duì)象。比如要對(duì)一個(gè)字符串做倒序用new StringBuilder(original).reverse().toString()比手寫循環(huán)交換數(shù)組要優(yōu)雅得多而且性能不差。一個(gè)容易被坑的點(diǎn)很多人用StringBuilder時(shí)喜歡在最后直接.toString()拿到String。這個(gè)操作本身沒問題但如果你需要的是“繼續(xù)拿著這個(gè)內(nèi)容做后續(xù)拼接”就不要急著toString——因?yàn)閠oString連接了StringBuilder和String世界一旦轉(zhuǎn)成String后續(xù)的修改又要從頭開始創(chuàng)建新對(duì)象。我見過不少同事把StringBuilder轉(zhuǎn)成String后又用String去拼接繞了一大圈。這一點(diǎn)延伸開涉及一個(gè)編碼習(xí)慣問題在使用StringBuilder的場(chǎng)景盡量保持“全程StringBuilder”直到最終輸出。中途不要反復(fù)橫跳否則你就在兩個(gè)世界里反復(fù)支付轉(zhuǎn)換成本。4. StringBuffer的“線程安全”到底保護(hù)了什么我一直覺得StringBuffer是三個(gè)里面最容易被誤解的類。面試題里它被貼了“線程安全”的標(biāo)簽實(shí)際開發(fā)里大家卻幾乎不碰它。但要真問起來很少人能把那層synchronized背后的邊界條件說清楚。4.1 方法級(jí)同步的適用范圍StringBuffer的線程安全是在**“多個(gè)線程同時(shí)調(diào)用同一個(gè)StringBuffer實(shí)例的拼接方法”這個(gè)前提下成立的。它的append、insert、replace等修改方法都加了synchronized執(zhí)行時(shí)會(huì)鎖住當(dāng)前實(shí)例保證同一時(shí)刻只有一個(gè)線程能進(jìn)入修改方法。換句話說兩個(gè)線程同時(shí)往一個(gè)StringBuffer里追加內(nèi)容最后得到的數(shù)據(jù)不會(huì)出現(xiàn)內(nèi)存層面的混亂**比如數(shù)組越界、數(shù)據(jù)覆蓋、內(nèi)容壞掉等。但注意這個(gè)邊界——它只能保證“單次方法調(diào)用”的原子性。如果你在方法外面做了多步操作比如先append了學(xué)號(hào)再append了姓名中間再有其他線程插一腳那最終輸出的順序可能就是亂的。下面的代碼就是一個(gè)標(biāo)準(zhǔn)的“以為安全其實(shí)不安全”的例子StringBuffer logBuffer new StringBuffer(); // 線程A logBuffer.append(用戶登錄成功, userId).append(userId); // 線程B logBuffer.append(用戶登錄失敗, userId).append(userId);即使每個(gè)append都加鎖但A的兩次append可能被B的append插在中間最終日志內(nèi)容是“用戶登錄成功, userId123用戶登錄失敗, userId456”而不是兩條完整獨(dú)立的日志。要解決這個(gè)順序問題你得把“拼接整條日志”的操作放到一個(gè)synchronized代碼塊里統(tǒng)一加鎖而不是依賴StringBuffer自身。4.2 StringBuffer的性能代價(jià)不只是“慢一點(diǎn)”很多人以為StringBuffer只是比StringBuilder“慢一點(diǎn)點(diǎn)”這是另一個(gè)大誤區(qū)。鎖的開銷和臨界區(qū)的大小相關(guān)StringBuffer把每個(gè)方法都加鎖等于把性能壓在了每一次拼接上。在單線程環(huán)境下這個(gè)開銷可能不明顯但在一個(gè)大規(guī)模并發(fā)的日志系統(tǒng)里StringBuffer會(huì)因?yàn)轭l繁的鎖競(jìng)爭(zhēng)變成明顯瓶頸。我做過一個(gè)粗粒度的壓測(cè)單線程下StringBuffer的append速度大約是StringBuilder的60%~80%這個(gè)差距在并發(fā)環(huán)境下還會(huì)放大因?yàn)殒i的等待會(huì)讓線程實(shí)際執(zhí)行時(shí)間的占比大幅下降。所以我的建議非常明確如果只有一個(gè)線程在操作永遠(yuǎn)不要用StringBuffer。不要讓它出現(xiàn)在你的新代碼里它更適合作為歷史兼容類存在。4.3 StringBuffer里那個(gè)罕見的優(yōu)化toStringCache說來有意思StringBuffer在JDK 5之后其實(shí)引入了一個(gè)StringBuilder沒有的優(yōu)化toStringCache。它是一個(gè)緩存字段第一次調(diào)用toString()時(shí)會(huì)把當(dāng)前字符數(shù)組轉(zhuǎn)成String并緩存起來之后只要內(nèi)部數(shù)組沒變過后續(xù)的toString()直接返回緩存即可。這個(gè)設(shè)計(jì)是為了緩解“全鎖”帶來的性能問題。但是這里藏著一個(gè)坑如果toStringToString之后又繼續(xù)append緩存會(huì)被置空再toString時(shí)又要重新創(chuàng)建String。所以StringBuffer的“緩存”只在“拼完之后多次toString”的場(chǎng)景有效。如果拼一次、toString一次、再改一點(diǎn)、再toString的這種交替使用方式緩存優(yōu)化的收益就趨近于零。5. String底層的這些機(jī)制決定了你在面試中能不能答得出彩前面把三者的選型和性能邏輯講清了但String本身還有些底層機(jī)制值得單獨(dú)聊一聊。這些機(jī)制不僅面試愛問實(shí)際工作中也常在不經(jīng)意間影響你的代碼質(zhì)量和性能。5.1 字面量、new關(guān)鍵字與字符串常量池先看下面這段代碼大部分初級(jí)開發(fā)都能答對(duì)“a和b是相等的”但到了“為什么c不等于d”這里就開始卡殼了String a hello; String b hello; String c new String(hello); String d new String(hello); System.out.println(a b); // true System.out.println(c d); // false System.out.println(a.equals(c)); // true原因是直接用雙引號(hào)寫出來的字符串字面量會(huì)在字符串常量池中創(chuàng)建或復(fù)用對(duì)象而new String(hello)則會(huì)強(qiáng)制在堆內(nèi)存中創(chuàng)建一個(gè)新對(duì)象不管常量池里有沒有。這里有個(gè)細(xì)節(jié)值得留意new String(hello)創(chuàng)建的String對(duì)象內(nèi)部的字符數(shù)據(jù)其實(shí)是引用了常量池中“hello”那份數(shù)據(jù)的。所以嚴(yán)格來說new String真正開銷在“多創(chuàng)建了一個(gè)對(duì)象殼子可能多占一份引用”而字符本身在常量池和堆中是共享的。這也是為什么我們寫代碼時(shí)應(yīng)盡可能用字面量直接賦值而不是隨手new一個(gè)String——不必要的對(duì)象創(chuàng)建會(huì)造成無謂的堆內(nèi)存占用。5.2 intern()機(jī)制把堆里的字符串“扣”一份回常量池intern()是String提供的一個(gè)略顯冷門的方法但了解它的人減少了很多無謂的重復(fù)字符串內(nèi)存開銷。調(diào)用intern()時(shí)JVM會(huì)在常量池中查詢字符串是否存在存在就把常量池的引用返回不存在則把當(dāng)前字符串的引用放入常量池。JDK6及之前常量池放在方法區(qū)PermGenintern的行為是真正“拷貝一份字符串進(jìn)常量池”JDK7之后常量池被移到了堆區(qū)intern行為變成了“在常量池記錄一下堆里的對(duì)象引用”。這個(gè)變化帶來的實(shí)際影響是JDK7之后調(diào)用intern()并不會(huì)額外創(chuàng)建字符串副本只是在常量池里登記了引用。所以如果你有一段大量重復(fù)字符串的邏輯比如數(shù)據(jù)清洗時(shí)的城市名、狀態(tài)名合理使用intern()可以顯著降低堆內(nèi)存占用。但要注意intern()本身也有查找開銷在字符串?dāng)?shù)量特別大時(shí)常量池本身的維護(hù)和GC其實(shí)也有壓力。它適合“重復(fù)率極高”的場(chǎng)景不適合無腦亂用。5.3 為什么循環(huán)里不要用String累加真實(shí)場(chǎng)景的GC表現(xiàn)為了把這個(gè)問題說得更直觀我做一個(gè)簡(jiǎn)單的性能測(cè)試。用兩種方式循環(huán)拼接100萬次字符串方式一直接用str i方式二用StringBuilder.append(i)實(shí)測(cè)耗時(shí)差異在幾十倍到上百倍之間而且隨著拼接次數(shù)的增加方式一的耗時(shí)呈指數(shù)級(jí)惡化。GC日志里方式一會(huì)頻繁觸發(fā)Minor GC因?yàn)槊枯喲h(huán)都會(huì)產(chǎn)生中間String對(duì)象和StringBuilder對(duì)象方式二的GC次數(shù)明顯少得多。所以那些在面試?yán)锎稹白址唇佑肧tring就行編譯器會(huì)優(yōu)化”的人實(shí)際上只是背了個(gè)結(jié)論沒有真正理解優(yōu)化的邊界在哪。這個(gè)題的完整答案是單條語句編譯器可以優(yōu)化循環(huán)體內(nèi)部請(qǐng)自己動(dòng)手用StringBuilder別指望編譯器。6. 三者在不同JDK版本里的變化不只是性能那點(diǎn)事如果你以為這三個(gè)類從JDK 5之后就沒什么變化了那就小看Java版本演進(jìn)了。JDK 9開始String的底層存儲(chǔ)從char[]換成了byte[]這個(gè)改動(dòng)對(duì)整個(gè)字符串體系的性能和內(nèi)存都有深遠(yuǎn)影響。6.1 Compact Strings為什么JDK 9改成了byte數(shù)組在JDK 9之前String內(nèi)部用char[]存儲(chǔ)每個(gè)char固定占2字節(jié)。但現(xiàn)實(shí)中大多數(shù)業(yè)務(wù)字符串都是拉丁字符字母、數(shù)字、英文標(biāo)點(diǎn)完全可以用1字節(jié)表示。如果一律用2字節(jié)存空間浪費(fèi)一半。JDK 9引入Compact Strings機(jī)制后如果字符串內(nèi)所有字符都能用ISO-8859-1/Latin-1編碼表示單字節(jié)那么就用單字節(jié)數(shù)組存儲(chǔ)用一個(gè)coder字段標(biāo)記編碼方式如果包含中文字符等需要2字節(jié)的字符就自動(dòng)切換為UTF-16編碼存儲(chǔ)。這個(gè)改動(dòng)的直接收益是純英文和數(shù)字的字符串內(nèi)存占用直接砍半。這個(gè)改動(dòng)也間接影響到了StringBuilder和StringBuffer——它們雖然不是byte[]存儲(chǔ)但JDK 9之后它們?cè)诤芏鄬?shí)現(xiàn)上也做了適配優(yōu)化。整體上整個(gè)字符串體系的性能和內(nèi)存都受益于此。6.2 JDK 8到JDK 17的編譯器優(yōu)化變遷順便說一下編譯器對(duì)字符串拼接的優(yōu)化策略經(jīng)歷了幾次演進(jìn)。JDK 9之前主要是用StringBuilder做鏈?zhǔn)絻?yōu)化JDK 9之后引入了一個(gè)叫StringConcatFactory的機(jī)制默認(rèn)策略是indy它能把字符串拼接更靈活地延遲到運(yùn)行時(shí)處理。這意味著“編譯器一定把它轉(zhuǎn)成StringBuilder”這句話在JDK 9之后已經(jīng)不完全準(zhǔn)確了運(yùn)行時(shí)JIT可能會(huì)采用更聰明的策略比如直接預(yù)估緩沖區(qū)大小、甚至自動(dòng)決定是否用復(fù)制而不是擴(kuò)容。但這個(gè)優(yōu)化同樣有限制——它針對(duì)的是簡(jiǎn)單的、可內(nèi)聯(lián)的拼接表達(dá)式。放到復(fù)雜循環(huán)里編譯器依舊沒辦法幫你自動(dòng)合并依舊要手動(dòng)使用StringBuilder。所以我的一個(gè)建議是別過度依賴編譯器和JDK版本的優(yōu)化該手寫StringBuilder的時(shí)候老實(shí)寫。把性能掌握在自己手里而不是賭JIT的版本和策略。代碼的可讀性和性能保證比依賴某個(gè)JDK版本的“黑科技”更劃算。6.3 JDK 21中的字符串模板這個(gè)未來值得關(guān)注JDK 21引入了“字符串模板”的預(yù)覽特性比如這樣的寫法String name 小明; int age 20; String message STR.姓名:\{name}, 年齡:\{age};這有點(diǎn)像后來很多語言里的字符串插值寫起來比一堆a(bǔ)ppend拼接要直觀得多。但目前Java的字符串模板和StringBuilder不是替代關(guān)系它更多解決的是“可讀性”問題而不是“性能”問題。到了運(yùn)行時(shí)它仍然要經(jīng)過拼接的過程底層實(shí)現(xiàn)依舊依賴字符數(shù)組的擴(kuò)容和拷貝機(jī)制。我對(duì)字符串模板的態(tài)度是關(guān)注它但不必急著大規(guī)模使用。等它轉(zhuǎn)正并穩(wěn)定后配合模式匹配這些新特性確實(shí)能讓代碼寫起來更舒服。但在老項(xiàng)目里StringBuilder依然是那個(gè)最踏實(shí)的選擇。7. 實(shí)戰(zhàn)避坑指南我在真實(shí)項(xiàng)目里踩過的幾個(gè)字符串坑理論講了一大堆最終還是要落到代碼上。這一節(jié)我把自己在實(shí)際項(xiàng)目中踩過的、調(diào)過的、幫同事擦過屁股的幾個(gè)字符串相關(guān)坑拿出來聊希望能幫你繞過。7.1 坑一StringBuilder.reverse()的大坑——小心代理無關(guān)的“中央反轉(zhuǎn)”先說一個(gè)朋友在公司日志脫敏系統(tǒng)里踩的坑。需求是把身份證和手機(jī)號(hào)中的數(shù)字做倒序展示他們直接這樣寫String mobile 13800138000; String masked new StringBuilder(mobile).reverse().toString();乍看沒問題反轉(zhuǎn)后恰好是把尾號(hào)放在前面邏輯上確實(shí)做到了“倒序”。但問題是他們忘了需求里其實(shí)要求的是“只反轉(zhuǎn)部分位”而不是“整串反轉(zhuǎn)”。因?yàn)镾tringBuilder.reverse()是對(duì)整個(gè)字符序列做反轉(zhuǎn)如果把“13800138000”整體反轉(zhuǎn)就成了“00038100831”身份證里的歸屬地信息全亂了。這種坑特別隱蔽因?yàn)槟闳庋劭唇Y(jié)果“確實(shí)是倒的”但業(yè)務(wù)含義卻錯(cuò)了。所以用reverse()前一定要確認(rèn)你的業(yè)務(wù)場(chǎng)景是不是“整個(gè)字符串整體反轉(zhuǎn)”。如果你要的是“后四位放在前面”這種局部反轉(zhuǎn)請(qǐng)先substring再反轉(zhuǎn)拼接而不是直接reverse整個(gè)串。7.2 坑二substring的底層變化和內(nèi)存泄漏隱患JDK 7之前JDK 7之前String.substring()返回的子串會(huì)共享原始字符串的底層char[]數(shù)組而不是拷貝。這在當(dāng)時(shí)是為了節(jié)省內(nèi)存但如果原始字符串很大、子串很小且被長(zhǎng)期持有那么這個(gè)子串會(huì)“拽住”整個(gè)大數(shù)組不讓GC回收——這就是舊JDK版本里非常有名的內(nèi)存泄漏Case。JDK 7之后substring改為創(chuàng)建新數(shù)組并拷貝內(nèi)容不再共享底層數(shù)據(jù)。如果你的項(xiàng)目還在用JDK 6或更早的版本雖然現(xiàn)在很罕見遇到大字符串頻繁substring長(zhǎng)駐內(nèi)存時(shí)要格外小心。即使在新版本里頻繁substring也會(huì)產(chǎn)生拷貝開銷這也是在一些高性能場(chǎng)景用StringBuilder.delete()或subSequence()來替代的原因。7.3 坑三空字符串拼接導(dǎo)致的結(jié)果難排查常見的錯(cuò)誤還有這類邏輯StringBuilder prefix new StringBuilder(); if (condition) { prefix.append(VIP_); } String finalName prefix.append(userName).toString();如果你在condition不滿足時(shí)直接用了finalName最終拿到的其實(shí)是userName本身——因?yàn)閜refix是空的。這類“空拼接”的問題在拼SQL時(shí)特別致命你拼了一個(gè)WHERE 11 AND ...開頭但某個(gè)字段沒傳值最后拼出來的SQL誰能一眼看出問題我的經(jīng)驗(yàn)是在StringBuilder拼接的場(chǎng)景每append完一個(gè)動(dòng)態(tài)片段至少打一行debug日志確認(rèn)當(dāng)前sb的內(nèi)容。尤其是剛接手別人的拼接代碼、或在自己寫了超過5個(gè)append的長(zhǎng)鏈時(shí)。7.4 坑四格式化字符串別忘了String.format的隱藏成本String.format()是一個(gè)常被誤當(dāng)成“拼接優(yōu)化”的方法。它的底層實(shí)現(xiàn)極其復(fù)雜解析格式字符串、生成Formatter、處理各種占位符和參數(shù)類型轉(zhuǎn)換。在低并發(fā)場(chǎng)景下可讀性帶來的價(jià)值遠(yuǎn)大于性能損失但如果你在核心熱路徑里用它構(gòu)造日志就要考慮換成手動(dòng)append了。我處理過一個(gè)案例一個(gè)系統(tǒng)每秒要打上千條審計(jì)日志每條日志用String.format(user%s, action%s, cost%sms, ...)拼接。實(shí)際邏輯對(duì)比后用StringBuilder重構(gòu)后耗時(shí)下降了接近一個(gè)數(shù)量級(jí)。核心熱路徑上的字符串構(gòu)建真的沒必要為了可讀性犧牲這么多性能——可以用模板字符串或者分步append可讀性和性能之間往往有更好的平衡點(diǎn)。7.5 坑五不要用StringBuffer做日志脫敏最后補(bǔ)充一個(gè)StringBuffer相關(guān)的坑。有人為了“線程安全”在日志脫敏系統(tǒng)里把每一次脫敏后的結(jié)果都往一個(gè)StringBuffer里append然后想著反正它是線程安全的多個(gè)線程寫也沒事。結(jié)果日志順序完全亂成一鍋粥。這里又把4.1節(jié)那個(gè)邊界條件拿出來強(qiáng)調(diào)一遍StringBuffer的線程安全不等于業(yè)務(wù)順序安全。如果需要保證“多條日志按提交順序完整輸出”你需要的不是StringBuffer而是隊(duì)列單線程消費(fèi)或者每個(gè)線程獨(dú)立的緩沖區(qū)。線程安全是一個(gè)很基礎(chǔ)的級(jí)別別把它當(dāng)萬能刀。8. 面試官看這段代碼的眼神從String到StringBuilder再到StringBuffer的“送命題”寫了這么多年Java我參加過不少面試也面過不少候選人。這部分梳理幾個(gè)我在面試時(shí)最常用來考察字符串理解的“送命題”附上完整思路對(duì)你準(zhǔn)備面試應(yīng)該有幫助。8.1 題目一為什么String是不可變的常見回答因?yàn)橛昧薴inal修飾、底層char[]/byte[]也被final修飾所以不能改內(nèi)容。這個(gè)回答只能算及格。想答出彩要補(bǔ)充三方面的理由安全性字符串被大量用作參數(shù)、類名、配置項(xiàng)、網(wǎng)絡(luò)協(xié)議字段不可變保證不會(huì)被惡意修改。性能優(yōu)化基礎(chǔ)字符串常量池、hash緩存、多線程安全共享都是建立在不可變前提上的如果可變這些機(jī)制全都會(huì)崩。線程安全不可變對(duì)象天然線程安全任意線程隨意共享引用都沒有數(shù)據(jù)競(jìng)爭(zhēng)問題。8.2 題目二String、StringBuilder、StringBuffer怎么選完整答案應(yīng)該拆成三個(gè)維度內(nèi)容標(biāo)識(shí)不變、需要共享復(fù)用用String。比如常量、配置值、方法參數(shù)。單線程下需要高頻修改、拼接用StringBuilder。尤其循環(huán)體和日志場(chǎng)景要記得盡量預(yù)分配容量。多線程共享同一個(gè)可變緩沖區(qū)時(shí)考慮StringBuffer但還要想清楚順序安全的邊界更推薦用并發(fā)數(shù)據(jù)結(jié)構(gòu)自行保證整體邏輯。如果只是每個(gè)線程各拼各的優(yōu)先StringBuilder。8.3 題目三字符串拼接的“編譯器優(yōu)化”到底優(yōu)化了什么面試時(shí)能答到“javac會(huì)把轉(zhuǎn)成StringBuilder”算及格能往下說才行優(yōu)化只局限在單條語句內(nèi)部循環(huán)體內(nèi)依舊會(huì)創(chuàng)建大量中間對(duì)象。JDK 9之后默認(rèn)優(yōu)化方式從“構(gòu)造StringBuilder”變成了StringConcatFactory的indify機(jī)制到運(yùn)行時(shí)JIT階段再?zèng)Q定實(shí)際拼接策略。無論是哪種優(yōu)化本質(zhì)都是“可變緩沖區(qū)一次性拼接”和手寫StringBuilder思路一致只是邊界和策略不同。8.4 題目四字符串拼接性能和哪幾個(gè)因素相關(guān)幾個(gè)核心點(diǎn)按重要程度排序拼接次數(shù)每多一次拼接就多一分?jǐn)U容和拷貝成本。初始容量預(yù)分配能顯著減少擴(kuò)容次數(shù)。JDK版本JDK 9之后的Compact Strings對(duì)純拉丁字符節(jié)省一半內(nèi)存。并發(fā)度StringBuffer的鎖競(jìng)爭(zhēng)在并發(fā)下會(huì)放大性能問題單線程用StringBuilder。這些問題實(shí)際上把前面聊的所有知識(shí)都串在了一起。能把這些講清楚面試官通常就不會(huì)再在字符串這塊糾纏了——你再深入一點(diǎn)比如講講intern()的JDK版本差異或者講講JDK 9底層byte[]的編碼判斷邏輯已經(jīng)超過大多數(shù)候選人的深度了。9. 到底該怎么寫代碼我的一份可落地的String編碼規(guī)范講了這么多原理和坑是時(shí)候把這些沉淀成一套能直接落到團(tuán)隊(duì)里的編碼規(guī)范了。下面是我自己在項(xiàng)目里會(huì)強(qiáng)制自己和團(tuán)隊(duì)遵守的一套String使用規(guī)則你可以直接抄走按需調(diào)整。原則一能用字面量絕不用new。// 錯(cuò)誤 String s new String(hello); // 正確 String s hello;原則二單條語句的少量拼接用多條/動(dòng)態(tài)拼接用StringBuilder。// 單條語句可讀性優(yōu)先編譯器能處理好 String log user userId , action action; // 循環(huán)或復(fù)雜拼接 StringBuilder sb new StringBuilder(256); for (Item item : items) { sb.append(item.getName()).append(,); }原則三StringBuilder需要預(yù)分配容量時(shí)先算一個(gè)合理上界。比如你知道最大可能有100條記錄、每條按50字符算就按100 * 50來初始化甚至可以加一點(diǎn)余量。原則四純多線程共享且確實(shí)要安全修改時(shí)優(yōu)先考慮用隊(duì)列單線程消費(fèi)而不是StringBuffer。StringBuffer只在“你確實(shí)只需要一個(gè)多線程共享的字節(jié)序列、且接受順序亂的可能”時(shí)才使用。大多數(shù)場(chǎng)景用隊(duì)列會(huì)得到更清晰的設(shè)計(jì)。原則五高性能路徑上的日志/報(bào)文構(gòu)建不要用String.format()和字符串拼接。直接在熱路徑上用StringBuilder把所有信息一步一步append進(jìn)去。這個(gè)優(yōu)化看起來很小但積少成多在高并發(fā)的服務(wù)端里能省下不少CPU和GC時(shí)間。10. 最后聊一點(diǎn)實(shí)際體驗(yàn)我自己寫代碼有個(gè)習(xí)慣在拿到一段新需求時(shí)先判斷這個(gè)字符串將來會(huì)不會(huì)被修改。如果不會(huì)——比如一個(gè)請(qǐng)求參數(shù)、一條配置項(xiàng)、一個(gè)數(shù)據(jù)庫字段名的字符串——就用String享受不可變帶來的所有好處如果會(huì)——比如動(dòng)態(tài)拼SQL、拼HTTP報(bào)文、拼日志——就直接上StringBuilder預(yù)分配容量全程不切String直到最終toString。這套思維模式就是String、StringBuilder、StringBuffer三兄弟在真實(shí)世界里的分工邏輯String負(fù)責(zé)當(dāng)“穩(wěn)定的載體”StringBuilder負(fù)責(zé)“高效的加工”StringBuffer只負(fù)責(zé)“歷史兼容和多線程兜底”。記住這個(gè)分工面試題和實(shí)際代碼就都跑不出你的掌心。如果這篇文章對(duì)你有幫助或者你在項(xiàng)目里也遇到過字符串拼接相關(guān)的性能坑、GC問題歡迎留言交流。順手給自己提個(gè)醒下次看到負(fù)責(zé)拼接的代碼先別急著寫先想想——這個(gè)字符串會(huì)不會(huì)變