Implementing a concurrent LinkedHashMap

Question

I'm trying to create a concurrent LinkedHashMap for a multithreaded architecture.

If I use Collections#synchronizedMap() , I would have to use synchronized blocks for iteration. This implementation would lead to sequential addition of elements.

If I use ConcurrentSkipListMap is there any way to implement a Comparator to store sequentially, as stored in Linked List or queue.

I would like to use java's built in instead of third party packages.

EDIT:

In this concurrent LinkedHashMap , if the keys are the name, I wish to put the keys in sequence of their arrival. ie new value would be appended to either at start or end, but sequentially.

While iterating, the LinkedHashMap could be added with new entries, or removed. but the iteration should be the sequence in which the entries were added.

I understand that by using Collections#synchronizedMap() , an synchronized block for iteration would have to be implemented, but would the map be modifiable (entries could be added/removed) while it is being iterated.

Answer 1

If you use synchronizedMap, you don't have to synchronize externally, except for iteration. If you need to preserve the ordering of the map, you should use a SortedMap. You could use ConcurrentSkipListMap, which is thread-safe, or another SortedMap in combination with synchronizedSortedMap.

Answer 2

A LinkedHashMap has a doubly linked list running through a hashtable. A FIFO only mutates the links on a write (insertion or removal). This makes implementing a version fairly straightforward.

1. Write a LHM with only insertion order allowed.
2. Switch to a ConcurrentHashMap as the hashtable.
3. Protect #put() / #putIfAbsent() / #remove() with a lock.
4. Make the "next" field volatile.

On iteration, no lock is needed as you can safely follow the "next" field. Reads can be lock-free by just delegating to the CHM on a #get() .

Answer 3

Use Collections#synchronizedMap() .

As per my belief, if I use Collections.synchronizedMap(), I would have to use synchronized blocks for getter/setter.

This is not true. You only need to synchronize the iteration on any of the views (keyset, values, entryset). Also see the abovelinked API documentation.

Answer 4

Until now, my project used LRUMap from Apache Collections but it is based on SequencedHashMap. Collections proposes ListOrderedMap but none are thread-safe.

I have switched to MapMaker from Google Guava . You can look at CacheBuilder too.

Answer 5

Um, simple answer would be to use a monotonically increasing key provider that your Comparator operates on. Think AtomicInteger , and every time you insert, you create a new key to be used for comparisons. If you pool your real key, you can make an internal map of OrderedKey<MyRealKeyType> .

class OrderedKey<T> implements Comparable<OrderedKey<T>> {
  T realKey;
  int index;
  OrderedKey(AtomicInteger source, T key) {
    index = source.getAndIncrement();
    realKey = key;
  }
  public int compareTo(OrderedKey<T> other) {
    if (Objects.equals(realKey, other.realKey)) {
      return 0;
    }
    return index - other.index;
  }


}

This would obviate the need for a custom comparator, and give you a nice O(1) method to compute size (unless you allow removes, in which case, count those as well, so you can just subtract "all successful removes" from "all successful adds", where successful means an entry was actually created or removed).