Java 記憶體佔用深度研究：32 位元 JVM 物件佈局與資料結構選型實戰

功能正確、記憶體看似正常，卻在資料量暴增時記憶體暴衝？根因在於不瞭解 JVM 物件真實佔用。本文針對 32 位元 HotSpot JVM，實測推導物件佈局鐵律，指導資料結構選型避坑。

基礎型別與參考大小

long[1000] = 8,000 位元組 + 陣列物件頭；Object[] 即使全 null，每格 4 位元組參考空間照佔。

物件頭與對齊鐵律

• 物件頭：8 位元組（Mark Word + Class Pointer）。
• 參考：4 位元組（指向堆疊物件）。
• 8 位元組對齊：物件總大小必須為 8 的倍數，不足補齊。

實測推導公式

新物件大小 = 參考(4) + 物件頭(8) + 實例欄位大小總和 → 向上取 8 倍數
陣列大小   = 參考(4) + 物件頭(8) + length欄位(4) + 元素大小總和 → 向上取 8 倍數

經典案例對照

String 記憶體經濟學

• 物件固定開銷：char[] value、offset、count、hash → 24 位元組 + 參考 4 = 28 位元組起跳。
• 字元陣列獨立配置：char[length] 另佔 16 + 2×length 位元組。
• 常值池重用：String s = "abc" 僅佔 28 位元組參考；new String("abc") 強制新建物件+陣列，極度浪費。

實戰優化案例

百萬筆 Hashtable → 改 String[] + int[] 並排，記憶體驟降、排序 2 秒內、二分查找媲美 Hash。

避坑清單

1. 嚴禁大量使用包裝類型陣列（Byte[]、Integer[]）。
2. 大集合優先考慮基本型別陣列或專用庫（Trove, FastUtil）。
3. 字串建構器 StringBuilder 替代 +，減少中間物件。
4. 啟用 -XX:+UseCompressedOops（JDK 6u23+ 預設開啟），64 位元 JVM 參考壓縮為 4 位元組，緩解膨脹。