Metoda computeIfAbsent klasy ConcurrentHashMap zapewnia atomowe, bezpieczne dla wątków obliczenie wartości, wykorzystując precyzyjne blokowanie na poziomie koszyka haszującego, a nie blokując całej tabeli. Krytyczne niebezpieczeństwo reentrantności powstaje, gdy mappingFunction dostarczona do tej metody próbuje rekurencyjnie uzyskać dostęp do tego samego klucza w tej samej instancji mapy podczas jej wykonania, tworząc potencjalną okrężną zależność.
W Java 8 dostęp do rekurencyjny powodował deadlock, ponieważ implementacja blokowała konkretny koszyk haszujący podczas obliczeń, a rekurencyjne wywołanie próbowało uzyskać ten sam blokadę już zatrzymaną przez aktualny wątek. Od Java 9 implementacja wykrywa tę rekurencję, wstawiając zarezerwowany węzeł ReservationNode do koszyka podczas obliczeń, oznaczając go jako "w trakcie". Jeśli ten sam wątek natrafi na ten ReservationNode podczas przeszukiwania dla tego samego klucza, metoda zgłasza IllegalStateException z komunikatem "Rekurencyjna aktualizacja", a nie deadlocka, zapewniając natychmiastową informację zwrotną na temat nieprawidłowej rekurencji.
Ten mechanizm wspomagania szybkiej reakcji zapobiega głodzeniu wątków i problemom z żywotnością w ramach wspólnej puli ForkJoinPool i innych kontekstów wykonawczych, w których deadlocki byłyby katastrofalne. Wymaga jednak, aby programiści starannie strukturyzowali swoją logikę obliczeniową, aby uniknąć okrężnych zależności między kluczami, co często wymaga wyraźnego wykrywania cykli w warstwie domeny.
Spotkaliśmy się z tym niebezpieczeństwem w silniku ustalania cen o wysokiej wydajności, który buforował obliczenia pochodnych dla instrumentów finansowych, aby uniknąć zbędnych symulacji Monte Carlo. Bufor wykorzystywał ConcurrentHashMap<String, CompletableFuture<BigDecimal>> z computeIfAbsent, aby zapewnić, że identyczne żądania wyceny opcji były deduplikowane i obliczane dokładnie raz na każdy sygnał rynkowy. Ten wzór jest powszechny w scenariuszach asynchronicznego ładowania danych, gdzie kosztowne obliczenia muszą być dzielone pomiędzy wiele równoległych żądań.
Problem objawił się podczas obliczania skomplikowanych pochodnych, które przypadkowo odnosiły się do innych pochodnych w tej samej pamięci podręcznej z powodu błędu w modelowaniu danych. Konkretnie, wzór wyceny dla Instrumentu A odnosił się do Instrumentu B jako podstawowego, podczas gdy wzór Instrumentu B niespodziewanie odnosił się ponownie do Instrumentu A, tworząc okrężną zależność. To spowodowało, że wywołanie computeIfAbsent dla A wywołało inne wywołanie computeIfAbsent dla A w tym samym wątku podczas fazy inicjalizacji wartości.
Nasze pierwsze rozważane rozwiązanie polegało na owinięciu dostępu do bufora w grube bloki synchronized, aby zapobiec jakiejkolwiek możliwości jednoczesnej modyfikacji podczas obliczeń. Chociaż podejście to wyeliminowałoby ryzyko deadlocka, zserializowałoby wszystkie obliczenia wyceny w całej mapie, skutkując tym, że wydajność spadłaby do wydajności jedno-wątkowej HashMap i zniszczyło wymagane charakterystyki wydajnościowe dla handlu w czasie rzeczywistym.
Drugie podejście polegało na wykorzystaniu putIfAbsent z wcześniej obliczonymi instancjami CompletableFuture, tworzonymi za pomocą supplyAsync() przed operacją na mapie. To pozwoliłoby uniknąć trzymania blokad podczas obliczeń, ale z zapałem inicjowałoby kosztowne obliczenia wyceny, nawet gdy klucz był już obecny w pamięci podręcznej, marnując znaczne zasoby CPU na zbędne obliczenia i podważając sens buforowania.
Nasze trzecie rozwiązanie wprowadziło wyraźne wykrywanie cykli, utrzymując ThreadLocal<Set<String>> zawierające "klucze obecnie obliczane" w stosie wywołań bieżącego wątku. Przed rozpoczęciem jakiejkolwiek operacji computeIfAbsent system sprawdzałby ten zestaw dla docelowego klucza, zgłaszając DomainException dla okrężnych odniesień przed dotarciem do warstwy mapy. To zachowało bezblokową równoległość ConcurrentHashMap, jednocześnie dostarczając znaczącego kontekstu związanego z biznesem na temat nieprawidłowych hierarchii instrumentów.
Wybraliśmy trzecie rozwiązanie, ponieważ addressowało przyczynę – nieprawidłowe okrężne modele finansowe – a nie tylko maskowało objawy, jednocześnie w pełni zachowując charakterystyki wydajnościowe współbieżności ConcurrentHashMap. Wyraźna walidacja zapewniła wyraźne ścieżki audytu pokazujące, które konkretne instrumenty tworzyły nieprawidłowe zależności okrężne, umożliwiając zespołowi danych wyeliminowanie błędów źródłowych danych, a nie tylko unikanie awarii.
Implementacja wyeliminowała produkcyjne awarie IllegalStateException i zmniejszyła zbędne obliczenia wyceny o około 40%, jednocześnie utrzymując wymagania dotyczące latencji poniżej milisekund dla platformy handlowej. Wyraźne wykrywanie cykli poprawiło również jakość danych, wymuszając korektę błędnych hierarchii instrumentów u źródła, a nie cicho obsługując je w kodzie.
Dlaczego ConcurrentHashMap odrzuca puste klucze i wartości, podczas gdy HashMap je dopuszcza?
ConcurrentHashMap używa null jako wewnętrznej wartości sentinela w swoich jednoczesnych operacjach atomowych, aby odróżnić "klucz nieobecny" od "obliczeń w toku". Metody takie jak computeIfAbsent i merge polegają na tym sentinelu, aby jednoznacznie wskazać nieobecność podczas atomowych aktualizacji bez potrzeby dodatkowych wyszukiwań, które mogłyby stworzyć warunki wyścigu. Ponieważ metoda get zwraca null dla zarówno brakujących kluczy, jak i kluczy mapujących na null, dopuszczenie wartości null uniemożliwiłoby określenie, czy klucz rzeczywiście istnieje w mapie podczas jednoczesnych modyfikacji, naruszając gwarancje atomowości operacji złożonych.
Jak blokowanie na poziomie koszyka w Java 8+ różni się od segmentowej współbieżności w Java 7?
Java 7 wykorzystywała stałą tablicę 16 segmentów, z których każdy był chroniony przez niezależny ReentrantLock, co sztucznie ograniczało maksymalną współbieżność zapisu do 16 wątków, niezależnie od dostępnego sprzętu. Java 8+ zlikwidowała tę segmentację na rzecz precyzyjnego blokowania na poziomie poszczególnych koszyków haszujących, wykorzystując bloki synchronized na pierwszym węźle każdej wiadra, w połączeniu z operacjami bezblokowymi CAS dla nieprzytrzymywanych zapisów i odczytów. Taka architektura pozwala na tysiące wątków do jednoczesnego zapisu do różnych koszyków bez kontrowersji, podczas gdy operacje zmiany rozmiaru wykorzystują progresywny transfer z volatile wskaźnikami na kolejną tabelę, aby umożliwić odczyty w trakcie migracji.
Kiedy należy preferować computeIfAbsent nad putIfAbsent i jakie implikacje dotyczące blokowania należy wziąć pod uwagę?
computeIfAbsent jest niezbędne, gdy tworzenie wartości jest kosztowne i musi odbywać się atomowo tylko wtedy, gdy klucz jest nieobecny, ponieważ akceptuje Function, która wykonuje się tylko wtedy, gdy to konieczne. Jednak implementacja blokuje cały koszyk haszujący na czas wykonania funkcji, co oznacza, że długotrwałe obliczenia zserializują cały dostęp do kluczy haszujących do tego koszyka, co potencjalnie stworzy wąskie gardło wydajności. putIfAbsent wymaga, aby wartość była wcześniej obliczona przed wywołaniem, co oznacza, że kosztowne tworzenie odbywa się niezależnie od obecności klucza, ale blokada jest trzymana tylko podczas krótkiego sprawdzenia wstawienia, co czyni ją preferowaną, gdy tworzenie wartości jest tanie lub idempotentne.