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