今天給大家聊聊咱們平時(shí)寫代碼的時(shí)候，最常見的 String 字符串代碼，他的一些底層原理，以及使用不當(dāng)可能引發(fā)的內(nèi)存泄漏的問題，相信對于大家平時(shí)日常開發(fā)寫代碼會有一定的幫助。

String 字符串在內(nèi)存里是如何存儲的？

首先呢，當(dāng)我們平時(shí)在代碼中寫下一行 String 類型的代碼時(shí)，大家知道這個(gè) String 字符串在內(nèi)存里是如何存儲的嗎？

比如這樣的一行代碼：String username = "zhangsan"，這個(gè)"zhangsan"其實(shí)就是一串字符串，實(shí)際上他在底層是用一個(gè)數(shù)組來存放的，而且這個(gè)數(shù)組大小就嚴(yán)格等于這個(gè)字符串的長度，他是不可變的。

如下圖：

接著呢，對于 Java 中的字符串來說，有一個(gè)常量池的概念，意思就是說，對于相同的字符串內(nèi)容，他往往會在內(nèi)存里用同一個(gè)數(shù)組來表示，而不會對相同的字符串內(nèi)容創(chuàng)建出不同的數(shù)組來存放。

比如說下面兩行代碼，大家看看：

String username = "zhangsan"; 
String nickname = "zhangsan";

上面的 username 和 nickname 他們兩個(gè)字符串指向的內(nèi)容都是"zhangsan"，實(shí)際上在底層都是用同一個(gè)數(shù)組來存放的。

如下圖所示：

所以說，正是因?yàn)橄嗤淖址且玫耐粋€(gè)底層的數(shù)組，所以如果用類似于 System.out.println(username == nickname) 這種判斷代碼的話，會發(fā)現(xiàn) username == nickname 返回的是 true，因?yàn)樗麄儌z就是指向了底層同一個(gè)數(shù)組的。

另外再給大家普及一個(gè)字符串的知識點(diǎn)，那就是如果我們用一個(gè)字符串創(chuàng)建一個(gè) String 對象的話，那他在內(nèi)存里一定是另外的一個(gè)對象了。

如下代碼所示，大家看看：

String username = "zhangsan"; 
String nickname = new String("zhangsan"); 
System.out.println(username == nickname);

大家看上面代碼，此時(shí) username 和 nickname 比較還是返回 true 嗎？

那不可能的，此時(shí)一定是 false，因?yàn)榇藭r(shí)在內(nèi)存里，username 是指向一個(gè)數(shù)組的，但是 nickname 是指向一個(gè) String 對象的，只不過這個(gè) String 對象里面是有一個(gè)"zhangsan"字符串而已。

如下圖：

但是這個(gè)時(shí)候又給大家再次介紹一個(gè)知識點(diǎn)了，那就是這個(gè) String 對象內(nèi)部的"zhangsan"字符串，是怎么存儲的呢？

其實(shí)啊，這個(gè) String 對象內(nèi)部的"zhangsan"字符串還是引用了之前的那個(gè)數(shù)組的，如下圖所示：

String.intern() 方法

所以說，如果此時(shí)你用 String.intern() 方法，就會發(fā)現(xiàn)你可以拿到 String 對象里的"zhangsan"字符串，此時(shí)再用這個(gè)字符串做比較，還是返回的是 true。

大家看下面代碼就懂了：

String username = "zhangsan"; 
String nickname = new String("zhangsan");
System.out.println(username == nickname.intern()); // 返回的是true

String 字符串是如何引發(fā)內(nèi)存泄漏呢？

好，那么大家都理解了 Java 里字符串的基本原理后，我們就可以來給大家講講平時(shí)我們用字符串 String 寫代碼，一旦要是不注意，是如何引發(fā)內(nèi)存泄漏問題的。

這個(gè)問題主要是出現(xiàn)在 Java 6 以及之前的版本里，在這個(gè)較為舊的 Java 版本中，String.substring() 這種字符串截取動作，是會導(dǎo)致內(nèi)存泄漏的，什么意思呢，我們來看看。

在 Java 6 以前的版本中，當(dāng)你調(diào)用 String.substring() 進(jìn)行字符串截取的時(shí)候，他在底層的運(yùn)作模式是這樣的，他會把你的原字符串的數(shù)組直接拷貝一份過來，然后用一個(gè) offset 指針和 count 標(biāo)記，來表名截取后的字符串你是需要哪些。

如下圖所示：

可是在這種運(yùn)作模式下就有一個(gè)問題了，就是你每次 substring 都會把原數(shù)組拷貝一份，可是對于你的子字符串來說僅僅是需要里面的一部分而已，而你缺把原字符串每次都拷貝一份，導(dǎo)致了子字符串中不需要的那部分拷貝內(nèi)容都是浪費(fèi)掉的。

如下圖紅圈部分都是子字符串不需要的：

所以此時(shí)子字符串不需要的紅圈部分處的內(nèi)容還依然占據(jù)了內(nèi)存，這屬于什么問題呢？

就是典型的內(nèi)存泄漏了，也就是說，你要是大量的進(jìn)行 substring 一類的操作，就可能會大量的拷貝字符串?dāng)?shù)組，然后很多拷貝后的字符串?dāng)?shù)組里，很多內(nèi)容都是不需要用的，結(jié)果還占據(jù)了很多內(nèi)存空間，這就叫做內(nèi)存泄漏。

內(nèi)存泄漏指的就是你很多內(nèi)存空間被占用了，結(jié)果你又不用他，別人也沒法用，就是典型的占著茅坑不拉屎的行為。

所以后來在 Java 7 版本開始就對 String.substring() 進(jìn)行了源碼重構(gòu)，開始改造了這部分的實(shí)現(xiàn)，每次你執(zhí)行 String.substring，他是把原字符串?dāng)?shù)組中你需要的那部分拷貝過來就可以了，就避免了每次都重復(fù)的拷貝原字符串?dāng)?shù)組。

如下圖：

總結(jié)

在這種 Java 7 以及往后的新版本中，就徹底的解決了 substring 導(dǎo)致的內(nèi)存泄漏問題了，因此大家平時(shí)在用字符串做開發(fā)的過程中，也一定要小心謹(jǐn)慎，避免誤用老版本的 Java 觸發(fā)這種內(nèi)存泄漏隱患。

當(dāng)然現(xiàn)在一般都是用 Java 8 以上的版本，尤其較多的是用 Java 9、Java 10 甚至 Java 11 這幾個(gè)新版本了。

但是不排除有一些公司的非常老舊的系統(tǒng)在維護(hù)的時(shí)候，用的還是曾經(jīng)很風(fēng)靡的 Java 6 這個(gè)版本，大家在對這類老系統(tǒng)維護(hù)的時(shí)候，一定要謹(jǐn)慎注意 substring 內(nèi)存泄漏問題。