詳解處理Java中的大物件的方法

2022-04-14 10:01:00

但這還遠遠不夠，我們僅僅減少了物件的建立頻率，但並沒有改變物件“大”這個事實。本文，將從 JDK 的一些知識點講起，先來看幾個面試頻率比較高的物件複用問題；接下來，從資料的結構緯度和時間維度出發，分別逐步看一下一些把物件變小，把操作聚焦的策略。

String中的substring

我們都知道，String 在 Java 中是不可變的，如果你改動了其中的內容，它就會生成一個新的字串。如果我們想要用到字串中的一部分資料，就可以使用 substring 方法。

下面是Java11中String的原始碼。

public String substring(int beginIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    int subLen = length() - beginIndex;
    if (subLen < 0) {
        throw new StringIndexOutOfBoundsException(subLen);
    }
    if (beginIndex == 0) {
        return this;
    }
    return isLatin1() ? StringLatin1.newString(value, beginIndex, subLen)
                      : StringUTF16.newString(value, beginIndex, subLen);
}

public static String newString(byte[] val, int index, int len) {
    if (String.COMPACT_STRINGS) {
        byte[] buf = compress(val, index, len);
        if (buf != null) {
            return new String(buf, LATIN1);
        }
    }
    int last = index + len;
    return new String(Arrays.copyOfRange(val, index << 1, last << 1), UTF16);
}

如上述程式碼所示，當我們需要一個子字串的時候，substring 生成了一個新的字串，這個字串通過建構函式的 Arrays.copyOfRange 函數進行構造。

這個函數在 Java7 之後是沒有問題的，但在Java6 中，卻有著記憶體漏失的風險，我們可以學習一下這個案例，來看一下大物件複用可能會產生的問題。下面是Java6中的程式碼：

public String substring(int beginIndex, int endIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    if (endIndex > count) {
        throw new StringIndexOutOfBoundsException(endIndex);
    }
    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;
}

可以看到，它在建立子字串的時候，並不只拷貝所需要的物件，而是把整個 value 參照了起來。如果原字串比較大，即使不再使用，記憶體也不會釋放。

比如，一篇文章內容可能有幾兆，我們僅僅是需要其中的摘要資訊，也不得不維持整個的大物件。

有一些工作年限比較長的面試官，對 substring 還停留在 JDK6 的印象，但其實，Java 已經將這個 bug 給修改了。如果面試時遇到這個問題，保險起見，可以把這個改善過程答出來。

這對我們的借鑑意義是：如果你建立了比較大的物件，並基於這個物件生成了一些其他的資訊，這個時候，一定要記得去掉和這個大物件的參照關係。

集合大物件擴容

物件擴容，在 Java 中是司空見慣的現象，比如 StringBuilder、StringBuffer、HashMap，ArrayList 等。概括來講，Java 的集合，包括 List、Set、Queue、Map 等，其中的資料都不可控。在容量不足的時候，都會有擴容操作，擴容操作需要重新組織資料，所以都不是執行緒安全的。

我們先來看下 StringBuilder 的擴容程式碼：

void expandCapacity(int minimumCapacity) {
    int newCapacity = value.length * 2 + 2;
    if (newCapacity - minimumCapacity < 0)
        newCapacity = minimumCapacity;
    if (newCapacity < 0) {
        if (minimumCapacity < 0) // overflow 
            throw new OutOfMemoryError();
        newCapacity = Integer.MAX_VALUE;
    }
    value = Arrays.copyOf(value, newCapacity);
}

容量不夠的時候，會將記憶體翻倍，並使用 Arrays.copyOf 複製源資料。

下面是 HashMap 的擴容程式碼，擴容後大小也是翻倍。它的擴容動作就複雜得多，除了有負載因子的影響，它還需要把原來的資料重新進行雜湊，由於無法使用 native 的 Arrays.copy 方法，速度就會很慢。

void addEntry(int hash, K key, V value, int bucketIndex) {
    if ((size >= threshold) && (null != table[bucketIndex])) {
        resize(2 * table.length);
        hash = (null != key) ? hash(key) : 0;
        bucketIndex = indexFor(hash, table.length);
    }
    createEntry(hash, key, value, bucketIndex);
}

void resize(int newCapacity) {
    Entry[] oldTable = table;
    int oldCapacity = oldTable.length;
    if (oldCapacity == MAXIMUM_CAPACITY) {
        threshold = Integer.MAX_VALUE;
        return;
    }
    Entry[] newTable = new Entry[newCapacity];
    transfer(newTable, initHashSeedAsNeeded(newCapacity));
    table = newTable;
    threshold = (int) Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}

List 的程式碼大家可自行檢視，也是阻塞性的，擴容策略是原長度的 1.5 倍。

由於集合在程式碼中使用的頻率非常高，如果你知道具體的資料項上限，那麼不妨設定一個合理的初始化大小。比如，HashMap 需要 1024 個元素，需要 7 次擴容，會影響應用的效能。面試中會頻繁出現這個問題，你需要了解這些擴容操作對效能的影響。

但是要注意，像 HashMap 這種有負載因子的集合（0.75），初始化大小 = 需要的個數/負載因子+1，如果你不是很清楚底層的結構，那就不妨保持預設。

接下來，我將從資料的結構緯度和時間維度出發，講解一下應用層面的優化。

保持合適的物件粒度

給你分享一個實際案例：我們有一個並行量非常高的業務系統，需要頻繁使用到使用者的基本資料。

如下圖所示，由於使用者的基本資訊，都是存放在另外一個服務中，所以每次用到使用者的基本資訊，都需要有一次網路互動。更加讓人無法接受的是，即使是隻需要使用者的性別屬性，也需要把所有的使用者資訊查詢，拉取一遍。

為了加快資料的查詢速度，對資料進行了初步的快取，放入到了 Redis 中，查詢效能有了大的改善，但每次還是要查詢很多冗餘資料。

原始的 redis key 是這樣設計的：

type: string 
key: user_${userid} 
value: json

這樣的設計有兩個問題：

查詢其中某個欄位的值，需要把所有 json 資料查詢出來，並自行解析；

更新其中某個欄位的值，需要更新整個 json 串，代價較高。

針對這種大粒度 json 資訊，就可以採用打散的方式進行優化，使得每次更新和查詢，都有聚焦的目標。

接下來對 Redis 中的資料進行了以下設計，採用 hash 結構而不是 json 結構：

type: hash 
key: user_${userid} 
value: {sex:f, id:1223, age:23}

這樣，我們使用 hget 命令，或者 hmget 命令，就可以獲取到想要的資料，加快資訊流轉的速度。

Bitmap 把物件變小

除了以上操作，還能再進一步優化嗎？比如，我們系統中就頻繁用到了使用者的性別資料，用來發放一些禮品，推薦一些異性的好友，定時迴圈使用者做一些清理動作等；或者，存放一些使用者的狀態資訊，比如是否線上，是否簽到，最近是否傳送資訊等，從而統計一下活躍使用者等。那麼對是、否這兩個值的操作，就可以使用 Bitmap 這個結構進行壓縮。

這裡還有個高頻面試問題，那就是 Java 的 Boolean 佔用的是多少位？

在 Java 虛擬機器器規範裡，描述是：將 Boolean 型別對映成的是 1 和 0 兩個數位，它佔用的空間是和 int 相同的 32 位。即使有的虛擬機器器實現把 Boolean 對映到了 byte 型別上，它所佔用的空間，對於大量的、有規律的 Boolean 值來說，也是太大了。

如程式碼所示，通過判斷 int 中的每一位，它可以儲存 32 個 Boolean 值！

int a= 0b0001_0001_1111_1101_1001_0001_1111_1101;

Bitmap 就是使用 Bit 進行記錄的資料結構，裡面存放的資料不是 0 就是 1。還記得我們在之前《分散式快取系統必須要解決的四大問題》中提到的快取穿透嗎？就可以使用 Bitmap 避免，Java 中的相關結構類，就是 java.util.BitSet，BitSet 底層是使用 long 陣列實現的，所以它的最小容量是 64。

10 億的 Boolean 值，只需要 128MB 的記憶體，下面既是一個佔用了 256MB 的使用者性別的判斷邏輯，可以涵蓋長度為 10 億的 ID。

static BitSet missSet = new BitSet(010_000_000_000); 
static BitSet sexSet = new BitSet(010_000_000_000); 
String getSex(int userId) { 
    boolean notMiss = missSet.get(userId); 
    if (!notMiss) { 
        //lazy fetch 
        String lazySex = dao.getSex(userId); 
        missSet.set(userId, true); 
        sexSet.set(userId, "female".equals(lazySex)); 
    } 
    return sexSet.get(userId) ? "female" : "male"; 
}

這些資料，放在堆內記憶體中，還是過大了。幸運的是，Redis 也支援 Bitmap 結構，如果記憶體有壓力，我們可以把這個結構放到 Redis 中，判斷邏輯也是類似的。

再插一道面試演演算法題：給出一個 1GB 記憶體的機器，提供 60億 int 資料，如何快速判斷有哪些資料是重複的？

大家可以類比思考一下。Bitmap 是一個比較底層的結構，在它之上還有一個叫作布隆過濾器的結構（Bloom Filter），布隆過濾器可以判斷一個值不存在，或者可能存在。

如圖，它相比較 Bitmap，它多了一層 hash 演演算法。既然是 hash 演演算法，就會有衝突，所以有可能有多個值落在同一個 bit 上。它不像 HashMap一樣，使用連結串列或者紅黑樹來處理衝突，而是直接將這個hash槽重複使用。從這個特性我們能夠看出，布隆過濾器能夠明確表示一個值不在集合中，但無法判斷一個值確切的在集合中。

Guava 中有一個 BloomFilter 的類，可以方便地實現相關功能。

上面這種優化方式，本質上也是把大物件變成小物件的方式，在軟體設計中有很多類似的思路。比如像一篇新發布的文章，頻繁用到的是摘要資料，就不需要把整個文章內容都查詢出來；使用者的 feed 資訊，也只需要保證可見資訊的速度，而把完整資訊存放在速度較慢的大型儲存裡。

資料的冷熱分離

資料除了橫向的結構緯度，還有一個縱向的時間維度，對時間維度的優化，最有效的方式就是冷熱分離。

所謂熱資料，就是靠近使用者的，被頻繁使用的資料；而冷資料是那些存取頻率非常低，年代非常久遠的資料。

同一句複雜的 SQL，執行在幾千萬的資料表上，和執行在幾百萬的資料表上，前者的效果肯定是很差的。所以，雖然你的系統剛開始上線時速度很快，但隨著時間的推移，資料量的增加，就會漸漸變得很慢。

冷熱分離是把資料分成兩份，如下圖，一般都會保持一份全量資料，用來做一些耗時的統計操作。

由於冷熱分離在工作中經常遇到，所以面試官會頻繁問到資料冷熱分離的方案。下面簡單介紹三種：

資料雙寫

把對冷熱庫的插入、更新、刪除操作，全部放在一個統一的事務裡面。由於熱庫（比如 MySQL）和冷庫（比如 Hbase）的型別不同，這個事務大概率會是分散式事務。在專案初期，這種方式是可行的，但如果是改造一些遺留系統，分散式事務基本上是改不動的，我通常會把這種方案直接廢棄掉。

寫入 MQ 分發

通過 MQ 的釋出訂閱功能，在進行資料操作的時候，先不落庫，而是傳送到 MQ 中。單獨啟動消費程序，將 MQ 中的資料分別落到冷庫、熱庫中。使用這種方式改造的業務，邏輯非常清晰，結構也比較優雅。像訂單這種結構比較清晰、對順序性要求較低的系統，就可以採用 MQ 分發的方式。但如果你的資料庫實體量非常大，用這種方式就要考慮程式的複雜性了。

使用 Binlog 同步

針對 MySQL，就可以採用 Binlog 的方式進行同步，使用 Canal 元件，可持續獲取最新的 Binlog 資料，結合 MQ，可以將資料同步到其他的資料來源中。

思維發散

對於結果集的操作，我們可以再發散一下思維。可以將一個簡單冗餘的結果集，改造成複雜高效的資料結構。這個複雜的資料結構可以代理我們的請求，有效地轉移耗時操作。

比如，我們常用的資料庫索引，就是一種對資料的重新組織、加速。B+ tree 可以有效地減少資料庫與磁碟互動的次數，它通過類似 B+ tree 的資料結構，將最常用的資料進行索引，儲存在有限的儲存空間中。

還有就是，在 RPC 中常用的序列化。有的服務是採用的 SOAP 協定的 WebService，它是基於 XML 的一種協定，內容大傳輸慢，效率低下。現在的 Web 服務中，大多數是使用 json 資料進行互動的，json 的效率相比 SOAP 就更高一些。

另外，大家應該都聽過 google 的 protobuf，由於它是二進位制協定，而且對資料進行了壓縮，效能是非常優越的。protobuf 對資料壓縮後，大小隻有 json 的 1/10，xml 的 1/20，但是效能卻提高了 5-100 倍。

protobuf 的設計是值得借鑑的，它通過 tag|leng|value 三段對資料進行了非常緊湊的處理，解析和傳輸速度都特別快。

小結

最後總結一下本文的內容重點：

首先，我們看了比較老的 JDK 版本中，String 為了複用引起的內容洩漏問題，所以我們平常的編碼中，一定要注意大物件的回收，及時切斷與它的聯絡。

接下來，我們看了 Java 中集合的一些擴容操作，如果你知道確切的集合大小，就可以指定一個初始值，避免耗時的擴容操作。

針對大物件，我們有結構緯度的優化和時間維度的優化兩種方法：

從結構緯度來說，通過把物件切分成合適的粒度，可以把操作集中在小資料結構上，減少時間處理成本；通過把物件進行壓縮、轉換，或者提取熱點資料，就可以避免大物件的儲存和傳輸成本。

從時間緯度來說，就可以通過冷熱分離的手段，將常用的資料存放在高速裝置中，減少資料處理的集合，加快處理速度。

到現在為止，我們學習了緩衝、快取、物件池化、結果快取池、大物件處理等優化效能的手段，由於它們都加入了額外的中間層，會使得程式設計模型變得複雜。

到此這篇關於詳解處理Java中的大物件的方法的文章就介紹到這了,更多相關Java大物件內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！