2

Several threads are accessing a ConcurrentHashMap, which is populated with entries when the application loads up, and is rarely modified structurally thereafter. Most operations on the map are either reading, or replacing existing entry values. Very rarely new entries are created or removed, and even then just a few every time. Therefore, usually contention is predicted on the entry level only.

What should I set the concurrencyLevel to? I was thinking of value of 1, because the map is hardly ever modified structurally, and when that happens, I rather pay the price of contention over larger internal strucute size.

EDIT: The suggested link answers my question, but it's worth mentioning that although concurrencyLevel of 1 is sufficient in my case, ConcurrentHashMap still allows for concurrent read/write access on the Entry level without locking, since it features a volatile read/write semantics.

Daniel Nitzan
  • 1,582
  • 3
  • 19
  • 36
  • Well, you've pretty much answered your own question there. – biziclop Mar 13 '15 at 15:07
  • It depends on how much threads *could* write to the map at the same time. With a concurrency level of 16 (which is the default) 16 threads can write at the same time. if you just use 1, while having 16 threads using it, you would always block 15 threads. Do a rough estimation on how much writing is going on *worst-case* - then i'd take that number. – dognose Mar 13 '15 at 15:09
  • Only you can answer this question without posting the actual code because we cant know how many threads will ever concurrently modify the table. – Jelle de Fries Mar 13 '15 at 15:09
  • Though if this is a server-side application, and there is a real chance that it will have to be scaled up, I might make the code pick up the concurrency level value from a config. – biziclop Mar 13 '15 at 15:10
  • I'd use the default. More concurrency doesn't really hurt, and in the future (or possibly a burst of modification and reading) you may need the concurrency. – markspace Mar 13 '15 at 15:10

0 Answers0