Collections Framework

Internally, ArrayList holds an Object[]. When add() would exceed the array's length, it allocates a new array — by default 1.5× the old capacity (oldCapacity + (oldCapacity >> 1)) — copies every element over with Arrays.copyOf, and the old array becomes garbage. This makes a single add() occasionally O(n), but amortized O(1) across many additions, since resizes become exponentially rarer.

If you know the approximate final size upfront, pass it to the constructor (new ArrayList<>(1000)) to avoid repeated resize-and-copy churn.

Two keys with different content can hash to the same bucket (a collision) — HashMap handles this by chaining: all entries that land in the same bucket are linked together (a list, or a red-black tree once the chain gets long — see the treeification question). On lookup, HashMap walks that bucket's chain and uses each candidate key's equals() to find the actual match, since a shared bucket doesn't necessarily mean the keys are equal.

Load factor (default 0.75) is the fraction full a HashMap can get before it resizes: threshold = capacity × loadFactor. Once size exceeds that threshold, the map rehashes — it doubles the bucket array's capacity and re-distributes every existing entry into the new, larger array (since the bucket index formula depends on capacity, old bucket assignments are no longer valid).

A lower load factor means more buckets (faster average lookups, more wasted memory); a higher load factor packs more into fewer buckets (less memory, more collisions/chaining). 0.75 is a measured middle ground the JDK authors chose as a good general-purpose default.

It's thrown when you structurally modify a fail-fast collection (add/remove an element) while iterating over it with a for-each loop or an Iterator whose modCount snapshot no longer matches — most commonly, calling list.remove(x) directly inside a for (String s : list) loop.

for (String s : list) {
    if (s.isEmpty()) list.remove(s); // modifies the list mid-iteration
}

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    if (it.next().isEmpty()) it.remove(); // iterator tracks its own modCount
}
// or, since Java 8:
list.removeIf(String::isEmpty);

HashSet is a thin wrapper around a HashMap: every element you add becomes a key in an internal map, mapped to a shared dummy constant value. Set semantics (no duplicates, O(1) contains) fall straight out of Map key semantics — you get them for free.

private static final Object PRESENT = new Object();
private transient HashMap<E, Object> map = new HashMap<>();

public boolean add(E e) {
    return map.put(e, PRESENT) == null; // true if e wasn't already a key
}

PriorityQueue is backed by a binary heap stored in a plain array (a min-heap by default — smallest element via compareTo/Comparator always at the root/index 0). offer() appends at the end then "bubbles up" to restore the heap property; poll() removes the root, moves the last element to the root, and "sifts down" — both O(log n). It gives O(1) peek at the minimum, which is the whole point of a priority queue: cheap access to "what's next," not full sorted iteration order.

The legacy Stack class extends Vector — it inherits a pile of irrelevant list methods (get(i), insertElementAt...) that let code violate stack discipline, and every method is synchronized even in single-threaded use, adding pure overhead. ArrayDeque implements Deque and gives you push/pop/peek with array-backed performance and no synchronization tax — the JDK docs themselves recommend it over Stack.

Java 9 added List.of(...), Set.of(...), and Map.of(...) factory methods that return genuinely immutable collections. The older approach, Collections.unmodifiableList(list), only wraps an existing mutable list — the wrapper itself rejects modifications, but the underlying list can still be changed through the original reference (and those changes show through the wrapper).

List<Integer> nums = List.of(1, 2, 3);
nums.add(4); // throws UnsupportedOperationException

Two options: make the class implement Comparable<T> for one natural ordering, or pass a Comparator<T> (often a lambda or method reference) when you need a different/custom order without touching the class.

// Natural ordering
class Employee implements Comparable<Employee> {
    int salary;
    public int compareTo(Employee o) { return Integer.compare(salary, o.salary); }
}
Collections.sort(employees); // uses compareTo

// Custom ordering, no change to Employee needed
employees.sort(Comparator.comparingInt((Employee e) -> e.salary).reversed());

Queue is FIFO — you add at the tail (offer) and remove from the head (poll). Deque ("double-ended queue") extends that to allow adding/removing at both ends, so it can act as a FIFO queue, a LIFO stack, or both at once — which is why ArrayDeque is the modern replacement for both LinkedList-as-a-queue and the legacy Stack class.

HashMap allows exactly one null key (stored in bucket 0, since there's no hash to compute) and any number of null values. Hashtable (and ConcurrentHashMap) allow neither — they throw NullPointerException on a null key or value, largely because in a concurrent map, a null return from get() would be ambiguous: does it mean "key not present" or "key present with a null value"? Disallowing null sidesteps that ambiguity entirely.