前言

此前部門內(nèi)的一個(gè)線上系統(tǒng)上線后內(nèi)存一路飆高、一段時(shí)間后直接占滿。協(xié)助開發(fā)人員去分析定位，發(fā)現(xiàn)內(nèi)存中某個(gè)Object的量遠(yuǎn)遠(yuǎn)超出了預(yù)期的范圍，很明顯出現(xiàn)內(nèi)存泄漏了。

結(jié)合代碼分析發(fā)現(xiàn)，泄漏的這個(gè)對象，主要存在一個(gè)全局HashMap中，是作為HashMap的Key值。第一反應(yīng)就是這里key對應(yīng)類沒有去覆寫equals()和hashCode()方法，但對照代碼仔細(xì)一看卻發(fā)現(xiàn)其實(shí)已經(jīng)按要求提供了自定義的equals和hashCode方法了。進(jìn)一步走讀業(yè)務(wù)實(shí)現(xiàn)邏輯，才發(fā)現(xiàn)了其中的玄機(jī)。

踩坑歷程回顧

鑒于項(xiàng)目代碼相對保密，這里舉個(gè)簡單的DEMO來輔助說明下。

場景： 內(nèi)存中構(gòu)建一個(gè)HashMap<User, List<Post>>映射集，用于存儲每個(gè)用戶最近的發(fā)帖信息(只是個(gè)例子，實(shí)際工作中如果遇到這種用戶發(fā)帖緩存的場景，一般都是用的集中緩存，而不是單機(jī)緩存)。

用戶信息User類定義如下：

@Data
public class User {
    // 用戶名稱
    private String userName;
    // 賬號ID
    private String accountId;
    // 用戶上次登錄時(shí)間，每次登錄的時(shí)候會自動更新DB對應(yīng)時(shí)間
    private long lastLoginTime;
    // 其他字段，忽略
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return lastLoginTime == user.lastLoginTime &&
                Objects.equals(userName, user.userName) &&
                Objects.equals(accountId, user.accountId);
    }
    @Override
    public int hashCode() {
        return Objects.hash(userName, accountId, lastLoginTime);
    }
}

實(shí)際使用的時(shí)候,用戶發(fā)帖之后，會將這個(gè)帖子信息添加到用戶對應(yīng)的緩存中。

/**
 *  將發(fā)帖信息加入到用戶緩存中
 *
 * @param currentUser 當(dāng)前用戶
 * @param postContent 帖子信息
 */
public void addCache(User currentUser, Post postContent) {
    cache.computeIfAbsent(currentUser, k -> new ArrayList<>()).add(postContent);
}

當(dāng)實(shí)際運(yùn)行的時(shí)候，會發(fā)現(xiàn)問題就來了，Map中的記錄越來越多，遠(yuǎn)超系統(tǒng)內(nèi)實(shí)際的用戶數(shù)量。為什么呢？仔細(xì)看下User類就可以知道了！

原來編碼的時(shí)候直接用IDE工具自動生成的equals和hashCode方法，里面將lastLoginTime也納入計(jì)算邏輯了。這樣每次用戶重新登錄之后，對應(yīng)hashCode值也就變了，這樣發(fā)帖的時(shí)候判斷用戶是不存在Map中的，就會再往map中插入一條，隨著時(shí)間的推移，內(nèi)存中數(shù)據(jù)就會越來越多，導(dǎo)致內(nèi)存泄漏。

這么一看，其實(shí)問題很簡單。但是實(shí)際編碼的時(shí)候，很多人往往又會忽略這些細(xì)節(jié)、或者當(dāng)時(shí)可能沒有這個(gè)場景，后面維護(hù)的人新增了點(diǎn)邏輯，就會出問題 —— 說白了，就是埋了個(gè)坑給后面的人踩上了。

hashCode覆寫的講究

hashCode，即一個(gè)Object的散列碼。HashCode的作用：

• 對于List、數(shù)組等集合而言，HashCode用途不大；
• 對于HashMap\HashTable\HashSet等集合而言，HashCode有很重要的價(jià)值。

HashCode在上述HashMap等容器中主要是用于尋域，即尋找某個(gè)對象在集合中的區(qū)域位置，用于提升查詢效率。

一個(gè)Object對象往往會存在多個(gè)屬性字段，而選擇什么屬性來計(jì)算hashCode值，具有一定的考驗(yàn)：

• 如果選擇的字段太多，而HashCode()在程序執(zhí)行中調(diào)用的非常頻繁，勢必會影響計(jì)算性能；
• 如果選擇的太少，計(jì)算出來的HashCode勢必很容易就會出現(xiàn)重復(fù)了。

為什么hashCode和equals要同時(shí)覆寫

這就與HashMap的底層實(shí)現(xiàn)邏輯有關(guān)系了。

對于JDK1.8+版本中，HashMap底層的數(shù)據(jù)結(jié)構(gòu)形如下圖所示，使用數(shù)組+鏈表或者紅黑樹的結(jié)構(gòu)形式：

給定key進(jìn)行查詢的時(shí)候，分為2步：

• 調(diào)用key對象的hashCode()方法，獲取hashCode值，然后換算為對應(yīng)數(shù)組的下標(biāo)，找到對應(yīng)下標(biāo)位置；
• 根據(jù)hashCode找到的數(shù)組下標(biāo)可能會同時(shí)對應(yīng)多個(gè)key（所謂的hash碰撞，不同元素產(chǎn)生了相同的hashCode值），這個(gè)時(shí)候使用key對象提供的equals()方法，進(jìn)行逐個(gè)元素比對，直到找到相同的元素，返回其所對應(yīng)的值。

根據(jù)上面的介紹，可以概括為：

• hashCode負(fù)責(zé)大概定位，先定位到對應(yīng)片區(qū)
• equals負(fù)責(zé)在定位的片區(qū)內(nèi)，精確找到預(yù)期的那一個(gè)

這里也就明白了為什么hashCode()和equals()需要同時(shí)覆寫。

數(shù)據(jù)退出機(jī)制的兜底

其實(shí)，說到這里，全局Map出現(xiàn)內(nèi)存泄漏，還有一點(diǎn)就是編碼實(shí)現(xiàn)的時(shí)候缺少對數(shù)據(jù)退出機(jī)制的考慮。 參考下redis之類的依賴內(nèi)存的緩存中間件，都有一個(gè)繞不開的兜底策略，即數(shù)據(jù)淘汰機(jī)制。

對于業(yè)務(wù)類編碼實(shí)現(xiàn)的時(shí)候，如果使用Map等容器類來實(shí)現(xiàn)全局緩存的時(shí)候，應(yīng)該要結(jié)合實(shí)際部署情況，確定內(nèi)存中允許的最大數(shù)據(jù)條數(shù)，并提供超出指定容量時(shí)的處理策略。比如我們可以基于LinkedHashMap來定制一個(gè)基于LRU策略的緩存Map，來保證內(nèi)存數(shù)據(jù)量不會無限制增長，這樣即使代碼出問題也只是這一個(gè)功能點(diǎn)出問題，不至于讓整個(gè)進(jìn)程宕機(jī)。

public class FixedLengthLinkedHashMap<K, V> extends LinkedHashMap<K, V> {
    private static final long serialVersionUID = 1287190405215174569L;
    private int maxEntries;

    public FixedLengthLinkedHashMap(int maxEntries, boolean accessOrder) {
        super(16, 0.75f, accessOrder);
        this.maxEntries = maxEntries;
    }
    /**
     *  自定義數(shù)據(jù)淘汰觸發(fā)條件，在每次put操作的時(shí)候會調(diào)用此方法來判斷下
     */
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxEntries;
    }
}

總結(jié)

梳理下幾個(gè)要點(diǎn)：

• 最好不要使用Object作為HashMap的Key
• 如果不得已必須要使用，除了要覆寫equals和hashCode方法
• 覆寫的equals和hashCode方法中一定不能有頻繁易變更的字段
• 內(nèi)存緩存使用的Map，最好對Map的數(shù)據(jù)記錄條數(shù)做一個(gè)強(qiáng)制約束，提供下數(shù)據(jù)淘汰策略。

到此這篇關(guān)于為什么不建議使用Java自定義Object作為HashMap的key的文章就介紹到這了,更多相關(guān)Java HashMap的key內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論