本文討論了如何在Java高并發(fā)環(huán)境中安全、原子地更新一個(gè)由final修改的concurenthashmap，以避免數(shù)據(jù)不一致或瞬時(shí)數(shù)據(jù)丟失。本文分析了直接清空和添加的風(fēng)險(xiǎn)，并提出了兩種主要策略：一種是增量更新和刪除舊鍵，但存在非原子問題;另一種是基于不可變映射和Atomicreference的原子替換方案，可以有效地保證閱讀操作的強(qiáng)烈一致性。同時(shí)，本文還討論了其他先進(jìn)的策略和實(shí)現(xiàn)考慮。1. 理解final Map并發(fā)更新挑戰(zhàn)

在Java中，當(dāng)一個(gè)集合(如Map)被final關(guān)鍵字修改時(shí)，意味著引用本身是不可變的，即不能指向另一個(gè)Map實(shí)例。但是，這并不意味著Map的內(nèi)容是不可變的。對(duì)于concurenthashmap等并發(fā)集合，其設(shè)計(jì)目標(biāo)是支持多線程和讀寫操作，但具體的全更新場(chǎng)景仍需謹(jǐn)慎處理。

考慮以下常見的更新邏輯：

private final Map> registeredEvents = new ConcurrentHashMap<>();

public void updateEvents(Map> newRegisteredEntries) {

if (MapUtils.isNotEmpty(newRegisteredEntries)) {

registeredEvents.clear(); // 問題點(diǎn)1：清空操作

registeredEvents.putAll(newRegisteredEntries); // 問題點(diǎn)2：填充操作

}

}

在高并發(fā)環(huán)境下，如果registeredevents用于實(shí)時(shí)數(shù)據(jù)轉(zhuǎn)換邏輯(比如每分鐘處理100萬事件)，clear()和putall()之間有一個(gè)短窗口期，那么Map是空的。在此期間，任何試圖讀取Map的線程都將獲得空數(shù)據(jù)，導(dǎo)致業(yè)務(wù)邏輯錯(cuò)誤或數(shù)據(jù)丟失，這是不可接受的。

2. 增量更新和刪除舊鍵策略及其局限性

為了避免Map在更新過程中出現(xiàn)完全空洞的瞬時(shí)狀態(tài)，一種改進(jìn)策略是先添加新項(xiàng)目，然后刪除舊項(xiàng)目。這可以確保Map至少在大多數(shù)更新時(shí)間包含一些有效數(shù)據(jù)。

立即學(xué)習(xí)“Java免費(fèi)學(xué)習(xí)筆記(深入);

private final Map> registeredEvents = new ConcurrentHashMap<>();

public void updateEventsSafely(Map> newRegisteredEntries) {

if (MapUtils.isNotEmpty(newRegisteredEntries)) {

// 1. 記錄舊鍵，用于后續(xù)刪除不再存在的條目

Set oldKeys = new HashSet<>(registeredEvents.keySet());

// 2. 在Map中添加新的條目，現(xiàn)有鍵的值將被覆蓋

registeredEvents.putAll(newRegisteredEntries);

// 3. 找出新數(shù)據(jù)中不再存在的舊鍵

oldKeys.removeAll(newRegisteredEntries.keySet());

// 4. 移除不再需要的舊鍵

oldKeys.forEach(registeredEvents::remove);

}

}

優(yōu)點(diǎn)：

避免Map在更新過程中完全為空，降低數(shù)據(jù)缺失的風(fēng)險(xiǎn)。

使用ConcurrentHashMap的并發(fā)寫入特性。

局限性：

非原子性： 整個(gè)更新過程(添加和刪除)不是一個(gè)原子操作。在執(zhí)行過程中，Map可能處于混合狀態(tài)，包括舊數(shù)據(jù)、新數(shù)據(jù)和可能尚未刪除的過期數(shù)據(jù)。如果業(yè)務(wù)邏輯要求所有相關(guān)鍵同時(shí)生效或失效，則該非原子性可能導(dǎo)致不一致。

并寫入問題： 如果多個(gè)線程同時(shí)調(diào)用updateventssafely，則可能會(huì)引入競(jìng)態(tài)條件。例如，一個(gè)線程正在計(jì)算oldkeys并準(zhǔn)備移除，另一個(gè)線程添加了新的條目，這可能導(dǎo)致移除操作或中間狀態(tài)不正確。

潛在垃圾： 在putall之后，但在remove之前，Map可能暫時(shí)包含比最終狀態(tài)更多的元素。

3. 推薦的原子性更新策略：使用不可變映射和引用原子

當(dāng)對(duì)數(shù)據(jù)一致性有嚴(yán)格的要求時(shí)，特別是當(dāng)整個(gè)應(yīng)用程序更新作為原子操作時(shí)，最佳實(shí)踐是采用“不可變映射”和“原子引用”相結(jié)合的策略。該方法的核心思想是創(chuàng)建一個(gè)新的、完整的應(yīng)用程序副本，填寫所有最新數(shù)據(jù)，然后通過原子操作引用新的應(yīng)用程序。

要實(shí)現(xiàn)這一點(diǎn)，原來的final 引用Map需要改為Atomicreferencerencerence，因?yàn)閒inal關(guān)鍵字會(huì)阻止我們重新分配Map的引用。

import java.util.Collections;

import java.util.HashMap;

import java.util.Map;

import java.util.Set;

import java.util.concurrent.ConcurrentHashMap;

import java.util.concurrent.atomic.AtomicReference;

public class EventMappingManager {

// 使用Atomicreference原子管理Map的引用

private final AtomicReference>> registeredEventsRef =

new AtomicReference<>(Collections.emptyMap()); // 初始值可以是空的或預(yù)設(shè)的

// 獲得當(dāng)前活動(dòng)的事件映射

public Map> getRegisteredEvents() {

return registeredEventsRef.get(); // 閱讀操作直接獲得當(dāng)前引用，無需鎖定，性能高

}

// 事件映射的原子更新

public void updateEventsAtomically(Map> newRegisteredEntries) {

// 1. 構(gòu)建包含所有最新數(shù)據(jù)的新型不可變Map

// 注意：如果newRegistererentries是可變的，那么HashMap就用作構(gòu)建器，需要深度復(fù)制。

Map> newMap = new HashMap<>(newRegisteredEntries);

// 如果希望Map本身不能修改，可以包裝成Collections，.unmodifiableMap

Map> immutableNewMap = Collections.unmodifiableMap(newMap);

// 2. 使用CAS操作原子更新引用

// oldMap 它是目前的舊引用。如果同時(shí)更新多個(gè)線程，只有一個(gè)能成功

registeredEventsRef.set(immutableNewMap);

// 另一種更嚴(yán)格的更新方法是使用compareandset，但是set通常足以完全替換場(chǎng)景

// 除非你需要根據(jù)舊值計(jì)算新值并確保原子性

// registeredEventsRef.compareAndSet(oldMap, immutableNewMap);

}

// 示例用法

public static void main(String[] args) {

EventMappingManager manager = new EventMappingManager();

// 首次加載

Map> initialData = new ConcurrentHashMap<>();

initialData.put("eventA", Collections.singleton(new EventMapping("type1", "action1")));

manager.updateEventsAtomically(initialData);

System.out.println("Initial Map: " + manager.getRegisteredEvents());

// 模擬高并發(fā)讀操作

new Thread(() -> {

for (int i = 0; i < 5; i++) {

try {

Thread.sleep(100);

} catch (InterruptedException e) {

Thread.currentThread().interrupt();

}

System.out.println("Reader 1: " + manager.getRegisteredEvents().get("eventA"));

}

}).start();

// 模擬更新操作

new Thread(() -> {

try {

Thread.sleep(250); // 稍等片刻，讓讀取線程先運(yùn)行

} catch (InterruptedException e) {

Thread.currentThread().interrupt();

}

Map> updatedData = new ConcurrentHashMap<>();

updatedData.put("eventA", Collections.singleton(new EventMapping("type2", "action2")));

updatedData.put("eventB", Collections.singleton(new EventMapping("type3", "action3")));

manager.updateEventsAtomically(updatedData);

System.out.println("Map Updated. New Map: " + manager.getRegisteredEvents());

}).start();

}

static class EventMapping {

String type;

String action;

public EventMapping(String type, String action) {

this.type = type;

this.action = action;

}

@Override

public String toString() {

return "{" + type + "," + action + "}";

}

}

}

該策略的優(yōu)勢(shì)：

強(qiáng)一致性： 在任何時(shí)候讀取registeredeventsreff.get()會(huì)得到完整一致的Map快照，不會(huì)部分更新或空。

無鎖閱讀操作： 讀操作(getRegisteredEvents()只需獲得Atomicreference的當(dāng)前值，無需任何鎖，性能極高。

寫入原子性： set()操作本身是原子的，保證Map引用的切換瞬間完成。

簡化邏輯： 更新邏輯清晰，不需要關(guān)心內(nèi)部鍵的添加和刪除細(xì)節(jié)。

注意事項(xiàng)：

內(nèi)存開銷： 每次更新都會(huì)創(chuàng)建一個(gè)新的Map實(shí)例。如果更新頻率高，Map很大，可能會(huì)導(dǎo)致短期內(nèi)存和GC壓力。但是，由于舊的Map不再被引用，最終會(huì)被垃圾回收。

數(shù)據(jù)拷貝： new HashMap(newRegisteredEntries)將進(jìn)行淺層復(fù)制。如果EventMaping對(duì)象本身是可變的，并且不希望舊Map引用中的EventMaping對(duì)象被修改，則需要進(jìn)行深層復(fù)制。

4. 其它高級(jí)策略和考慮

對(duì)于更復(fù)雜的并發(fā)場(chǎng)景或特定需求，可能需要考慮以下策略：

版本控制或快照： 如果Map中的值之間存在復(fù)雜的關(guān)聯(lián)，并且需要確保一組相關(guān)更新作為邏輯單元生效，則可以將版本號(hào)或快照機(jī)制引入Map。每次更新生成一個(gè)新版本，讀取操作可以指定讀取哪個(gè)版本的數(shù)據(jù)。這通常需要更復(fù)雜的自定義數(shù)據(jù)結(jié)構(gòu)或事務(wù)管理。

自定義并發(fā)數(shù)據(jù)結(jié)構(gòu)： 對(duì)于極端性能要求或非常特殊的并發(fā)語義，可以考慮構(gòu)建自定義和高度優(yōu)化的并發(fā)數(shù)據(jù)結(jié)構(gòu)，但這通常只在標(biāo)準(zhǔn)數(shù)據(jù)庫不能滿足需求時(shí)考慮。

需求分析： 在選擇更新策略之前，必須清楚地定義系統(tǒng)的并發(fā)需求：

讀寫頻率： 讀寫操作的相對(duì)頻率。

一致性模型： 需要強(qiáng)一致性(讀取最新數(shù)據(jù))或最終一致性(數(shù)據(jù)最終會(huì)達(dá)成一致性)。

原子粒度： 是單鍵值對(duì)的原子性，還是整個(gè)Map的全更新原子性。

總結(jié)

安全更新finalal ConcurrentHashMap(或其他共享Map)在高并發(fā)應(yīng)用中非常重要。直接clear()然后putall()操作將引入數(shù)據(jù)不一致的窗口期。增量更新(先添加后刪除舊鍵)可以緩解一些問題，但仍存在非原子和并發(fā)寫入的挑戰(zhàn)。

AtomicReferencencence用于需要強(qiáng)一致性和完全更新的場(chǎng)景原子地替換不可變Map實(shí)例這是推薦的最佳實(shí)踐。該方法提供了一個(gè)清晰、高性能、安全的線程解決方案，以確保在任何時(shí)候都能獲得完整和一致的數(shù)據(jù)視圖。在實(shí)際應(yīng)用中，應(yīng)根據(jù)具體的業(yè)務(wù)需求、性能考慮和內(nèi)存限制來選擇最合適的策略。

以上是Java中finalal的安全更新 更多關(guān)于圖靈教育的其他相關(guān)文章。