Czy ktoś jest świadomy jakiegokolwiek rzeczywistego korzystania z klasy AtomicLongFieldUpdate? Przeczytałem opis, ale nie do końca zrozumiałem jego znaczenie. Dlaczego chcę to wiedzieć? Ciekawość i przygotowanie OCPJP.Prawdziwe wykorzystanie i wyjaśnienie klasy AtomicLongFieldUpdate
Z góry dziękuję.
Atomics są zwykle używane w programowaniu równoległym.
W trybie kradzieży pracy obsługuje tylko asynchroniczne, końcowe, forasync, izolowane i zmienne atomowe.
Można postrzegać atomową jako bezpieczną ochronę przed wyścigiem danych i innymi problemami, które należy uwzględnić w programowaniu równoległym.
Można myśleć o drabinie kosztów za:
long: tanie, ale niebezpieczne dla wielowątkowych dostępuvolatile long: operacje droższe, bezpieczne dla wielowątkowych dostępu atomowych niemożliweAtomicLong: najdroższe, bezpieczne dla wielowątkowych dostępu, możliwe operacje atomowe(Whe n Mówię "niebezpieczny" lub "niemożliwy", mam na myśli "bez zewnętrznego mechanizmu, takiego jak synchronizacja" oczywiście.)
W przypadku, gdy wymagany jest dostęp wielowątkowy, ale większość operacji to proste odczyty lub zapisy, z wystarczy kilka operacji atomowych, możesz utworzyć jedną instancję statyczną o numerze AtomicLongFieldUpdate i użyć jej, gdy potrzebne są aktualizacje atomowe. Narzut pamięci/środowiska wykonawczego jest wówczas podobny do prostej zmiennej volatile, z wyjątkiem operacji atomowych, które są rzędu (lub nieco droższe niż) operacji zwykłych AtomicLong.
Oto nice little tutorial.
Wystarczy dodać więcej informacji. 'AtomicLong' jest tylko bardziej" kosztowny "niż' volatile long' w tym, że istnieje klasa wrapperów - więc nieco więcej pamięci narzutowej. Ponadto, 'volatile long' nie jest" bezpieczny dla wielowątkowego dostępu ", jeśli robisz' ++ '. – Gray
Również narzut pamięci' AtomicLongFieldUpdate' nas będzie czymś więcej niż zwykłym 'AtomicLong'. runtime będzie wolniejsze niż oba 'volatile long' i' AtomicLong' ponieważ używa refleksji – Gray
@Gray Możesz użyć 1 statycznej instancji ALFU, więc obciążenie pamięci nie jest tak duże, jak mogłoby ci się wydawać. myśl (nie wiesz), że odbicie jest używane tylko do konfiguracji pola, a nie na każdym dostępie, a ponadto w najnowszych wersjach HotSpot operacja jest [wewnętrzna] (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id = 7023898) Dokładny model kosztowy (pamięć i środowisko wykonawcze) będzie zależał od implementacji JRE i JVM – rxg
Czy ktoś wie o jakimkolwiek rzeczywistym użyciu klasy
AtomicLongFieldUpdate?
nigdy nie używałem tej klasy w sobie, ale robi mi na wykorzystanie przestrzeni roboczej widzę parę „prawdziwego życia” przypadków jego stosowania:
com.google.common.util.concurrent.AtomicDouble używa go do atomowo modyfikować swoje wewnętrzne pole volatile long przechowujące bity z double przy użyciu Number.doubleToRawLongBits(...). Całkiem fajne.
net.sf.ehcache.Element używa go do atomowej aktualizacji pola hitCount.
Czytałem opis ale nie całkiem zrozumiał znaczenia.
Zasadniczo zapewnia tę samą funkcjonalność co AtomicLong, ale na polu lokalnym dla innej klasy.Obciążenie pamięci urządzenia AtomicLongFieldUpdate jest mniejsze niż AtomicLong, ponieważ konfiguruje się jedną instancję aktualizacji dla każdego pola, co zmniejsza obciążenie pamięci, ale zwiększa obciążenie procesora (choć może niewielkie) z odbicia.
W Javadocs powiedzieć:
Ta klasa jest przeznaczony do stosowania w atomowych struktur danych, w której kilka pól tego samego węzła są niezależnie podlega aktualizacji atomowych.
Oczywiście, ale wtedy użyłbym wielu pól Atomic*. Jedyny powód, dla którego użyłbym tej klasy, to jeśli istniała klasa, której nie mogłem zmienić, którą chciałem zwiększyć atomowo.
Powód, dla którego warto użyć np. AtomicLongFieldUpdater na rzecz AtomicLong to po prostu obniżenie kosztów sterty. Wewnętrznie oba działają prawie tak samo na poziomie compareAndSet, z których oba używają sun.misc.Unsafe na końcu.
Weź pod uwagę, że masz określoną klasę, która jest inicjowana 1000 k razy. Z AtomicLong utworzysz 1000k AtomicLongs. Z drugiej strony, przy użyciu AtomicLongFieldUpdater, utworzysz 1 STAŁĄ AtomicLongFieldUpdater i prymitywy o długości 1000k, które oczywiście nie potrzebują tak dużo miejsca na sterty.
Nie odpowiada to na pytanie dotyczące "AtomicLongFieldUpdate". – Gray