VarHandle generalizuje dostęp do volatile, oddzielając akces do lokalizacji pamięci od semantyki porządku pamięci stosowanej do niej. Podczas gdy zmienna volatile zawsze wymusza całkowite porządkowanie (sekwencyjna spójność) dla każdego odczytu i zapisu, VarHandle oferuje cztery różne tryby — plain, opaque, acquire/release oraz volatile — umożliwiając programistom wybór słabszych modeli spójności, gdy pełna sekwencyjna spójność nie jest konieczna. To oddzielenie pozwala zaawansowanym algorytmom współbieżnym na pominięcie kosztownych barier StoreLoad na architekturach takich jak x86 lub ARM, znacznie poprawiając przepustowość w scenariuszach takich jak kolejki z jednym producentem i jednym konsumentem. API osiąga to bez odwołania się do sun.misc.Unsafe, zapewniając w pełni wspieraną standardową mechanizm do dostępu poza stertą, manipulacji elementami tablicy i aktualizacji pól rekordów z precyzyjnymi, weryfikowalnymi semantykami pamięci.
Optymalizowaliśmy bezblokowy bufor pierścieniowy używany do zbierania telemetrii, gdzie wątek producenta zapisywał zdarzenia, a wątek konsumenta je przetwarzał, oba operując na współdzielonej tablicy. Początkowa implementacja korzystała z tablicy volatile dla elementów bufora, zapewniając widoczność, ale wywołując pełną barierę pamięci przy każdej aktualizacji slotu, co stało się wąskim gardłem na naszych serwerach opartych na ARM.
Pierwszą rozważaną alternatywą było utrzymanie volatile i dodanie wypełnienia linii pamięci, aby uniknąć fałszywego współdzielenia. To zachowało poprawność i zmniejszyło ruch koherencyjny pamięci, ale nadal narzucało pełny koszt bariery StoreLoad inherentny dla volatile, konsumując cenne cykle CPU na gwarancje porządku, których nie potrzebowaliśmy między producentem a konsumentem.
Oceniliśmy powrót do bloków synchronized chroniących indeksy bufora, co uprościłoby rozumowanie dotyczące bezpieczeństwa, zapewniając wzajemne wykluczenie. Niestety, to podejście zserializowało operacje producenta i konsumenta, niszcząc bezblokowe właściwości opóźnienia, które były niezbędne dla naszych docelowych czasów przetwarzania poniżej jednej milisekundy i wprowadzając ryzyko inwazji priorytetów przy dużym obciążeniu.
Zastosowaliśmy VarHandle z setRelease dla zapisów producenta i getAcquire dla odczytów konsumenta. To powiązanie zapewniło niezbędny związek występujący przed zapisem i następnym odczytem, nie wymuszając całkowitego porządku względem innych zmiennych, doskonale odpowiadając modelowi pamięci wymaganemu dla naszej kolejki z jednym producentem i jednym konsumentem.
Rezultująca przepustowość poprawiła się o około czterdzieści procent na serwerach ARM w porównaniu do podstawy volatile, przy zachowaniu poprawności, co pokazuje, że słabsze modele spójności wystarczają, gdy projekt algorytmu już ogranicza wzorce współbieżności.
Czy VarHandle to tylko bezpieczny wrapper wokół Unsafe do dostępu do pamięci poza stertą?
Chociaż VarHandle może zarządzać segmentami poza stertą za pomocą MemorySegment, jego główny postęp architektoniczny polega na ujawnieniu trybów porządku pamięci, które Unsafe jedynie przybliżał za pomocą nieprzezroczystych barier. VarHandle pozwala zadeklarować, czy dostęp bierze udział w porządku synchronizacji (acquire/release) lub tylko zapewnia atomowość (opaque), różnice, które Unsafe’s surowe putOrdered zlewał lub wymagał ręcznego wstawienia bariery, aby poprawnie przybliżyć, co sprawia, że weryfikacja kodu przeciwko JMM jest znacznie bardziej wiarygodna.
Czy setOpaque gwarantuje, że mój zapis stanie się widoczny dla innego wątku?
Nie. Tryb Opaque zapewnia atomowość i koherencję — zapis wydaje się niepodzielny i uporządkowany względem innych nieprzezroczystych dostępów do tej samej zmiennej — ale nie zapewnia żadnej gwarancji wystąpienia przed-wątku. Wątek odczytujący przy użyciu getOpaque może zapętlić się w nieskończoność, obserwując przestarzałą wartość z pamięci podręcznej, chyba że inny mechanizm synchronizacji wymusi opróżnienie pamięci podręcznej, w przeciwieństwie do acquire/release, które tworzy niezbędną krawędź widoczności między pisarzem a czytelnikiem.
Kiedy powinienem woleć tryb volatile zamiast setRelease/getAcquire?
Wybierz volatile, gdy wymagasz spójności sekwencyjnej: całkowitego porządkowania wszystkich operacji volatile względem siebie w globalnym porządku synchronizacji. Użyj acquire/release, gdy musisz jedynie wymusić porządek między konkretnym zapisem a następnym odczytem (bezpieczeństwo publikacji), bez koordynowania z wszystkimi innymi dostępami do pamięci. Niewłaściwe stosowanie acquire/release do algorytmów zakładających spójność sekwencyjną prowadzi do subtelnych błędów w porządkowaniu, gdzie niezależne aktualizacje zmiennych wydają się wychodzić z porządku dla różnych obserwatorów.