Java Developer Interview Question

You need a map shared by many threads. What do you use, and what does ConcurrentHashMap do that a synchronized map does not?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

Use ConcurrentHashMap. It locks per bin rather than the whole map, using a compare and set for empty bins and synchronizing on the bin head otherwise, so readers never block and writers to different bins proceed in parallel. A synchronized map serializes every operation on one lock, and it still requires external synchronization while iterating. Use its atomic methods, such as compute and merge, instead of get followed by put.

Why interviewers ask this

It checks whether you know why the concurrent collections exist rather than reaching for synchronized by reflex. The interviewer wants the granularity difference and the crucial practical point that wrapping a map does not make sequences of operations atomic. Knowing that size and iteration are weakly consistent, and when CopyOnWriteArrayList or a BlockingQueue is the better tool, rounds out the answer.

How to structure your answer

  • Name the tool first, then the mechanism that makes it faster.
  • Explain why a synchronized wrapper is still not enough for compound actions.
  • Point to the atomic methods for read modify write.
  • Mention the other concurrent collections and when they fit.

Example answer

Spoken example, first person

ConcurrentHashMap, almost always. The important difference is granularity: it locks at the level of a single bin, and an insert into an empty bin is just a compare and set, so unrelated keys do not contend and reads are lock free. A synchronized map puts one lock around everything, so it becomes the bottleneck as soon as several threads are busy. The bigger trap with a synchronized wrapper is that individual calls are atomic but sequences are not, so if I check containsKey and then put, another thread can slip between them, and iteration is not safe at all without holding the lock myself. That is why I use the atomic methods: computeIfAbsent for a lazily built cache entry, merge for counters, so the read modify write happens inside the map. The things to know are that size is an estimate under concurrent modification and iterators are weakly consistent, so they do not throw but may not see the newest writes. For other shapes I use CopyOnWriteArrayList when reads vastly outnumber writes, and a BlockingQueue for producer and consumer handoff.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • What are the risks of doing expensive work inside computeIfAbsent?
  • What does weakly consistent iteration mean in practice?
  • When is CopyOnWriteArrayList the wrong choice?

Related java developer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot