Concurrent Linked HashMap java

Question

Please help me use/create Concurrent LinkedHashMap in multithreaded architecture.

As per my belief, if I use Collections.synchronizedMap(), I would have to use synchronized blocks for iterator. Would this implementation lead to sequential addition of elements

If I use ConcurrentSkipListMap<String,String> 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.

Thanks

EDIT:

In Concurrent LinkedHashMap, the keys are the name, I wish to put the keys in sequence of their arrival. i.e. new value would be appened 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 follow the seqence 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

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 2

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 3

A LinkedHashMap has a doubly linked list running through a hashtable. A FIFO only mutates the links on 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().