386 Java Developer Interview Questions & Answers

Access modifiers control where a Java class, constructor, field, method, or nested type can be used. Public gives the widest access. Protected allows access from the same package and from subclasses, with a special rule for subclasses in another package. Writing no modifier gives package access. Private limits access to the enclosing top level class or interface. In production code, I start with private and widen access only when the design requires it.

Access modifiers are visibility rules. They decide which parts of a program may use another part. These rules help developers show only what other code needs and hide details that should remain internal. This makes programs safer to change because fewer places can depend on hidden details. Java provides four access levels. Each level allows a different group of code to use the declared item. The correct choice depends on whether the item should be available everywhere, within one package, through inheritance, or only inside its owner.

1. Should I explain access for top level types as well as their members?
2. Should I include access between different packages?
3. Should I explain the special protected rule for subclasses in another package?

Java has four access levels: public, protected, package access, and private. Package access is selected by writing no access modifier.

Public gives the widest Java language access. A public member may be used from another class only when the declaring type is also accessible. In a named module, the package may also need to be exported to the module containing the caller.

Protected allows access from every class in the same package. It also allows access from a subclass in another package. In that second case, access is granted through inheritance. The subclass cannot freely access the protected member through an arbitrary object whose type is the parent class.

Package access allows use only by code in the same package. It is useful for helper types and members that several classes in one package share but outside code should not use.

Private is the narrowest level. A private member is accessible only within the body of the top level class or interface that encloses its declaration. This includes its nested types. Java compilers and the JVM support this access without requiring the developer to expose the member publicly.

A top level class or interface can be public or have package access. It cannot be protected or private. Members and nested types may use all four access levels.

The modifier itself does not allocate objects, copy values, or change asymptotic performance. Its purpose is access control. A strong production rule is to choose the narrowest level that still supports the required collaboration.

Common mistakes include calling package access an explicit modifier even though it is created by writing no modifier. Another mistake is assuming protected means subclasses only, because every class in the same package also receives access. Candidates may also assume that a subclass in another package can access a protected member through any parent object. Java does not allow that. Other mistakes include declaring a top level type as protected or private, making every member public, and assuming a public member is usable when its declaring type or package is not accessible.

Explain the four levels from widest to narrowest. Then mention that protected includes same package access and has a special inheritance rule across packages. Finish by stating that production code should use the narrowest access level that supports the required design.

The final keyword prevents a variable from being assigned again, prevents a method from being overridden, and prevents a class from being extended. For an object reference, final stops the reference from pointing to another object, but it does not stop changes inside a mutable object. I use final when a value, reference, method implementation, or class design should not be replaced.

The final keyword tells Java that a variable, method, or class has a restriction that later code cannot remove. For a variable, it stops another assignment after the first valid assignment. For a method, it stops a child class from replacing the inherited implementation. For a class, it stops another class from extending it. This makes the intended design clearer and prevents some accidental changes. However, final does not always make data completely unchangeable. Its exact effect depends on whether it is applied to a primitive value, an object reference, a parameter, a method, or a class.

1. Should I explain final local variables, fields, and parameters?
2. Should I compare a final reference with an immutable object?
3. Should I include the rules for final methods and final classes?

The final keyword creates a Java language restriction.

A final variable can be assigned only once. A final local variable may receive its value when declared or later, but Java must prove that every use happens after one definite assignment and that no second assignment occurs. A final parameter receives its value when the method is called and cannot be assigned again inside that method.

A final instance field may have a field initializer, an instance initializer, or an assignment in every constructor path. A final static field may have a field initializer or an assignment in a static initializer.

For a primitive variable, final prevents replacing the primitive value. For an object reference, final prevents assigning a different reference. It does not make the object immutable. A final ArrayList reference can still be used to add or remove elements because the list itself remains mutable.

A final method may be inherited, but a subclass cannot override it. The method may still be overloaded with a different parameter list. A final class cannot be extended.

Final normally adds no separate object allocation, copying, or meaningful memory cost. It is mainly a compile time language rule. Final instance fields also receive special initialization visibility guarantees under the Java Memory Model when the object is constructed correctly and does not escape during construction. This does not make a mutable object thread safe.

Use final to communicate stable assignments, protect required method behavior, and prevent unsupported inheritance. Do not use it as a substitute for immutability, synchronization, or careful class design.

A common mistake is saying that a final object cannot change. Final protects the variable that stores the reference, not the mutable object behind it. Another mistake is saying that every final variable must be assigned on its declaration line. A blank final variable may be assigned later when Java can prove that it is assigned exactly once. Developers may also confuse final with finally or finalize, which have different meanings. Final does not automatically provide deep immutability, thread safety, or a performance improvement. A private method cannot be overridden because it is not inherited, so final adds no useful overriding protection to that method.

Explain final in three parts. A final variable cannot be assigned again, a final method cannot be overridden, and a final class cannot be extended. Then state the key limitation that a final reference does not make a mutable object immutable.

The static keyword makes a member belong to the class instead of to each object. A static field has one shared value for each loaded copy of the class, and a static method can be called with the class name without creating an object. A static method has no current object, so it cannot directly use this, instance fields, or instance methods.

The static keyword is useful when a value or action should be shared by all objects of one class. Java keeps one shared value instead of giving every object a separate copy. For example, each user can have a different name, while one shared number records how many users were created. A shared action can also run without first creating an object. This is helpful for common values, simple helper actions, and information that describes the whole group rather than one item. It should be used carefully when the shared value can change.

1. Should I explain static fields, static methods, static initialization, and method hiding?
2. Should I include thread safety and class loader behavior for shared static state?

A static member belongs to the class rather than to an individual object. It is normally accessed with the class name, such as User.getCount(). An object does not need to be created before a static method or field can be accessed, although the class must be initialized before its static members are used as required by Java initialization rules.

A static field has one value for each loaded Class object. Every instance using that same loaded class sees the same field. This is useful for constants, shared counters, cached metadata, and values that describe the class as a whole. A constant is commonly declared static and final because it belongs to the class and cannot be reassigned after initialization.

A static method also belongs to the class. It has no current object, so it cannot directly access this, instance fields, or instance methods. It can directly access static members. An instance method can access both instance members and static members because it has a current object.

Static methods are hidden rather than overridden. When a parent class and child class declare static methods with the same signature, the selected method depends on the declared reference type or class name, not on the runtime object type.

Mutable static state requires care in production. Threads using the same loaded class share the field, so compound updates such as count plus plus are not automatically safe. Synchronization, locks, or atomic classes may be needed. Static references can also keep objects reachable for the lifetime of the class loader. Separate class loaders and separate Java processes have separate static state.

A common mistake is thinking that every object receives its own static field. Objects using the same loaded class share that field. Another mistake is calling a static method through an object reference. Java allows this, but the call is still resolved as a class method and the syntax hides its real ownership. Developers may also expect a static method to access this or instance data directly, but no current object exists. Other mistakes include treating hidden static methods as overridden methods, using mutable static state without thread safety, and assuming static state is shared across class loaders or Java processes.

Start by saying that static means the member belongs to the class. Then explain fields and methods separately. Mention that static methods have no current object, static methods are hidden rather than overridden, and mutable static fields require careful thread safety and lifecycle management.

The main difference is that this refers to the current object, while super selects members and constructors from the direct superclass. I use this to access current object fields and methods or to call another constructor in the same class. I use super to access an inherited visible field, call the superclass version of an overridden method, or invoke a superclass constructor. Neither keyword can be used to access the current object from a static context.

The keyword this means the object whose constructor or instance method is currently running. The keyword super tells Java to use a visible field, method, or constructor from the direct parent class. These keywords are useful when a class and its parent use the same names. They also help constructors initialize an object in the required order. This does not create a new object, and super does not represent a separate parent object. Both keywords work with the one object that is being used or created.

1. Should I explain fields and overridden methods?
2. Should I include constructor chaining?
3. Should I compare the Java 21 and Java 25 constructor rules?

Inside an instance method or constructor, this refers to the current object. For example, this.name selects the name field of that object. It is often used when a parameter hides a field name, as in this.name = name. The left side is the object field, and the right side is the parameter.

A call such as this.describe() invokes a method on the current object. Normal dynamic method selection still applies. Therefore, Java can run an overriding method based on the actual object type.

Super is not a separate object reference that can be stored or passed around. It is a keyword that selects the direct superclass context. Super.name accesses an inherited visible field when a child field hides it. Super.describe() calls the direct superclass implementation instead of the overriding implementation in the child. Super cannot directly access a private superclass member.

In a constructor, this(...) invokes another constructor in the same class. Super(...) invokes a constructor of the direct superclass. A constructor can contain only one explicit constructor invocation, and constructor chains must eventually reach a superclass constructor. A recursive this(...) chain is a compile time error.

In Java 21, this(...) or super(...) must be the first constructor statement. Java 25 finalized flexible constructor bodies, so permitted statements may appear before that invocation. Code in this early construction section cannot read the object being constructed or call its instance methods. If no explicit invocation is written, Java implicitly invokes super() when allowed. Compilation fails if the direct superclass has no accessible constructor with no arguments.

These keywords perform selection and invocation. They do not copy or allocate another object. Their direct memory cost is zero, and their direct performance cost is negligible beyond the normal field access, method call, or constructor call being performed.

Common mistakes include treating super as a separate parent object, trying to store or pass super as a value, and using this or super for current object access in a static context. Another mistake is assuming super can directly access private superclass members. Candidates may also confuse field hiding with method overriding. Fields are selected using the declared context of the access, while overridden instance methods normally use dynamic method selection. A super method call explicitly selects the direct superclass implementation. It is also incorrect to state that a constructor invocation must always be the first statement in Java 25, because Java 25 permits a restricted early construction section.

Start with one clear sentence: this refers to the current object, while super selects the direct superclass context. Then explain one field example, one overridden method example, and constructor chaining. Mention that Java 21 requires the constructor invocation first, while Java 25 permits restricted statements before it.

An array has a fixed length after creation, while an ArrayList can grow or shrink as elements are added or removed. Arrays can store primitive values or object references. An ArrayList stores object references, so primitive values use wrapper types such as Integer. I use an array when the number of items is known and stable, and an ArrayList when the size can change or List methods make the code easier to maintain.

The practical choice depends on whether the number of values can change. An array is like a row of numbered spaces created with a fixed count. After creation, that count cannot change, although the values inside the spaces can change. An ArrayList is a flexible group of values. It can grow when new values arrive and become smaller when values are removed. Both keep values in order and let you reach a value by its position. The main decision is whether you need a stable size or easy changes to the group.

1. Is the number of values known in advance?
2. Will values often be added or removed?
3. Do we need to store primitive values directly?

An array has a fixed length. For example, new int[3] always has three positions. You can replace values in those positions, but you cannot add a fourth position. To use a different length, you must create another array and copy the required values into it.

An ArrayList is a class from the Java collections library. It stores its elements in an internal array. When that internal array has no free capacity and another element is added, the ArrayList allocates a larger internal array and copies the existing element references into it. This growth is automatic, but the addition that triggers it costs more time and memory than a normal addition.

Arrays can store primitives directly, such as int, double, and boolean. They can also store object references. An ArrayList stores object references and uses generic types, such as ArrayList<Integer>. Java often converts between int and Integer automatically, but wrapper objects can require more memory than primitive values.

Both arrays and ArrayList provide constant time access by index. Replacing an existing element by index is also constant time. Adding to the end of an ArrayList is constant time on average across many additions. Adding or removing near the beginning or middle takes linear time because later elements must shift.

Reference arrays and ArrayList can contain null. Primitive arrays cannot. Neither type is automatically thread safe.

Use an array when the size is known, direct primitive storage matters, or an API requires an array. Use an ArrayList when the size changes and methods such as add, remove, contains, and clear improve readability and maintenance.

A common mistake is saying that an array is immutable. Its length is fixed, but its elements can usually be changed. Another mistake is saying that ArrayList stores primitives directly. It stores object references, so primitive values use wrapper types. Candidates also forget that ArrayList growth can allocate another internal array and copy existing references. Another mistake is using remove(1) on an ArrayList<Integer> while intending to remove the value one. That call removes the element at index one. Using remove(Integer.valueOf(1)) removes the first matching value. It is also incorrect to assume that either type is automatically thread safe.

Start with fixed length versus flexible size. Then mention primitive storage, index access, automatic resizing, shifting costs, and the practical rule for choosing between them.

The Java Collections Framework is the standard JDK set of interfaces and classes for storing and working with groups of objects. Iterable supports iteration. Collection is the main interface for groups of elements, with List, Set, Queue, and Deque below it. Map is separate because it stores key and value pairs. I choose a collection based on whether I need ordering, duplicates, fast lookup, queue behavior, mutation, thread safety, and the expected amount of data.

In Java, we often need to keep many values together and perform common actions such as adding, removing, finding, or visiting them. Java provides a standard group of ready made tools for this job. Different tools have different rules. Some keep items in a specific order. Some prevent repeated items. Some connect one value to another value for quick finding. Some are designed for processing items from one end or both ends. The main skill is choosing the tool whose behavior matches the problem instead of using the same tool everywhere.

1. Should I explain the main interfaces as well as common implementations?
2. Would you like me to compare their ordering, duplicate, and lookup behavior?

The Java Collections Framework is a set of JDK interfaces, implementations, and algorithms for working with groups of objects.

Iterable is the basic interface for something that can provide an Iterator, which lets code visit elements one at a time. Collection extends Iterable and represents a group of elements.

List keeps elements in sequence and allows duplicates. ArrayList is a common implementation. It gives fast indexed access and is usually a good choice when reads are common and inserts in the middle are not frequent.

Set represents unique elements. HashSet is a common implementation. It uses hashing and normally gives fast add, remove, and contains operations. It does not promise iteration order.

Queue represents elements waiting to be processed. Deque extends Queue and supports adding or removing from both ends. ArrayDeque is a common choice for a queue or stack. It does not allow null elements.

Map is part of the framework but does not extend Collection. It stores key and value pairs. HashMap is a common implementation. Each key is unique, while values can repeat. It allows one null key and null values.

The correct choice depends on ordering, duplicates, lookup needs, how often data changes, concurrency needs, and expected data size. Standard ArrayList, HashSet, HashMap, and ArrayDeque are not generally safe for unsynchronized concurrent modification by multiple threads.

A common mistake is saying that Map extends Collection. It does not. Another mistake is assuming HashSet or HashMap keeps insertion order. Their iteration order is not guaranteed. Candidates may also assume every collection allows null, but ArrayDeque does not. Another mistake is choosing ArrayList for frequent insertion near the front without considering element movement. It is also incorrect to assume ordinary ArrayList, HashSet, HashMap, or ArrayDeque automatically makes concurrent modification by multiple threads safe.

Start with the purpose of the framework, then explain the interface relationships in a simple order. Mention that Map is separate from Collection. Give one practical example for ArrayList, HashSet, HashMap, and ArrayDeque. Finish by saying that the right choice depends on ordering, duplicates, lookup needs, mutation, concurrency, and data size.

I would choose ArrayList for most applications because it gives constant time indexed access, usually uses less memory, and normally iterates efficiently. LinkedList stores every element in a separate node with references to the previous and next nodes. Indexed access is therefore linear time. LinkedList can add or remove an element in constant time when the required node is already known, but finding that node can still take linear time.

Both classes keep items in order and let the program add, read, replace, or remove them. The main difference is how they arrange those items in memory. ArrayList keeps item references together in one growing container. LinkedList gives every item its own holder and connects the holders. This changes how quickly the program can reach an item, move items, and change the beginning or middle of the collection. It also changes how much extra memory is used. The best choice depends on which operations the program performs most often.

1. Will the code frequently read or replace an element by its position?
2. Will additions and removals happen mainly at the end, beginning, or middle?
3. Will the code already have an Iterator positioned at the element being changed?
4. Are memory use and iteration speed important?

ArrayList stores element references in a resizable array. Because an array supports direct indexed access, get and set are O(1). Adding at the end is amortized O(1). Most additions are fast, but an addition that exceeds the current capacity can allocate a larger array and copy the existing references, making that individual operation O(n). Inserting or removing near the beginning or middle is O(n) because later references must shift.

LinkedList is a doubly linked list. Each node stores an element reference plus references to the previous and next nodes. Getting an element by index is O(n) because the implementation must walk from the nearer end. Adding or removing at either end is O(1). Inserting or removing through a ListIterator at an already reached position is also O(1), but reaching that position may require O(n) work.

ArrayList usually uses less memory. It stores one array of references, although the array may contain unused capacity. LinkedList allocates one node per element and keeps two additional node references. Those separate allocations also usually make iteration less friendly to processor caches, so LinkedList is not automatically faster for frequent changes.

Both classes preserve insertion order, allow duplicate elements, and allow null. Neither class is thread safe. Their iterators are fail fast on a best effort basis and must not be treated as a concurrency guarantee.

ArrayList is the normal production default. LinkedList is useful only when its constant time end operations or changes through an already positioned iterator match the workload. For a queue or stack, ArrayDeque is usually a better choice.

A common mistake is saying that every middle insertion or removal in LinkedList is O(1). The link change is O(1) only after the target node has been reached. Calling add with an index, remove with an index, or searching for a value still requires a traversal and is O(n). Another mistake is assuming LinkedList uses less memory. It normally uses more because each element requires a node and two additional node references. Candidates also forget that ArrayList growth occasionally copies references, confuse fail fast iteration with thread safety, or choose LinkedList for a queue when ArrayDeque is usually more suitable.

Begin with the practical choice that ArrayList is the usual default. Then explain that ArrayList uses a resizable array while LinkedList uses connected nodes. Compare indexed access, end operations, middle changes, memory, and iteration. Clearly qualify that LinkedList gives constant time insertion or removal only after the required node has already been reached.

I use HashSet when I need fast membership checks and do not need sorted iteration. Its basic operations have expected O(1) time when hash values are distributed well, but it does not guarantee iteration order. I use TreeSet when elements must remain sorted or when I need navigation and range operations. Its basic operations take O(log n) time. HashSet permits one null element. TreeSet can accept null only when its Comparator explicitly supports null values.

Both classes store unique values, but they organize those values differently. HashSet is usually the better choice when the order does not matter and the program mainly needs to check whether a value exists. TreeSet is useful when values must remain sorted or when the program must find values near a given value. This choice affects lookup speed, iteration order, null handling, memory use, and the rules used to decide whether two values are duplicates.

1. Must the values be returned in sorted order?
2. Does the code need range or nearest value searches?
3. Can the collection contain null?
4. Is faster average lookup more important than sorted access?

HashSet implements Set and is backed by a HashMap. It uses hashCode to select a storage location and equals to determine whether an equal element is already present. The add, contains, and remove operations have expected O(1) time when hash values are distributed well. The API does not guarantee constant time for every possible input.

HashSet does not guarantee iteration order. Its order can change when the set changes or when the program runs in a different environment. It permits one null element because its backing HashMap permits a null key.

TreeSet implements NavigableSet and is backed by a TreeMap. It keeps elements sorted by their natural ordering or by a Comparator supplied when the set is created. Its add, contains, and remove operations have guaranteed O(log n) time.

TreeSet provides navigation methods such as lower, higher, floor, and ceiling. It also provides range views through headSet, tailSet, and subSet. These operations are useful when the application needs sorted traversal, nearest values, or values within a boundary.

TreeSet decides that two elements are duplicates when compareTo or the Comparator returns zero. This can differ from equals, so the ordering should normally be consistent with equals. A TreeSet using natural ordering rejects null. A TreeSet with a Comparator can accept null only when that Comparator supports comparing null values.

Neither collection is thread safe. Objects stored in either set should not change fields used by equals, hashCode, compareTo, or the Comparator while they remain in the set.

A common mistake is assuming that HashSet preserves insertion order. LinkedHashSet is the usual choice when predictable encounter order is required. Another mistake is expecting TreeSet to use equals for duplicate detection. TreeSet uses compareTo or its Comparator, and a comparison result of zero means the values are duplicates. Developers also sometimes change an object after insertion in a way that changes its hash or ordering. This can make contains or remove fail and can break the logical structure of the set. Another mistake is assuming that TreeSet always rejects null. A Comparator that explicitly supports null can allow it, while natural ordering cannot. Neither collection should be modified concurrently without suitable coordination.

Start with the decision rule. Say HashSet is for fast expected membership checks without sorted order, while TreeSet is for sorted values, navigation, and range operations. Then compare expected O(1) with guaranteed O(log n), explain null handling, and mention that TreeSet treats a comparison result of zero as a duplicate.

I normally use HashMap when the map is confined to one thread or when access is coordinated elsewhere. Hashtable is a legacy class whose main map operations synchronize on the Hashtable instance. That protects individual operations, but it does not automatically make a sequence of operations atomic. HashMap allows one null key and multiple null values, while Hashtable allows neither. For a map shared by many threads, ConcurrentHashMap is usually the better modern choice.

These two choices both store information so a value can be found by a matching name or object. The practical difference is safety when several parts of a program use the same data at once. The older choice protects each basic action by itself, but that does not protect a longer group of actions. The newer common choice does not add that protection automatically. They also treat missing references differently. One accepts them, while the older one rejects them. In modern programs, another shared data option is usually better when many workers update the data together.

1. Will several threads read and update the same map?
2. Must the map accept null keys or null values?
3. Must several map operations happen as one atomic action?

HashMap and Hashtable both implement Map and store key and value pairs by using each key's hashCode and equals methods.

HashMap is the normal general purpose choice. It does not synchronize its operations. Multiple threads may read an unchanged HashMap after it has been published safely, but concurrent structural changes require external coordination. Without that coordination, behavior is not safe or predictable.

Hashtable is a legacy class. Its main map operations synchronize on the Hashtable instance. Only one thread at a time can execute those synchronized operations on the same instance. This adds lock contention. It also protects only one method call at a time. A sequence such as checking for a key and then inserting a value is not automatically atomic. The caller must lock the complete sequence on the same Hashtable instance, or use an atomic operation from a suitable concurrent map.

HashMap permits one null key and multiple null values. Hashtable throws NullPointerException when given a null key or null value.

Both maps normally provide constant time lookup, insertion, and removal when keys have well distributed hash codes. Poor hash distribution can make operations slower. HashMap and Hashtable both use memory proportional to the number of entries. They store references to keys and values rather than copying those objects. Resizing allocates a larger bucket array and redistributes stored entries.

HashMap iterators are fail fast on a best effort basis. Hashtable collection view iterators have similar behavior. Hashtable also provides the older Enumeration API, which is not fail fast.

For modern shared access, ConcurrentHashMap is usually preferred because it supports safe concurrent operations with better scalability than one instance wide lock. Hashtable is mainly useful when maintaining an older API that specifically requires it.

A common mistake is saying that Hashtable makes every use of the map thread safe. Its synchronization protects individual method calls, not a sequence such as check then insert. Another mistake is choosing Hashtable whenever several threads exist without considering ConcurrentHashMap. Candidates also forget that Hashtable rejects both null keys and null values, while HashMap permits one null key and multiple null values. It is also incorrect to treat fail fast iteration as a guaranteed way to detect every concurrent modification.

Start with the practical choice. Say that HashMap is the normal modern map, Hashtable is a synchronized legacy class, and ConcurrentHashMap is usually preferred for shared concurrent access. Then explain null handling and why synchronized individual methods do not make compound actions atomic.

HashMap is not thread safe, so I use it when one thread owns the map or when all access is protected by external synchronization. ConcurrentHashMap is designed for safe access by multiple threads and allows reads and updates with much less contention than locking one entire map. HashMap allows one null key and null values, while ConcurrentHashMap allows neither. For shared state, I use atomic methods such as putIfAbsent, compute, or merge instead of separate check and update calls.

The practical choice depends on whether several workers can use and change the same collection at the same time. A regular map is simpler when one worker owns it. A concurrent map is safer when many workers share it. It prevents overlapping changes from damaging the collection or producing unsafe access. It also provides operations that perform a check and an update as one action. This matters because another worker could otherwise change the data between those two steps and cause a lost or incorrect update.

1. Will multiple threads read or update the same map?
2. Must a check and an update happen as one atomic operation?
3. Does the application need null keys or null values?
4. Can iteration happen while other threads update the map?

HashMap is not thread safe. Multiple threads may read the same HashMap only when no thread modifies it and the map has been safely published. Unsynchronized concurrent updates can cause lost updates, stale observations, or inconsistent behavior.

ConcurrentHashMap is thread safe for its documented operations. Retrieval operations normally do not block. Updates use internal coordination only where needed instead of locking the entire map for every operation. The exact mechanism is a JDK implementation detail, so code should rely on the API guarantees rather than assumptions about internal locks.

Both maps normally provide average O(1) get and put performance when keys have suitable hash values. ConcurrentHashMap pays extra coordination cost for thread safety. A HashMap is therefore usually the simpler and lower cost choice for thread confined data. Under real shared access, ConcurrentHashMap usually scales better than protecting one HashMap with one large lock.

HashMap permits one null key and multiple null values. ConcurrentHashMap rejects null keys and null values. This lets a null result from get clearly indicate that no value is currently mapped to the key.

HashMap iterators are fail fast on a best effort basis and may throw ConcurrentModificationException after an unsupported structural change. ConcurrentHashMap iterators are weakly consistent. They do not throw that exception because of concurrent updates, but they are not fixed snapshots and may observe some updates while iteration is running.

Methods such as putIfAbsent, computeIfAbsent, compute, and merge provide atomic map operations. A separate containsKey followed by put is not atomic. ConcurrentHashMap protects one map instance inside one JVM. It does not coordinate separate application processes or replicas.

A common mistake is assuming that a final HashMap reference makes the map thread safe. Final prevents reassignment of the reference, but it does not protect changes to the map. Another mistake is using containsKey followed by put on ConcurrentHashMap and assuming the pair is atomic. Each call is safe by itself, but another thread can act between them. Developers may also assume that a ConcurrentHashMap iterator is a fixed snapshot. It is weakly consistent and may observe some concurrent changes. Another mistake is expecting thread safety of the map to make a larger business operation atomic. Several related map calls may still require explicit coordination. ConcurrentHashMap may also use more memory than HashMap because concurrency support can require additional bookkeeping. The exact difference is implementation and workload dependent.

Start with the decision rule. Use HashMap for thread confined data or data protected by external synchronization. Use ConcurrentHashMap for shared concurrent access. Then compare atomic operations, null handling, iteration behavior, performance, memory cost, and the fact that thread safe individual methods do not make every sequence of calls atomic.