無鎖編程實戰：不可變類替代讀寫鎖，大幅提升高併發讀場景效能

無鎖編程實戰：不可變類替代讀寫鎖，大幅提升高併發讀場景效能

面對「讀極其頻繁、寫極少」的配置熱點場景，傳統 ReentrantReadWriteLock 仍有鎖開銷。本文通過基準測試對比，證明不可變物件 + 原子引用替換可消除讀端鎖，顯著提升吞吐。

場景描述

• 線程 A：每秒億級訂單處理，需讀取用戶折扣配置（會員價、活動價）計算價格。
• 線程 B：偶爾更新配置（如每秒 1 次）。
• 需求：讀過程中配置必須一致（不可出現「髒讀」：部分新舊混合）。

方案一：ReadWriteLock（基準）

// 可變配置類
class AccountConfig {
    private double membershipDiscount;
    private double specialEventDiscount;
    // getter/setter...
}

// 讀線程
lock.readLock().lock();
AccountConfig cfg = map.get(user);
double price = orderPrice * (1 - cfg.getMembershipDiscount()) * (1 - cfg.getSpecialEventDiscount());
lock.readLock().unlock();

// 寫線程
lock.writeLock().lock();
cfg.setMembershipDiscount(newVal);
lock.writeLock().unlock();

方案二：不可變類 + ConcurrentHashMap 原子替換

// 不可變配置類
final class ImmutableAccountConfig {
    private final double membershipDiscount;
    private final double specialEventDiscount;
    public ImmutableAccountConfig(double m, double s) { this.membershipDiscount = m; this.specialEventDiscount = s; }
    // 僅 getter，無 setter
}

// 讀線程：零鎖！
ImmutableAccountConfig cfg = map.get(user);
double price = orderPrice * (1 - cfg.getMembershipDiscount()) * (1 - cfg.getSpecialEventDiscount());

// 寫線程：構建新物件，原子 put 替換
ImmutableAccountConfig old = map.get("user1");
ImmutableAccountConfig fresh = new ImmutableAccountConfig(newDiscount, old.getSpecialEventDiscount());
map.put("user1", fresh); // ConcurrentHashMap.put 為原子操作

基準測試結果（1 億次讀，1 秒 1 寫）

ReadWriteLock: 5,289,501,171 ns  (~5.29 秒)
Immutable    : 3,599,621,120 ns  (~3.60 秒)
提升約 32%

雖未達數量級差距，但在高併發讀場景下，消除鎖爭用帶來的延遲抖動降低更具價值。

設計層面優勢

• 防呆： 讀端無需記得加鎖，不可變類天然防止「忘記加讀鎖」導致的髒讀。
• 封裝： 配置物件不可被任意修改，僅通過受控的更新路徑變更。
• 快照隔離： 讀線程看到的要么是完整舊配置，要么是完整新配置，不存在中間態。

多寫者場景注意

若有多個寫線程，仍需對「構建新物件 + put」加寫鎖（或用 computeIfPresent 原子更新），否則會出現更新丟失。讀線程依然無鎖。

Google Guava 不可變集合

若配置為 Map/集合，推薦 ImmutableMap/ImmutableList：

ImmutableMap<String, Double> cfg = ImmutableMap.<String, Double>builder()
    .put("membership", 0.02).put("event", 0.05).build();

// 更新：複製到可變 Map，修改，再建新 ImmutableMap
Map<String, Double> tmp = Maps.newHashMap(cfg);
tmp.put("membership", 0.03);
ImmutableMap<String, Double> newCfg = ImmutableMap.copyOf(tmp);

適用性判斷

不可變類不是銀彈，但在「讀多寫少、配置類資料」這類經典場景中，是比鎖更優雅、更高效的選擇。

原創文章，轉載請註明：https://www.cnblogs.com/Binhua-Liu/p/5573444.html