Historia: Przed Javą 8, współbieżna akumulacja opierała się na AtomicLong, którego jedna lokalizacja pamięci stała się wąskim gardłem skalowalności pod obciążeniem wątków z powodu nadmiernego unieważniania linii pamięci podręcznej w różnych rdzeniach CPU. LongAdder został wprowadzony jako część pakietu java.util.concurrent.atomic, aby rozwiązać ten problem za pomocą techniki inspirowanej algorytmem Striped64, dynamicznie partycjonując operacje zapisu na wiele wypełnionych komórek.
Problem: Gdy wiele wątków jednocześnie podejmuje próby operacji CAS na współdzielonym AtomicLong, każda niepowodzenie wywołuje rozgłos spójności pamięci podręcznej, co szeregowo zrujnowuje ruch pamięci i drastycznie obniża przepustowość w zależności od liczby rdzeni. Zjawisko to, znane jako skakanie linii pamięci podręcznej, uniemożliwia linearną skalowalność nawet w przypadku innych zadaniach, które są w obliczu równoległymi.
Rozwiązanie: LongAdder początkowo próbuje aktualizacji na pojedynczym polu base przy użyciu CAS; tylko po wykryciu współzawodnictwa — w szczególności gdy wątek nie zdołał zdobyć blokady podstawowej po sekwencji badań probabilistycznych (zwykle realizowanej za pomocą licznika kolizji i lokalnego haszowania w Striped64) — leniwie alokuje tablicę obiektów Cell oznaczonych @Contended. Każdy wątek następnie hashuje do odrębnej komórki, wykonując niekontestowane dodania w izolowanych liniach pamięci podręcznej, podczas gdy metoda sum() leniwie łączy te wartości tylko wtedy, gdy wymagana jest spójna migawka.
Platforma handlu o wysokiej częstotliwości wymagała globalnego licznika do weryfikacji przepustowości zamówień w 64-rdzeniowej implementacji, początkowo zrealizowanej przy użyciu AtomicLong. W czasie szczytów zmienności rynku system wykazywał nieliniową degradację opóźnienia, gdzie czas odpowiedzi 99. percentyla wzrósł dziesięciokrotnie, profilowanie ujawniło, że 40% cykli CPU było marnowanych na protokoły spójności pamięci podręcznej rywalizujące o pojedynczy adres pamięci licznika.
Zespół inżynieryjny rozważał trzy rozwiązania architektoniczne. Po pierwsze, ocenili ręczny lokalny mapę liczników, gdzie każdy wątek utrzymywał niezależny AtomicLong w ConcurrentHashMap, okresowo agregowany przez tło raportera; chociaż wyeliminowało to współzawodnictwo, wprowadziło znaczny narzut pamięci na wątek oraz złożone zarządzanie cyklem życia podczas zmiany rozmiaru puli wątków, ryzykując wycieki pamięci w wieloletnich wykonawcach. Po drugie, prototypowali niestandardową strategię fragmentacji, wykorzystując tablicę 64 instancji AtomicLong indeksowanych przez Thread.currentThread().getId() % 64; to zmniejszyło ruch pamięci podręcznej, ale cierpiało na nierówną dystrybucję, gdy pules wątków wielokrotnie używały ID i wymagało ręcznego zarządzania dostosowaniem tablicy podczas wzrostu ruchu, co dodało delikatną kwestię utrzymania. Po trzecie, rozpatrzyli migrację do LongAdder, który oferował wbudowane dynamiczne paski z automatycznym wypełnieniem @Contended, aby zapobiec fałszywemu współdzieleniu, chociaż z kompromisem, że operacje odczytu zwracałyby słabo spójne przybliżenia zamiast dokładnych wartości atomowych.
Zespół ostatecznie zdecydował się na LongAdder, ponieważ wymaganie biznesowe tolerowało nieco przestarzałe wartości odczytu dla pulpitów monitorujących, podczas gdy ścieżka walidacji intensywnego zapisu wymagała maksymalnej przepustowości. Heurystyka automatycznej ekspansji komórek zapewniła, że podczas okresów niskiego ruchu obiekt pozostał lekki (pojedyncze pole bazowe), a duże współzawodnictwo wyzwalało przejrzystą skalowalność na różnych wypełnionych komórkach. Po wdrożeniu opóźnienie ustabilizowało się, a przepustowość skalowała się liniowo do 64 rdzeni w miarę rozdzielania ruchu unieważnienia pamięci podręcznej po różnych obszarach pamięci, zamiast koncentrować się na jednym gorącym punkcie.
Pytanie: Dlaczego częste sprawdzanie LongAdder.sum() w wąskim cyklu może potencjalnie unieważniać korzyści z wydajności paskowania i jakie gwarancje spójności oferuje ta metoda?
Odpowiedź: Metoda sum() musi przejść przez pole base i każdą aktywną Cell w tablicy, aby obliczyć sumę, wymagając barier pamięci, które wyzwalają synchronizację spójności pamięci podręcznej we wszystkich uczestniczących rdzeniach; w konsekwencji ciągłe obciążenia zapisu ze stron skutecznie seryjnie serializują paskowane zapisy i ponownie wprowadzają współzawodnictwo, którego LongAdder miał na celu uniknąć. Co więcej, sum() oferuje tylko słabą spójność, zwracając wartość dokładną wyłącznie w momencie wywołania bez gwarancji atomowości w odniesieniu do jednoczesnych aktualizacji, co oznacza, że wynik może odzwierciedlać tymczasowy stan, w którym niektóre inkrementy wątków są widoczne, podczas gdy inne nie.
Pytanie: Jak adnotacja @Contended w wewnętrznej klasie Cell LongAdder zapobiega fałszywemu współdzieleniu, a jaki flaga JVM reguluje to zachowanie wypełniania?
Odpowiedź: @Contended nakazuje kompilatorowi HotSpot wstrzyknąć 128 bajtów (lub wartość określoną przez -XX:ContendedPaddingWidth) wypełniania wokół pola value w każdej Cell, zapewniając, że sąsiednie elementy tablicy znajdują się na odrębnych liniach pamięci podręcznej niezależnie od optymalizacji rozmieszczenia obiektów. Bez tego wypełnienia, sekwencyjne komórki dzieliłyby 64-bajtową linię pamięci podręcznej, co powodowałoby, że zapisy do jednej komórki unieważniałyby pamiętane kopie sąsiadów w innych rdzeniach, ponownie wprowadzając skakanie pamięci podręcznej; kandydaci często pomijają, że ta adnotacja jest zarezerwowana dla wewnętrznych klas JDK, chyba że -XX:-RestrictContended jest wyraźnie wyłączona, aby umożliwić wykorzystanie kodu użytkownika.
Pytanie: W jakich konkretnych okolicznościach LongAdder wykazuje gorszą wydajność niż AtomicLong i jak implementacja longValue() wpływa na to zagrożenie?
Odpowiedź: LongAdder ponosi narzut alokacji dla swojej tablicy Cell i logiki obliczania haszy nawet podczas niekonfiltrowanego jedno-wątkowego wykonania, co sprawia, że AtomicLong jest lepszy w scenariuszach o niskim współzawodnictwie lub licznikach aktualizowanych wyłącznie przez jeden wątek. Co więcej, longValue() bezpośrednio deleguje do sum(), co oznacza, że każdy kodowy strumień, który ciągle sprawdza wartość licznika — taki jak algorytm spin-lock czy backpressure — zmusza do wielokrotnej globalnej agregacji, która synchronizuje wszystkie linie pamięci podręcznej, skutecznie przekształcając paskowaną strukturę w współdzieloną singleton i niszcząc skalowalność.