CODEWITHSUNDEEP
javaconcurrencythread-safetyblocking
superche
superche

Reputation: 773

Thread safely loop through ConcurrentHashMap with no blocking

I'm working on an ultra low latency and high performance application. The core is single threaded, so don't need to worry about concurrency.

I'm developing a schedule log function which log messages periodically to prevent same messages flush in the log.

So the log class contains a ConcurrentHashMap, one thread update it (put new key or update existing value), another thread periodically loop through the map to log all the messages.

My concern is since need to log when loop through the Map which may take time, would it block the thread trying to update the Map? Any blocking is not acceptable since our application core is single threaded.

And is there any other data structure other than ConcurrentHashMap I can use to reduce the memory footprint?

Is there a thread-safe way to iterate the Map without blocking in the read-only case? Even the data iterated may be stale is still acceptable.

Upvotes: 1

Views: 319

Answers (2)

dm03514
dm03514

Reputation: 55972

There may be other structures that would allow you to reduce the memory footprint, reduce latency, and perhaps offer a more uniform & consistent performance profile.

One of these is a worker pattern where your main worker publishes to a nonblocking queue and the logger pulls from that queue. This should decouple the two processes, allow for multiple concurrent publishers and allow you to scale out loggers.

One possible data structure for this is ConcurrentLinked Queue. I have very little experience with Java so I'm not sure how the performance profile of this differs from concurrent hashmap; but this is a very common pattern in distributed systems and in golang.

Upvotes: 0

unautre
unautre

Reputation: 191

According to the java API docs, it says that :

[...] even though all operations are thread-safe, retrieval operations do not entail locking [...]

Moreover, the entrySet() method documentation tells us that:

The [returned] set is backed by the map, so changes to the map are reflected in the set, and vice-versa.

That would mean that modification of the map is possible while an iteration is done over it, meaning that it indeed doesn't block the whole map.

Upvotes: 1

Related Questions