String類存在于java.lang包中，在程序里使用挺廣泛的，用來(lái)創(chuàng)建一個(gè)字符串對(duì)象變量，Java內(nèi)部對(duì)String類做了一些特殊的處理，例如把String類聲明成final類型，也就是說(shuō)不能有子類，String類型對(duì)象一旦創(chuàng)建后就不可改變（你可能會(huì)想不是可以拼接字符串嗎，怎么不可以改變String類對(duì)象了，別急，下面慢慢看），以及一些針對(duì)JVM的優(yōu)化等，先來(lái)簡(jiǎn)單看看String類在Java中的一些特點(diǎn)。

被定義為final類

在Java語(yǔ)言中，String類型被定義成final修飾，導(dǎo)致String類不能擁有其他子類，最主要的是出于安全方面問(wèn)題，JDK中的一些核心類，包括String類，內(nèi)部實(shí)現(xiàn)都不是Java語(yǔ)言，而是調(diào)用了系統(tǒng)本地的API，這些API較為底層，需要和操作系統(tǒng)打交道，所以為了安全起見(jiàn)，String類定義為final修飾，不允許被繼承，也就不會(huì)被重寫(xiě)。

不可改變

String對(duì)象的不可改變，也就是不變性，指的是String對(duì)象一旦創(chuàng)建成功后，就不能再對(duì)它進(jìn)行修改，

看一個(gè)例子：

程序中進(jìn)行了一次字符串拼接，都在同一個(gè)String對(duì)象str上操作，雖然如此，但是可以看到兩次輸出的hashCode是不同的，原因是String對(duì)象一旦在JVM常量池里面被創(chuàng)建，那么它的地址就不會(huì)被修改，即使我們對(duì)對(duì)象進(jìn)行拼接等修改，也只是把新的字符串保存到一個(gè)新的地址中去。

所以說(shuō)，所謂的String不可改變，不是指的該類型實(shí)例對(duì)象的指向不可改變，我們可以把上面程序中的str對(duì)象指向新的字符串地址，但是原來(lái)的字符串還是存在于JVM常量池中，沒(méi)有改變，不可改變指的就是這個(gè)，字符串一旦創(chuàng)建后，一直存在，不可修改，對(duì)象可以修改指向，不指向它的地址，一旦該字符串沒(méi)有任何變量指向它后，就等著GC把它回收掉。

常量池優(yōu)化

String對(duì)象不可改變的好處是多線程環(huán)境下訪問(wèn)安全，性能高，因?yàn)閷?duì)象不可被修改，所以多線程對(duì)它的訪問(wèn)只能是讀操作，多個(gè)讀操作即使不加同步處理也不會(huì)出現(xiàn)修改數(shù)據(jù)導(dǎo)致不一致的問(wèn)題，所以減少了許多不必要的同步操作，提高了性能。

可以來(lái)看一個(gè)簡(jiǎn)單的例子：

證明在JVM內(nèi)部，當(dāng)兩個(gè)String類型對(duì)象存放相同的字符串時(shí)，它們?cè)诔Ａ砍貎?nèi)部的引用是一樣的：

程序中，String對(duì)象str_1和str_2它們的字符串內(nèi)容是相同的，這兩個(gè)對(duì)象在創(chuàng)建時(shí)都各自在堆中分配了自己的空間，所以輸出str_1 == str_2的結(jié)果為false。

之后我們通過(guò)String.intern（）方法輸出兩者在常量池中的引用，發(fā)現(xiàn)是一樣的，也就是說(shuō)，兩個(gè)不同的String對(duì)象，因?yàn)橹迪嗤?，所以在常量池中引用的是同一個(gè)副本，這是一種常量池優(yōu)化，為了節(jié)省內(nèi)存空間。

String造成的內(nèi)存泄漏

內(nèi)存泄漏上一篇日志講過(guò)，指的是程序由于一些設(shè)計(jì)上的問(wèn)題或者執(zhí)行過(guò)程中出錯(cuò)，在申請(qǐng)內(nèi)存，使用完畢后沒(méi)有釋放資源，內(nèi)存堆積越來(lái)越多，最后堆空間被占用完，具體的例子就是一些已經(jīng)不再被使用的對(duì)象沒(méi)有被回收，一直常駐在內(nèi)存中。

雖然GC會(huì)幫助我們自動(dòng)回收那些已經(jīng)不再被使用的對(duì)象，但是如果程序的一些邏輯設(shè)計(jì)不當(dāng)，仍然會(huì)出現(xiàn)內(nèi)存泄漏問(wèn)題，最后導(dǎo)致內(nèi)存溢出。

舉個(gè)例子：

如果String類的substring（）方法使用不恰當(dāng)，也有可能導(dǎo)致內(nèi)存泄漏，不過(guò)這個(gè)問(wèn)題隨著JDK的更新，早已被修復(fù)了，還是總結(jié)一下，當(dāng)作一種設(shè)計(jì)上的前車之鑒，提醒自己日后留意類似的這種情況（例如創(chuàng)建定長(zhǎng)數(shù)組時(shí)）。

String結(jié)構(gòu)

String.substring（）方法導(dǎo)致內(nèi)存泄漏問(wèn)題與String類的結(jié)構(gòu)有關(guān)，String的結(jié)構(gòu)分為三部分組成，count長(zhǎng)度，value數(shù)組和offset偏移量，假設(shè)有這么一種情況，String對(duì)象的value數(shù)組可以存儲(chǔ)500個(gè)字符，count長(zhǎng)度標(biāo)識(shí)有10字節(jié)，那么這個(gè)String對(duì)象實(shí)際占用的空間是10個(gè)字節(jié)，剩下的490個(gè)字節(jié)空間就放在那里了，它們一直沒(méi)有被使用，直到這個(gè)String對(duì)象被釋放前，它們都會(huì)常駐在內(nèi)存中。

回到String.substring（）方法，它的內(nèi)部實(shí)現(xiàn)是這樣的：

public String substring(int beginIndex, int endIndex) {
	if(beginIndex < 0) {
		throw new StringIndexOutOfBoundsException(beginIndex);
	}
	if(endIndex > count) {
		throw new StringIndexOutOfBoundsException(endIndexIndex);
	}
	if(beginIndex > endIndex) {
		throw new StringIndexOutOfBoundsException(endIndex - beginIndex);
	}
	return ((beginIndex ==0) && (endIndex == count)) ? this :
		new String(offset + beginIndex, endIndex - beginIndex, value);
}
String(int offset, int count, char value[]) {
	this.value = value;
	this.offset = offset;
	this.count = count;
}

可以看到方法內(nèi)部對(duì)于一些邊界情況拋出異常信息，最后調(diào)用了String類的構(gòu)造函數(shù)，從傳入的參數(shù)看，offset偏移量和count變量都發(fā)生了改變，但是value數(shù)組沒(méi)有改變，使用的還是原來(lái)舊的引用，這么做的問(wèn)題是，如果舊的String字符串被回收后，這個(gè)value值沒(méi)有得到更新，而是跟著創(chuàng)建新的String對(duì)象，那么使用舊的value創(chuàng)建出來(lái)的新的String對(duì)象中多出來(lái)的原來(lái)已經(jīng)被回收了的部分內(nèi)存，就堆積在那里了，跟著新的對(duì)象常駐在內(nèi)存中，隨著字符串拼接操作，substring（）方法被多次調(diào)用后，便可能會(huì)造成內(nèi)存泄漏。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論