JavaCollectionsConcurrencyHashingjunior level

HashMap vs Hashtable in modern Java

the question

What is the difference between `HashMap` and `Hashtable` in Java, and which one would you use?

what they're testing: The interviewer is probing whether you can choose a collection by its null, synchronization, and concurrency guarantees instead of treating similar APIs as interchangeable.

a strong answer

HashMap is the usual choice when you do not need a shared, concurrently updated map. Both classes implement Map with hash tables, but HashMap is unsynchronized and accepts one null key and any number of null values. Hashtable is synchronized and accepts neither. Neither promises iteration order.

A synchronized method makes that one call thread-safe; it does not make containsKey followed by put one atomic action. Hashtable also serializes its synchronized operations on the instance, limiting concurrency. When threads share and update a map, ConcurrentHashMap is usually the better choice. Its retrievals generally do not block, and operations such as computeIfAbsent are atomic.

Hashtable dates from Java 1.0 and was later adapted to implement Map. It is not deprecated, so legacy code or an API typed specifically as Hashtable may still justify it. In new code, use HashMap for ordinary single-threaded or externally synchronized access. Use ConcurrentHashMap when the map itself must support concurrent access, unless the required operation needs an explicit shared lock.

Where people slip

the tempting wrong answer, and what's actually true

`Hashtable` is deprecated, so using it produces a deprecation warning.
`Hashtable` is a legacy class but is not deprecated; modern code usually has better choices.
Because `Hashtable` is synchronized, any multi-step operation on it is atomic.
Synchronization protects each method call, but other threads can interleave between calls. To make the sequence atomic, hold the same lock around the entire sequence.
`HashMap` and `Hashtable` have the same rules for `null`.
`HashMap` permits one `null` key and multiple `null` values, while `Hashtable` permits neither.
`Hashtable` is the standard choice whenever multiple threads share a map.
Oracle recommends `ConcurrentHashMap` when a thread-safe, highly concurrent map is needed.

If they push further

How can you make a `HashMap` safe for shared mutation?

Protect every access with one shared lock, or wrap the map with `Collections.synchronizedMap` at creation time and access it only through the wrapper. Synchronize on the returned map during traversal; multi-call actions need one lock around the whole sequence.

Why is `ConcurrentHashMap` usually preferred to `Hashtable`?

Its retrievals generally do not block, it supports high expected concurrency for updates, and it offers atomic methods such as `putIfAbsent`, conditional `replace`, and `computeIfAbsent`.

Does either implementation preserve insertion order?

No. Use an insertion-ordered `LinkedHashMap` when predictable insertion-order iteration is required.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.