Jednoczesna kolekcja do 50/50 odczyt/zapis

Question

Potrzebuję twojej porady. Na wstępie chciałbym opisać wstępne warunki.

1. mam pewne osoby trzeciej Java obiektów z domyślnie java.lang.Object „s hashCode() i equals() realizacji. Interfejs Comparable nie jest zaimplementowany. Rozmiar jest nieistotny.
2. Potrzebuję przechowywać takie obiekty przez jakiś czas w pamięci. Będę czytać i pisać je z różnych wątków w stosunku 50/50 (około 50% czyta i 50% pisze).
3. Kolejność obiektów nie jest ważna. Po prostu chcę mieć możliwość wzięcia jakiegoś przedmiotu ze sklepu, to wszystko. Z bierze mam na myśli zarówno uzyskać i usunąć w tym samym czasie.
4. Oczywiście, chcę, aby działał tak szybko, jak to możliwe, przy najniższym zużyciu pamięci. Próbuję uniknąć wszelkich synchronizacji w moim kodzie.

Najpierw próbowałem samodzielnie rozwiązać ten problem. Od razu odrzuciłem kolekcje CopyOnWriteArray* ze względu na duże zużycie pamięci. Czytałem, że lepiej używać ich w przypadku rzadkich zapisów. ConcurrentHashMap w ogólnych apartamentach dla moich potrzeb, ale nie znalazłem sposobu, aby podjąć operacji atomowej bez synchronizacji. Zatrzymałem się z moim dochodzeniem w sprawie kolekcji ConcurrentSkipListSet. Zawiera on metodę pollFirst, która jest całkiem niezłym zbiorem dla obiektów z.

Zaimplementowałem moje rozwiązanie z ConcurrentSkipListSet jako podstawę. Wszystko działa dobrze z wyjątkiem jednego małego szczegółu. Jak wspomniałem wyżej obiekty, z którymi pracuję, nie implementuję Comparable. Aby użyć wybranej kolekcji, muszę w jakiś sposób wdrożyć Comparator. Oto moja implementacja tego interfejsu. W tym przykładzie użyłem bezpośrednio java.lang.Object zamiast mojego typu obiektów. Zrobiłem to, ponieważ implementacja jest całkowicie taka sama, różnica jest tylko w ogólnej części klasy.

import java.util.Comparator; 

public class ObjectComparator implements Comparator<Object> { 

    public int compare(Object o1, Object o2) { 
     return o1.hashCode() - o2.hashCode(); 
    } 
} 

Wady tej implementacji są oczywiste. Odkryłem, że jest tam no guarantee, że dwa różne obiekty będą miały różne kody skrótów. W takim przypadku można stracić niektóre przedmioty, które nie są akceptowane. Myślałem, aby zwrócić kilka liczb losowych w przypadku równych kodów mieszania dla różnych obiektów, ale nie jestem pewien, że nie złamie implementacji ConcurrentSkipListSet.

W odniesieniu do opisanej sytuacji mam dwa ogólne pytania.

1. Czy możliwe jest wdrożenie Comparator dla mojego obiektu w taki sposób, aby jak nie wrócić 0 dla różnych obiektów i zachować ConcurrentSkipListSet funkcjonalności?
2. Czy istnieje inny sposób przechowywania moich obiektów?

Z góry dziękuję za odpowiedzi.

Answer 1

Prawdopodobnie szukasz ConcurrentLinkedQueue, to będzie przechowywać elementy w oparciu o zamówienie FiFo (pierwsze weszło). Z tego powodu nie są wymagane wymagania. Implementacja tej kolejki jest bardzo wydajna, bez żadnego wewnętrznego blokowania.

Jedną z trudności, które masz (jeśli nie używasz zamków) jest to, że nie możesz sprawdzić, czy kolekcja nie jest pusta, a następnie wziąć ją (ponieważ mogła ulec zmianie po sprawdzeniu i przed wykonaniem działania). W związku z tym funkcja take powróci null, gdy nic nie będzie obecne. Jeśli nie chcesz utrzymywać odpytywania danych, możesz także skorzystać z klas implementujących interfejs BlockingQueue, który oferuje funkcje, które czekają, aż dane będą dostępne.

Answer 2

1: Można zaimplementować porównawczy jako takie:

public int compare(Object o1, Object o2) { 
    if (o1 == o2) { 
     return 0; 
    } else { 
     int dif = o1.hashCode() - o2.hashCode(); 
     if (dif != 0) { 
      return dif; 
     } else { 
      return 1; //Might cause issues 
     } 
    } 
} 

2: Można zrobić każdy normalny kolekcji zsynchronizowane przy użyciu java.util.Collections.synchronizedCollection() (lub dowolna inna metoda zsynchronizowana). Na przykład, jeśli zsynchronizujesz LinkedList, możesz użyć polecenia remove (index) do , aby zabrać obiekt pod obiekt.

Answer 3

ConcurrentHashMap w ogólnych apartamentów dla moich potrzeb, ale nie mogę znaleźć sposób, aby podjąć działanie atomowy

Dlaczego nie skorzystać remove w ConcurrentHashMap? Wydaje się, że to jest to, czego potrzebujesz.