ConcurrentHashMap Czytanie i zapisywanie blokad

Question

Próbuję znaleźć odpowiedź na te, ale nie mogę znaleźć go w Google lub w dokumentach Java.

Przypadek 1: w ConcurrentHashMap, załóżmy wątek t1 czyta z segmentu n, a na samym innym wątku t2 chcą pisać na n samym segmencie:

Pytanie 1: czy te dwie operacje będą jedna po drugiej, czy będą wykonywane jednocześnie?

Przypadek 2: w ConcurrentHashMap załóżmy, że wątek t1 pisze na segmencie n, a na sam inny wątek t2 chcą czytać z samym segmencie n,

Pytanie 2: czy te dwie operacje będą jedna po drugiej, czy będą wykonywane jednocześnie?

Answer 1

myślę odpowiedzi javadoc oba pytania:

operacji pobierania (w tym dostać) generalnie nie blokują, więc może pokrywają się z operacji aktualizacji (W TYM umieścić i wyjąć). Retrievals odzwierciedlają wyniki ostatnio wykonanych operacji aktualizacji . W przypadku operacji agregujących, takich jak putAll i , wyraźne, współbieżne wyszukiwania mogą odzwierciedlać wstawianie lub usuwanie tylko niektórych pozycji.

Segmenty są przy aktualizacji:

Dopuszczalny współbieżności między operacji aktualizacji jest prowadzony przez opcjonalnie concurrencyLevel konstruktora argumentu (domyślnie 16), który jest stosowany jako wskazówka do zaklejania wewnętrznego.

Krótko mówiąc, odczyty nie są blokowane (implementuje się je jako zmienne odczytujące zmienne). Wpisy mogą blokować się nawzajem, jeśli piszą w tym samym segmencie.

Answer 2

Według docs ConcurrentHashMap Oracle

Konstruktor ConcurrentHashMap wygląda następująco:

publicznego ConcurrentHashMap (int initialCapacity, float loadFactor, int concurrencyLevel)

Zatem powyższa linia tworzy nowa, pusta mapa z określoną początkową pojemnością, współczynnikiem obciążenia i poziomem współbieżności. gdzie ważne parametry, które należy rozważyć z ConcurrentHashMap Konstruktor:

• initialCapacity - początkowa pojemność. Implementacja wykonuje wewnętrzny rozmiar, aby pomieścić tak wiele elementów.
• concurrencyLevel - szacowana liczba jednoczesnych aktualizacji wątków. Implementacja służy do wewnętrznego wymiarowania, aby spróbować uwzględnić wiele wątków.

W aplikacji ConcurrentHashMap Api znajdują się następujące stałe.

• statyczny końcowy int DEFAULT_INITIAL_CAPACITY = 16;
• statyczny końcowy int DEFAULT_CONCURRENCY_LEVEL = 16;

Parametry początkowego parametru wydajności i poziomu współbieżności konstruktora ConcurrentHashMap (lub obiektu) są domyślnie ustawione na 16.

W ten sposób, zamiast blokady szerokiej mapy, ConcurrentHashMap utrzymuje listę 16 blokad domyślnie (liczba blokad równa początkowej pojemności, która jest domyślnie 16), z których każda jest używana do blokowania pojedynczego zasobnika Mapa.Oznacza to, że 16 wątków (liczba wątków równa się poziomowi współbieżności, który jest domyślnie 16) może modyfikować kolekcję w tym samym czasie, biorąc pod uwagę, że każdy wątek działa na różnych zasobnikach. W odróżnieniu od hashtable, wykonujemy dowolną operację (aktualizację, usuwanie, czytanie, tworzenie) bez blokowania na całej mapie w aplikacji ConcurrentHashMap.

Operacje pobierania (w tym get) zasadniczo nie są blokowane. Używa w tym przypadku pojęcia niestabilności., więc może pokrywać się z operacjami aktualizacji (w tym wstawiania i usuwania). Retrievals odzwierciedlają wyniki ostatnio wykonanych operacji aktualizacji, które utrzymują się w momencie ich wystąpienia.

Dozwolona współbieżność między operacjami aktualizacji jest sterowana przez opcjonalny argument konstruktora ConcurrencyLevel (domyślnie 16), który jest używany jako wskazówka do wewnętrznego rozmiaru. Tabela jest wewnętrznie podzielona na partycje w celu umożliwienia wskazanej liczby równoczesnych aktualizacji bez rywalizacji. Ponieważ umieszczanie w tabelach mieszania jest zasadniczo losowe, faktyczna współbieżność będzie się różnić. Najlepiej jest wybrać wartość, aby pomieścić tyle wątków, ile kiedykolwiek jednocześnie modyfikuje tabelę. Używanie znacznie większej wartości niż potrzebna może zmarnować miejsce i czas, a znacznie mniejsza wartość może prowadzić do rywalizacji o wątki.

Mam nadzieję, że to pomoże!