這是最近發(fā)生的又一起內(nèi)存相關(guān)的事件了。這個(gè)案例是從一個(gè)最近的客戶報(bào)告中提取出來，一個(gè)異常運(yùn)行的應(yīng)用在其產(chǎn)品中反復(fù)報(bào)告內(nèi)存耗盡。

這個(gè)癥狀是由我們的一個(gè)實(shí)驗(yàn)性功能發(fā)現(xiàn)，它主要用來監(jiān)測(cè)某一類數(shù)據(jù)結(jié)構(gòu)的使用情況。它提供了一個(gè)信號(hào)探針，結(jié)果會(huì)指向問題源代碼的某一位置。為了保護(hù)客戶的隱私，我們?nèi)藶橹亟嗽摾硬⒈３炙鎸?shí)場(chǎng)景在技術(shù)層面的一致性。你可以免費(fèi)在此處下載到源碼。

故事開始于一組從外界源加載進(jìn)來的對(duì)象。同外部的信息交互是基于XML的接口，這本身并沒什么大不了的，但事實(shí)上“基于XML的格式進(jìn)行通訊”的實(shí)現(xiàn)細(xì)節(jié)被分散到了系統(tǒng)的每一個(gè)角落。 傳入系統(tǒng)的文檔是首先被轉(zhuǎn)換成XMLBean實(shí)例，然后在整個(gè)系統(tǒng)范圍內(nèi)被使用，這中做法聽起來有點(diǎn)傻。

整個(gè)問題中最核心的部分是一個(gè)延遲加載的緩沖方案。緩存的對(duì)象是“Person”的實(shí)例：

// Imports and methods removed to improve readability  
public class Person {  
    private String id;  
    private Date dateOfBirth;  
    private String forename;  
    private String surname;  
} 

你也許會(huì)說這才能消耗多少內(nèi)存呢。但當(dāng)我們揭開進(jìn)一步的細(xì)節(jié)時(shí)，發(fā)現(xiàn)事情就變了味了。表面上根據(jù)設(shè)計(jì)，聲稱實(shí)現(xiàn)只用到的諸如上文提到的那樣一些簡(jiǎn)單的類，但真實(shí)的情形是使用了基于模型生成的數(shù)據(jù)結(jié)構(gòu)。使用的模型是諸如下面的這個(gè)簡(jiǎn)化的XSD片段。

<xs:schema targetNamespace="http://plumbr.eu" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified"> 
    <xs:element name="person"> 
        <xs:complexType> 
            <xs:sequence> 
                <xs:element name="id" type="xs:string"/> 
                <xs:element name="dateOfBirth" type="xs:dateTime"/> 
                <xs:element name="forename" type="xs:string"/> 
                <xs:element name="surname" type="xs:string"/> 
            </xs:sequence> 
        </xs:complexType> 
    </xs:element> 
</xs:schema> 

使用XMLBeans，開發(fā)者生成了該模型，并在真實(shí)的場(chǎng)景中使用。現(xiàn)在我們回到開始的這個(gè)緩存的方案上來，假設(shè)它設(shè)計(jì)初衷是為了支持最多1.3M Person類的實(shí)例，而我們實(shí)際卻要塞進(jìn)去同等數(shù)量的大家伙，這從根上就注定了失敗。

跑一組測(cè)試用例后，發(fā)現(xiàn)1.3M個(gè)基于XMLBean的生成的實(shí)例需要消耗大概1.5GB的堆空間。我們當(dāng)時(shí)想這肯定可以做的更好。

第一個(gè)改進(jìn)是顯而易見的，外部同系統(tǒng)內(nèi)部集成的實(shí)現(xiàn)細(xì)節(jié)是不應(yīng)該把影響傳遞給系統(tǒng)的每一個(gè)角落的。所以我們把緩存改成了使用簡(jiǎn)單的 java.util.HashMap<Long, Person>。ID是鍵，Person是值。我們發(fā)現(xiàn)內(nèi)存的消耗立即降低到了214MB。但這還不能令我們滿意。

由于Map中的鍵是一個(gè)數(shù)，我們有十足的理由使用Trove Collections來進(jìn)一步降低它的內(nèi)存消耗。這在實(shí)現(xiàn)上的改動(dòng)很快，我們只需把 HashMap 改成 TLongObjectHashMap<Person> ，堆的消耗進(jìn)一步降低到了143MB。

活干到這個(gè)程度我們已經(jīng)可以收工了，但是工程師的好奇心驅(qū)使我們要更進(jìn)一步。不由自主的我們發(fā)現(xiàn)了系統(tǒng)的數(shù)據(jù)存在著大量的重復(fù)信息。例如Date Of Birth其實(shí)已經(jīng)在ID中編碼了，所以Date Of Birth可以直接從ID中得到，而不必使用額外的空間去它。

經(jīng)過改良，Person類現(xiàn)在變成了這個(gè)樣子：

// Imports and methods removed to improve readability  
public class Person {  
    private String id;  
    private String forename;  
    private String surname;  
} 

重新跑一邊測(cè)試證實(shí)我們的改進(jìn)的確有效，堆消耗降低到了93MB。但是我們還未滿足。

該應(yīng)用在64位的機(jī)器上使用老的JDK6。默認(rèn)情況下，這么做不能壓縮普通對(duì)象的指針的。通過參數(shù)”-XX:UseCompressedOops“切換到壓縮模式使我們獲得了額外的收獲，現(xiàn)在我們的內(nèi)存消耗降低到了73MB。

當(dāng)然，我們還能走的更遠(yuǎn)。比如基于鍵值建立B-tree，但這已經(jīng)開始影響到了代碼的可讀性，所以我們決定到此為止。降低21.5倍的堆內(nèi)存應(yīng)該已經(jīng)是一個(gè)足夠好的結(jié)果了。

讓我們?cè)谥貜?fù)一下學(xué)到了什么

別把同外部模塊的整合影響到系統(tǒng)的每一個(gè)角落

冗余的數(shù)據(jù)可能帶來開銷。在可能的情況下盡量消除它

基本數(shù)據(jù)類型是你最經(jīng)常打交道的朋友，務(wù)必知道些關(guān)于它們的工具，如果還沒玩過Trove請(qǐng)立刻開始吧

JVM自帶的優(yōu)化技術(shù)不可忽視

如果你對(duì)這個(gè)實(shí)驗(yàn)很好奇，請(qǐng)?jiān)诖颂?a target="_blank" onclick="javascript:_gaq.push(['_trackEvent','download','http://www.plumbr.eu/files/plumbr-optimization-sample.zip']);" >下載相關(guān)的代碼。使用到的的測(cè)量工具和其具體描述可以在這篇博文找到。

原文鏈接： Nikita Salnikov-Tarnovski

譯文鏈接：http://blog.jobbole.com/40666/