Java 對象大小：通過分析估計、測量和驗證

本篇文章，我們將學習如何估計所有可能的 Java 對象或原始數據類型（?Primitive?）。這些知識非常重要，尤其是 對于生產應用程序。你可能認為現(xiàn)在大多數服務器都有足夠的內存來滿足所有可能的應用程序需求。在某種程度而言你是對的——硬件，它相對于一個開發(fā)人員的薪水算是比較便宜。但是，仍然很容易滿足非常消耗性的情況，例如：

• 緩存特別是長字符串。
• 結構有一個大數目的記錄（例如，具有節(jié)點樹從構建龐大的XML文件）。
• 從數據庫復制數據的任何結構。

在下一步中，我們開始估計從原始結構到更復雜結構的 Java 對象。

Java 原始數據類型

Java ?Primitives ?的大小是眾所周知的，并且從包裝盒中提供：

32 位和 64 位系統(tǒng)的最小內存字

32 位和 64 位內存字的最小大小分別為 8 和 16 字節(jié)。任何較小的長度都按 8 舍入。在計算過程中，我們將考慮這兩種情況。

由于內存（字節(jié)大?。┙Y構的性質，任何內存都是 8 的倍數，如果不是系統(tǒng)會自動添加額外的字節(jié)（但 32/64 系統(tǒng)的最小大小仍然是 8 和 16 字節(jié)）

Java對象

Java 對象內部沒有字段，根據規(guī)范，它只有稱為header 的元數據。Header 包含兩部分：標記詞（?Mark Word?） 和 類指針（?class pointer?）。 

以及它在 Java Memory 中的樣子： 

Java 原始包裝器

在 Java 中，除了基元和引用（最后一個是隱藏的）之外，一切都是對象。所以所有的包裝類只是包裝相應的原始類型。所以包裝器大小一般=對象頭對象+內部原始字段大小+內存間隙。所有原始包裝器的大小如下表所示：

Java數組

Java數組是非常相似的對象-他們也有不同的原始和對象值。該數組包含headers、數組長度及其單元格（到基元）或對其單元格的引用（對于對象）。為了方便大家清楚明白，我們繪制一個原始整數和大整數（包裝器）的數組。

基元數組（在我們的例子中是整數）

對象數組（在我們的例子中是位整數）

因此，你可以看到原始數組和對象數組之間的主要區(qū)別——帶有引用的附加層。在這個例子中，大多數內存丟失的原因是使用一個整數包裝器，它增加了 12 個額外的字節(jié)（比原始數據多 3 倍?。?/p>

Java類

現(xiàn)在我們知道如何計算 Java Object、Java Primitive 和 Java Primitive Wrapper 和 Arrays。Java 中的任何類都不過是一個混合了所有提到的組件的對象：

• 標頭（32/64 位操作系統(tǒng)的 8 或 12 字節(jié)）。
• 原始（類型字節(jié)取決于原始類型）。
• 對象/類/數組（4 字節(jié)參考大小）。

Java字符串

Java string 它是類的一個很好的例子，所以除了 header 和 hash 之外，它還封裝了 char 數組，所以對于長度為 500 的長字符串，我們有：

但是我們要考慮到Java String 類有不同的實現(xiàn)，但一般來說，主要大小由char 數組保存。

如何以編程方式計算

使用運行時檢查大小 freeMemory

最簡單但不可靠的方法是比較內存初始化前后總內存和空閑內存的差異：

long beforeUsedMem=Runtime.getRuntime().totalMemory()-Runtime.getRuntime().freeMemory();
Object[] myObjArray = new Object[100_000];
long afterUsedMem=Runtime.getRuntime().totalMemory()-Runtime.getRuntime().freeMemory();

使用 Jol 庫

最好的方法是使用Aleksey Shipilev 編寫的Jol 庫。這個解決方案會讓您驚喜地發(fā)現(xiàn)我們可以輕松地調查任何對象/原語/數組。為此，您需要添加下一個 Maven 依賴項：

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.16</version>
</dependency>

并提供給 ClassLayout.parseInstance 你想要估計的任何內容：

int primitive = 3; // put here any class/object/primitive/array etc
System.out.println(VM.current().details());
System.out.println(ClassLayout.parseInstance(primitive).toPrintable());

作為輸出，你將看到：

純文本1

# Running 64-bit HotSpot VM.
# Using compressed oop with 0-bit shift.
# Using compressed klass with 3-bit shift.
# Objects are 8 bytes aligned.
# Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

java.lang.Integer object internals:
OFF  SZ   TYPE DESCRIPTION               VALUE
  0   8        (object header: mark)     0x0000000000000001 (non-biasable; age: 0)
  8   4        (object header: class)    0x200021de
 12   4    int Integer.value             3
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

使用探查器

作為一種選擇，怒可以使用分析器（?JProfiler?、?VM Visualizer?、?JConsole? 等）來觀察此結構或其他結構消耗了多少內存。但是這個解決方案是關于分析內存而不是對象結構。在下一段中，我們將使用 JProfiler 來確認我們的計算是正確的。

制作數據庫緩存類并計算其大小

作為一個現(xiàn)實的例子，我們創(chuàng)建類來表示某個數據庫表中的數據，其中包含 5 列和 1.000.000 條記錄。 

public class UserCache{
    public static void main(String[] args){
        User [] cachedUsers = new User[1_000_000];
        while(true){}
    }
    private static class User{
        Long id;
        String name; //assume 36 characters long
        Integer salary;
        Double account;
        Boolean isActive;
    }
}

所以現(xiàn)在我們創(chuàng)建了 100 萬用戶，對嗎？好吧，它在 User 類中的內容并不重要——我們剛剛創(chuàng)建了 1M 個引用。內存使用：1M * 4 字節(jié) = 4000 KB 或 4MB。甚至沒有開始，但支付了 4MB。

為 64 位系統(tǒng)分析 Java 內存

為了確認我們的計算，我們執(zhí)行我們的代碼并將?JProfile?附加到它。作為替代方案，你可以使用任何其他分析器，例如?VisualVM?（它是免費的）。。

提示：當你分析應用程序時，你可以不時運行 GC 以清理未使用的對象。所以分析的結果：我們有User[]4M 記錄的參考點，大小為 4000KB。當我們分析：

作為下一步，我們初始化對象并將它們添加到我們的數組中（名稱是唯一的 UUID 36 長度大小）：

for(int i = 0;i<1_000_000;i++){
    User tempUser = new User();
    tempUser.id = (long)i;
    tempUser.name = UUID.randomUUID().toString();
    tempUser.salary = (int)i;
    tempUser.account = (double) i;
    tempUser.isActive = Boolean.FALSE;
    cachedUsers[i] = tempUser;
}

現(xiàn)在讓我們分析這個應用程序并確認我們的期望。你可能會提到某些值不精確，例如，字符串的大小為 24.224 而不是 24.000，但我們計算了所有字符串，包括內部 JVM 字符串以及與Boolean.FALSE對象相關的相同內容（估計為 16 字節(jié)，但在配置文件中，它顯然Boolean.TRUE是32，因為也是JVM 內部使用）。

對于 1M 記錄，我們花費了 212MB，它只有 5 個字段，并且所有字符串長度都受 36 個字符的限制。正如你所看到的，對象非常貪婪。讓我們改進 User 對象并用原語替換所有對象（字符串除外）。

僅僅通過將字段更改為基元，我們就節(jié)省了 56MB（大約 25% 的已用內存）。但我們還通過刪除用戶和原語之間的額外引用來提高性能。 

如何減少內存消耗

讓我們列出一些簡單的方法來節(jié)省內存消耗：

壓縮的 OOP

對于 64 位系統(tǒng)，你可以使用壓縮的 oop 參數執(zhí)行 JVM。這是一個相當大的主題，

將數據從子對象提取到父對象

如果設計允許將字段從子類移動到父類，則可能會節(jié)省一些內存：

帶有原語的集合

從前面的例子中，我們看到了原語包裝器是如何浪費大量內存的。原始數組不像 ?Java Collection? 接口那樣用戶友好。但是還有一個替代方案：?Trove?、?FastUtils?、?Eclipse Collection? 等。讓我們比較 ?來自?Trove 庫?的?simpleArrayList<Double>?和?TDoubleArrayListd內存使用情況。

TDoubleArrayList arrayList = new TDoubleArrayList(1_000_000);
List<Double> doubles = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
  arrayList.add(i);
  doubles.add((double) i);
}

通常，關鍵區(qū)別隱藏在 ?Double Primitive Wrapper? 對象中，而不是 ?ArrayList ?或 ?TDoubleArrayList ?結構中。因此簡化 1M 記錄的差異：

?JProfiler ?證實了這一點：

因此，只需更改集合，我們就可以輕松地將消耗減少 3 倍。

本文有關 Java 內存結構的基本內容就介紹到此結束了，感謝各位的閱讀。