Java 內存優化與高效編程實戰清單：從陋習到最佳實踐

「Java 佔內存」多源於編碼陋習而非語言本身。本文歸納 9 大高頻內存殺手與對應最佳實踐，從對象創建、集合使用、引用管理、池化技術、資源釋放五個維度，給出可直接落地的優化清單。

一、包裝類對象濫用：緩存池與值傳遞

陋習

ps.setBoolean("flag", new Boolean(true));      // 每次新建對象
ps.setInt("id", new Integer(100));             // 每次新建對象
List list = new ArrayList<>();
for (int i = 0; i < 10000; i++) list.add(new Integer(i)); // 10000 個 Integer 對象

最佳實踐

• Boolean：僅兩個實例 `Boolean.TRUE`/`FALSE`，用 `Boolean.valueOf(boolean)` 獲取。
• Integer/Long/Short/Byte：JDK 緩存 `-128 ~ 127` (可配 `-XX:AutoBoxCacheMax`)，用 `Integer.valueOf(int)` 替換 `new Integer()`。
• 基本類型集合：用 Eclipse Collections / FastUtil / Goldman Sachs Collections 的 `IntList`/`LongList` 等原始類型集合，避免裝箱開銷與對象頭內存 (16 字節/對象)。
• ORM/框架層：MyBatis/JPA/Hibernate 內部已優化，業務代碼勿手動包裝。

二、字符串拼接濫用：StringBuilder/StringBuffer

陋習

String sql = "SELECT * FROM t WHERE ";
for (String col : cols) {
    sql += col + " = ? AND "; // 每次拼接產生新 String + StringBuilder 臨時對象
}

最佳實踐

• 循環/多次拼接 → `StringBuilder` (非線程安全、高性能) 或 `StringBuffer` (線程安全)。
• Java 9+ `String.join()`、`StringJoiner`、編譯器優化 `invokedynamic` (JEP 280) 已自動優化簡單拼接，但複雜邏輯仍需顯式 `StringBuilder`。
• SQL 構建用專用庫 (jOOQ、MyBatis SQL Builder、QueryDSL) 而非手工拼接。

三、緩存無界增長：引入淘汰策略與容量上限

陋習

Map userCache = new HashMap<>(); // 無限增長，最終 OOM
userCache.put(key, value); // 從不清理

最佳實踐

• 用成熟緩存框架：**Caffeine** (本地、高性能、W-TinyLFU)、**Ehcache 3.x**、**Redis** (分布式)。
• 配置核心參數：`maximumSize`、`expireAfterWrite`/`expireAfterAccess`、`refreshAfterWrite`、弱鍵/弱值引用。
• 手寫簡易 LRU：`LinkedHashMap(16, 0.75f, true) { protected boolean removeEldestEntry(Eldest) { return size() > MAX_SIZE; } }`。
• 緩存穿透/擊穿/雪崩防護：佈隆過濾器、互斥鎖重建、隨機過期時間、多級緩存。

四、類層次過深與方法調用鏈過長：棧幀與內聯開銷

• 繼承層次超過 3-4 層 → 組合優於繼承，介面默認方法替代部分需求。
• 調用鏈過長 (A→B→C→D→E) → 內聯優化有深度限制 (`-XX:MaxInlineLevel=9`)，熱點方法體積過大 (`-XX:MaxInlineSize=35`) 導致不內聯，增加棧幀開銷與逃逸分析難度。
• 扁平化設計，核心熱點路徑代碼內聚，減少委託跳轉。

五、變量作用域過大：延遲對象死亡

陋習

public void process() {
    List hugeList = loadHugeData(); // 方法開頭創建
    // 50 行其他邏輯...
    use(hugeList); // 最後才用
    // 方法結束 hugeList 才不可達
}

最佳實踐

• 就近聲明、就近使用：在首次使用前聲明，使用完立即賦 `null` (對長方法有效，短方法編譯器自動優化)。
• 拆分長方法：提取為私有方法，變量生命週期隨棧幀自然結束。
• 循環內大對象 → 循環外復用 / 作用域縮小到循環體內。

六、static 字段濫用：類級內存洩漏

陋習

public class Config {
    public static final Map CACHE = new HashMap<>(); // 永不釋放
    public static List HUGE_LIST = loadHuge(); // 類加載即常駐
}

最佳實踐

• 常量用 `final` + 不可變對象 (集合用 `Collections.unmodifiableMap`/Guava `ImmutableMap`)。
• 可變狀態**嚴禁** `static`，改用單例 Bean (Spring 管理生命週期)、緩存框架、ThreadLocal (需手動 `remove()`)。
• 類加載器卸載條件嚴苛，`static` 字段引用的對象圖極難回收。

七、高頻對象無池化：對象池與線程池

適用場景

• 數據庫連接、HTTP 客戶端、線程、大緩衝區 (ByteBuffer)、解析器 (JSON/XML)、加密對象、資源昂貴且可復用對象。

實現選擇

• 通用對象池：Apache Commons Pool 2 (HikariCP、Druid、Tomcat JDBC Pool 底層)。
• 線程池：`ThreadPoolExecutor` / `Executors` / HikariCP 內部池 / Spring `TaskExecutor`。
• ByteBuffer 池：Netty `PooledByteBufAllocator` / JDK `ByteBuffer.allocateDirect` 池化 (`-XX:+UsePooledDirectBuffers`)。

警惕

• 池大小需壓測調優，過大反增 GC 壓力、鎖競爭。
• 對象重置邏輯 (`reset()`) 必須徹底，避免臟數據洩漏。
• 無狀態/輕量對象 (如 DTO、VO) **無需池化**，逃逸分析+標量替換更優。

八、資源未及時關閉：try-with-resources 強制釋放

陋習

Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);
// 異常拋出時 conn/stmt/rs 全洩漏

最佳實踐

• **所有實現 `AutoCloseable` 的資源** 必須用 `try-with-resources` (Java 7+)：

try (Connection conn = dataSource.getConnection();
     Statement stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery(sql)) {
    // 正常或異常退出均自動關閉，逆序關閉，異常抑制機制保證釋放
}

• 自定義資源類實現 `AutoCloseable`，配合 `Cleaner` (Java 9+) 兜底。
• 連接池借還連接 (`borrow`/`release`) 同理，確保 `finally` 歸還。

九、其他高頻優化微操

總結：內存優化心法

1. 減少分配：基本類型、不可變對象、逃逸分析、對象池、預估容量。
2. 縮短壽命：就近聲明、方法拆分、作用域最小化、try-with-resources。
3. 消除洩漏：靜態集合清理、監聽器移除、ThreadLocal remove、緩存淘汰、連接歸還。
4. 監控驗證：JFR/JMC、GC 日誌、MAT、Arthas、Prometheus + Grafana 告警。

優化非一蹴而就，而是**編碼習慣→代碼評審→壓測驗證→監控迭代**的持續過程。從今天的提交開始，拒絕 `new Integer()`、拒絕循環 `+=`、拒絕無界 `HashMap`，讓 JVM 內存曲線平穩如絲。