Java 8 Update 20 的新特性 —— 字符串去重
2018-07-20 來源：編程學(xué)習(xí)網(wǎng)
字符串在任何應(yīng)用中都占用了大量的內(nèi)存。尤其數(shù)包含獨(dú)立UTF-16字符的char[]數(shù)組對(duì)JVM內(nèi)存的消耗貢獻(xiàn)最多——因?yàn)槊總�(gè)字符占用2位。
內(nèi)存的30%被字符串消耗其實(shí)是很常見的，不僅是因?yàn)樽址桥c我們互動(dòng)的最好的格式，而且是由于流行的HTTP API使用了大量的字符串。使用Java 8 Update 20，我們現(xiàn)在可以接觸到一個(gè)新特性，叫做字符串去重，該特性需要G1垃圾回收器，該垃圾回收器默認(rèn)是被關(guān)閉的。
字符串去重利用了字符串內(nèi)部實(shí)際是char數(shù)組，并且是final的特性，所以JVM可以任意的操縱他們。
對(duì)于字符串去重，開發(fā)者考慮了大量的策略，但最終的實(shí)現(xiàn)采用了下面的方式：
無論何時(shí)垃圾回收器訪問了String對(duì)象，它會(huì)對(duì)char數(shù)組進(jìn)行一個(gè)標(biāo)記。它獲取char數(shù)組的hash value并把它和一個(gè)對(duì)數(shù)組的弱引用存在一起。只要垃圾回收器發(fā)現(xiàn)另一個(gè)字符串，而這個(gè)字符串和char數(shù)組具有相同的hash code，那么就會(huì)對(duì)兩者進(jìn)行一個(gè)字符一個(gè)字符的比對(duì)。
如果他們恰好匹配，那么一個(gè)字符串就會(huì)被修改，指向第二個(gè)字符串的char數(shù)組。第一個(gè)char數(shù)組就不再被引用，也就可以被回收了。
這整個(gè)過程當(dāng)然帶來了一些開銷，但是被很緊實(shí)的上限控制了。例如，如果一個(gè)字符未發(fā)現(xiàn)有重復(fù)，那么一段時(shí)間之內(nèi)，它會(huì)不再被檢查。
那么該特性實(shí)際上是怎么工作的呢？首先，你需要?jiǎng)倓偘l(fā)布的Java 8 Update 20，然后按照這個(gè)配置: -Xmx256m -XX:+UseG1GC 去運(yùn)行下列的代碼：
public class LotsOfStrings {
private static final LinkedList<String> LOTS_OF_STRINGS = new LinkedList<>();
public static void main(String[] args) throws Exception {
int iteration = 0;
while (true) {
for (int i = 0; i < 100; i++) {
for (int j = 0; j < 1000; j++) {
LOTS_OF_STRINGS.add(new String("String " + j));
}
}
iteration++;
System.out.println("Survived Iteration: " + iteration);
Thread.sleep(100);
}
}
}
這段代碼會(huì)執(zhí)行30個(gè)迭代之后報(bào)OutOfMemoryError。
現(xiàn)在，開啟字符串去重，使用如下配置去跑上述代碼：
-Xmx256m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:+PrintStringDeduplicationStatistics
此時(shí)它已經(jīng)可以運(yùn)行更長(zhǎng)的時(shí)間，而且在50個(gè)迭代之后才終止。
JVM現(xiàn)在同樣打印出了它做了什么，讓我們一起看一下：
[GC concurrent-string-deduplication, 4658.2K->0.0B(4658.2K), avg 99.6%, 0.0165023 secs]
[Last Exec: 0.0165023 secs, Idle: 0.0953764 secs, Blocked: 0/0.0000000 secs]
[Inspected: 119538]
[Skipped: 0( 0.0%)]
[Hashed: 119538(100.0%)]
[Known: 0( 0.0%)]
[New: 119538(100.0%) 4658.2K]
[Deduplicated: 119538(100.0%) 4658.2K(100.0%)]
[Young: 372( 0.3%) 14.5K( 0.3%)]
[Old: 119166( 99.7%) 4643.8K( 99.7%)]
[Total Exec: 4/0.0802259 secs, Idle: 4/0.6491928 secs, Blocked: 0/0.0000000 secs]
[Inspected: 557503]
[Skipped: 0( 0.0%)]
[Hashed: 556191( 99.8%)]
[Known: 903( 0.2%)]
[New: 556600( 99.8%) 21.2M]
[Deduplicated: 554727( 99.7%) 21.1M( 99.6%)]
[Young: 1101( 0.2%) 43.0K( 0.2%)]
[Old: 553626( 99.8%) 21.1M( 99.8%)]
[Table]
[Memory Usage: 81.1K]
[Size: 2048, Min: 1024, Max: 16777216]
[Entries: 2776, Load: 135.5%, Cached: 0, Added: 2776, Removed: 0]
[Resize Count: 1, Shrink Threshold: 1365(66.7%), Grow Threshold: 4096(200.0%)]
[Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
[Age Threshold: 3]
[Queue]
[Dropped: 0]
為了方便，我們不需要自己去計(jì)算所有數(shù)據(jù)的加和，使用方便的總計(jì)就可以了。
上面的代碼段規(guī)定執(zhí)行了字符串去重，花了16ms的時(shí)間，查看了約 120 k 字符串。
上面的特性是剛推出的，意味著可能并沒有被全面的審視。具體的數(shù)據(jù)在實(shí)際的應(yīng)用中可能看起來有差別，尤其是那些應(yīng)用中字符串被多次使用和傳遞，因此一些字符串可能被跳過或者早就有了hashcode（正如你可能知道的那樣，一個(gè)String的hash code是被懶加載的）。
在上述的案例中，所有的字符串都被去重了，在內(nèi)存中移除了4.5MB的數(shù)據(jù)。
[Table]部分給出了有關(guān)內(nèi)部跟蹤表的統(tǒng)計(jì)信息，[Queue]則列出了有多少對(duì)去重的請(qǐng)求由于負(fù)載被丟棄，這也是開銷減少機(jī)制中的一部分。
那么，字符串去重和字符串駐留相比又有什么差別呢？我博客上有一篇文章，名叫how great String Interning is for memory efficiency 。事實(shí)上，字符串去重和駐留看起來差不多，除了暫留的機(jī)制重用了整個(gè)字符串實(shí)例，而不僅僅是字符數(shù)組。
JDK Enhancement Proposal 192的創(chuàng)造者的爭(zhēng)論點(diǎn)在于開發(fā)者們常常不知道將駐留字符串放在哪里合適,或者是合適的地方被框架所隱藏.就像我寫的那樣,當(dāng)碰到復(fù)制字符串(像國(guó)家名字)的時(shí)候,你需要一些常識(shí).字符串去重,對(duì)于在同一個(gè)JVM中的應(yīng)用程序的字符串復(fù)制也有好處,同樣包括像XML Schemas,urls以及jar名字等一般認(rèn)為不會(huì)出現(xiàn)多次的字符串.
當(dāng)字符串駐留發(fā)生在應(yīng)用程序線程中的時(shí)候,垃圾回收異步并發(fā)處理時(shí),字符串去重也不會(huì)增加運(yùn)行時(shí)的消耗.這也解釋了,為什么我們會(huì)在上面的代碼中發(fā)現(xiàn)Thread.sleep().如果沒有sleep會(huì)給GC增加太多的壓力,這樣字符串去重根本就不會(huì)發(fā)生.但是,這只是示例代碼才會(huì)出現(xiàn)的問題.實(shí)際的應(yīng)用程序,常常會(huì)在運(yùn)行字符串去重的時(shí)候使用幾毫秒的時(shí)間.
原文地址：https://blog.codecentric.de/en/2014/08/string-deduplication-new-feature-java-8-update-20-2/
版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。
