以“技”服人
管理一個以年輕人爲主的技術團隊，一方面要在管理方式上下功夫，而另一方面更需要以“技”服人。如果作爲一個技術團隊的老大，你胸無點墨，總是被團隊成員的技術問題難倒，那就算你管理方式再厲害，在大家心中，你還是不能贏得大家的尊重。
所以作爲基層技術團隊的負責人，一定要在技術方面能領導這個團隊，能在技術方面給大家指導，這樣才能“壓”的住，即使你不能每個問題都能擺平，但是江湖一定要有你的大神傳說。
那天在評審代碼時，遇到一個字符串拼接的問題，小兄弟使用了+來實現的，我隨口反問了句，爲什麼不使用StringBuilder？
小兄弟一臉懵逼的表情，眼神中質問着我，這又顯的你了？是的，我看到了他的質疑，但是我必須拿捏他。這裏就將那天口頭分享的內容整理成文，和大家分享。
先說結論，再說細節
現在的快節奏，很多讀者只需要結論，並不在乎細節，所以先擺出結論，後續再細說細節：
如果不需要頻繁操作拼接或者修改字節串，直接使用
String更便捷，代碼更簡潔；如果非要給這個頻繁限定一個範圍的話，我想1萬以內，都是可以的如果需要頻繁進行字符串拼接或者修改，並且有多個線程併發訪問該字符串，則應選擇使用線程安全的
StringBuffer，有了安全，那就要放棄一定的性能如果頻繁操作拼接或者修改，但只有單個線程訪問該字節串，則
StringBuilder則是最好的選擇
當你說出了準確答案，你已經讓別人信服了8分；如果你把細節也講透了，那你就完全拿捏了。
String的細節
String類型，編碼的兄弟肯定天天都會和它打交道，我們先來看看String類的內部定義。
String類中value字段用於儲存字符串的實際內容，value是一個char[]數組，並且用final修飾初始化定長度後即不可改變，這就表示value的引用地址是不可變的（但裏面的元素是可變的），再加上final修飾的String類不能被繼承，這就決定value數組的元素值已經無法從外部修改了，最終決定了String對象是不可變的。
在String類內部，定義了一堆字符串操作函數，而這些對字符串操作的函數，都是重新定義了新的字符串進行返回，而原字符串內容並不會變更。
StringBuffer的細節
StringBuffer類在內部實現時，主要是實現了AbstractStringBuilder抽象類，在該類中，定義了一個可char[]的數組來存放字符串，當進行append操作時，如果數組空間不夠用，就會根據內定算法重新申請空間，並將原數據拷貝過來。在內部實現上，都是通過使用synchronized關鍵字來實現的線程安全。
通過大量使用synchronized就會不可避免的影響性能，而在StringBuffer類的內部實現上，結合多線程的讀多寫少的使用場景，爲了提升性能，有一個實現小細節，有以下一個變量定義：
字段上的解釋是返回最後一次toString的緩存值，一旦StringBuffer被修改就清除這個緩存值，這裏搞了這個緩存，可以平衡StringBuffer的性能。這個小細節，我們日後在開發時，可以借鑑哦。
StringBuilder的細節
StringBuilder與StringBuffer的最大區別就是使用synchronized關鍵字實現的線程安全上，其它上面大同小異，不再糾結，有空可以去看看源代碼，還是會有好多收穫的。
總結
他們問孔乙己，茴香豆的茴有幾種寫法，但是我堅信這篇文章絕對不是一篇八股文。漸漸的，慢慢的，發現身邊在乎技術細節的同事越來越少了，喜歡打磨代碼的人也越來越少了，問題出在哪裏？