0

I have a data structure as:-

Map<String,Map<String,List<CustomPOJO>>>

The frequency of read operations on this data structure will be too high and write operations will also be there but not many.

As far as read is concerned I guess there is no issue by using simple java.util.HashMap API.

For write operations there can be two approaches:-

  1. Put entire data in ConcurrentHashMap and use it to write data into it.

  2. Perform all write operations in a synchronized block/method and use simple java.util.HashMap API.

Please suggest which one would be better for write operation and also suggest whether there can be any loophole in read operation.

Pshemo
  • 122,468
  • 25
  • 185
  • 269
Timothy Drisdelle
  • 395
  • 3
  • 5
  • 14
  • possible duplicate of [ConcurrentHashMap vs Synchronized HashMap](http://stackoverflow.com/questions/1291836/concurrenthashmap-vs-synchronized-hashmap) – Leo Jan 26 '14 at 13:25
  • There aren't many use cases where a synchronized map can beat a concurrent hashmap. – assylias Jan 26 '14 at 13:38

2 Answers2

1

Firstly, how predictable is the outer Map's key string value? If that's all predictable at design time, I would rather turn that into an Enum and uses an EnumMap to hold the outer Map. The same applies for the inner map, too. In that case your question turns into 

EnumMap<Enum, EnumMap<Enum, List<POJO>>>

and is perfectly resolved.

Secondly, since you are using a map of map structure and using in an env where performance matters, I would assume the number of keys in the outer map << the number of total POJOs inside the entire structure. That's to say, the chance you add a new submap to the whole structure is very small. In this case a ReadWriteLock is best on the outer Map; For the inner map you could consider either ReadWriteLock or ConcurrentHashMap.

There are 3 major design considerations for the ConcurrentHashMap:

  1. That it generates a lot of temp objects. So if your application is GC-sensitive you want to limit its usage.
  2. That it allows maximum 16 concurrent threads operating it by default - but this is unlikely to be a concern.
  3. That it's size() isn't constant time.

I would usually apply ReadWrite lock pattern or even atomic variable based implementation mainly when 1. turns out to be a problem. Otherwise I think ConcurrentHashMap does fine in most of circumstances.

Also, note that in the latest implementation of JDK, the Read/Write priority changed for the ReadWriteLock. If my memory is correct it seems to favor read operation than write; so in case you have too many reads your write thread might got thread starvation. In that case you might want your own read/write implementation.

Alex Suo
  • 2,977
  • 1
  • 14
  • 22
0

I think this article best suites to your question there is explanation. Personally I think you should use ConcurrentHashMap because it allow reader to read without blocking all hashmap. http://javarevisited.blogspot.com/2011/04/difference-between-concurrenthashmap.html

RMachnik
  • 3,598
  • 1
  • 34
  • 51