Java Collections Framework

Iterable -> Collection -> List, Set, Queue (and Deque extends Queue). Map is a separate hierarchy and does not extend Collection.

• List: ordered, indexed, duplicates allowed (ArrayList, LinkedList).
• Set: no duplicates (HashSet, LinkedHashSet, TreeSet); SortedSet -> NavigableSet.
• Queue/Deque: head/tail operations (PriorityQueue, ArrayDeque, LinkedList).
• Map: key-value (HashMap, LinkedHashMap, TreeMap); SortedMap -> NavigableMap.

ArrayList is backed by a resizable array: O(1) random access, amortized O(1) append, O(n) insert/remove in the middle. LinkedList is a doubly linked list: O(1) insert/remove at a known node or the ends, but O(n) access by index.

• In practice ArrayList wins almost always: contiguous memory is cache friendly and each LinkedList node costs ~24 extra bytes (header + prev + next + item reference).
• LinkedList implements Deque too, but ArrayDeque is usually faster for that role.

The default constructor starts with an empty shared array and allocates capacity 10 on first add. When full it grows to old + (old >> 1), i.e. 1.5x, by copying with Arrays.copyOf.

• Use new ArrayList<>(n) or ensureCapacity when the size is known to avoid repeated copying.
• trimToSize() releases unused slots.

HashMap keeps an array of buckets (Node<K,V>[] table). The key's hashCode() is spread, masked to an index, and the entry is stored in that bucket as a linked list (or a red-black tree when large). Lookup compares hash then equals.

• Index = (n - 1) & hash where n is a power of two.
• Spread function: h ^ (h >>> 16) mixes high bits into low bits.
• Default capacity 16, load factor 0.75.
• Allows one null key and many null values; not thread-safe.

Resize happens when size > threshold, where threshold = capacity * loadFactor (12 for the default 16 x 0.75). The table doubles and entries are redistributed.

• Higher load factor saves memory but increases collisions; lower speeds lookups but wastes memory.
• Resize is O(n) and happens on the writing thread.

Because capacity doubles, each entry either stays at index i or moves to i + oldCap, decided by one bit: (hash & oldCap) == 0. Java 8 splits each bucket into a "lo" and "hi" list preserving relative order.

• Java 7 re-inserted nodes at the head of the new bucket, which reversed order and could create a cycle (infinite loop) when two threads resized concurrently.
• Java 8 preserves order, so the classic cyclic-list hang is gone, but concurrent use is still unsafe (lost updates, corrupted tree).
• Java 8 also appends new nodes at the tail and adds treeification.

When a single bucket reaches TREEIFY_THRESHOLD = 8 nodes and the table has at least MIN_TREEIFY_CAPACITY = 64 slots, the list becomes a red-black tree, bounding worst-case lookup at O(log n) instead of O(n).

• If the table is smaller than 64, HashMap resizes instead of treeifying.
• Trees untreeify when they shrink to UNTREEIFY_THRESHOLD = 6 (during resize split/removal).
• Tree ordering uses hashCode, then Comparable if the keys implement it, then a tie-break by identity hash; non-comparable keys make lookups in a tree bucket slower.

Equal objects must return equal hash codes; hash code must be stable while the object is a key. If a field used in hashCode changes after insertion, the entry sits in the wrong bucket and becomes unreachable.

• Override both together; use the same fields in both.
• Prefer immutable keys (String, Integer, records, enums).
• Unequal objects may share a hash code (collisions are legal, just slow).

HashSet wraps a HashMap; elements are the keys and every value is a shared dummy object PRESENT. add returns true if map.put(e, PRESENT) == null.

• Same complexity and resize behaviour as HashMap.
• Allows one null; iteration order is unspecified.

HashSet: no order, O(1). LinkedHashSet: insertion order, O(1), extra memory for a linked list. TreeSet: sorted order by Comparable/Comparator, O(log n), backed by a TreeMap.

• TreeSet uses compareTo/compare for equality, not equals.
• TreeSet rejects null (with natural ordering) and offers floor, ceiling, headSet, tailSet, descendingSet.

HashMap: unordered, O(1), nulls allowed. LinkedHashMap: insertion (or access) order, O(1). TreeMap: sorted by key, O(log n), no null keys with natural ordering. Hashtable: legacy, synchronized on every method, no nulls.

• For thread safety use ConcurrentHashMap, not Hashtable or synchronizedMap for high contention.

Construct with accessOrder = true so get/put move the entry to the tail; override removeEldestEntry to evict the head when size exceeds a limit.

class LruCache<K, V> extends LinkedHashMap<K, V> {
    private final int max;
    LruCache(int max) { super(16, 0.75f, true); this.max = max; }
    @Override protected boolean removeEldestEntry(Map.Entry<K, V> e) {
        return size() > max;
    }
}

• Not thread-safe; wrap with Collections.synchronizedMap or use Caffeine for production.

TreeMap is a red-black tree implementing NavigableMap. get, put, remove, containsKey are O(log n); keys are ordered by Comparable or a supplied Comparator.

• Navigation: firstKey, lastKey, floorKey, ceilingKey, higherKey, lowerKey, subMap, headMap, tailMap, descendingMap.
• Key equality is defined by compare == 0, so an inconsistent comparator violates the Map contract.
• Not synchronized; ConcurrentSkipListMap is the concurrent sorted alternative.

Use them whenever keys/elements are of one enum type. EnumMap is an array indexed by ordinal(), EnumSet is a bit vector (RegularEnumSet for <= 64 constants, a long[] otherwise).

• Faster and smaller than HashMap/HashSet; iteration follows enum declaration order.
• Null keys are rejected; not thread-safe.
• Iterators are weakly consistent (no ConcurrentModificationException).

PriorityQueue is an array-backed binary min-heap. offer/poll are O(log n), peek is O(1), remove(Object) and contains are O(n).

• Ordering from Comparable or Comparator; head is the least element.
• Iteration and toString do not return sorted order, only heap array order.
• Not thread-safe (PriorityBlockingQueue is); no null elements; not stable for equal priorities.
• Building from a collection uses O(n) heapify.

Prefer ArrayDeque for both stack (push/pop) and queue (offer/poll) use: it is a resizable circular array, faster than LinkedList and without the Vector synchronization of legacy Stack.

• ArrayDeque rejects null (null is the empty sentinel for poll/peek); LinkedList allows it.
• Capacity is always a power of two; no index access.
• Stack extends Vector, is synchronized and exposes list operations that break LIFO discipline.

Each operation has a throwing and a non-throwing form: add/offer, remove/poll, element/peek. Throwing forms raise IllegalStateException (full) or NoSuchElementException (empty); the others return false or null.

• For bounded queues, offer returns false when full; blocking queues add put/take and timed offer/poll.

Fail-fast iterators (ArrayList, HashMap, HashSet) check modCount and throw ConcurrentModificationException on detected structural change. "Fail-safe" (more precisely weakly consistent or snapshot) iterators never throw it.

• CopyOnWriteArrayList: iterator works on an immutable snapshot, never sees later changes.
• ConcurrentHashMap: weakly consistent, may or may not reflect updates made after creation.
• Fail-fast is best effort, not a guarantee; do not rely on it for correctness.

The iterator's expected modCount differs from the collection's after a structural change made outside the iterator (add/remove during a for-each). Avoid it with Iterator.remove(), removeIf, collecting items to remove first, or a concurrent collection.

list.removeIf(s -> s.isEmpty());          // preferred
for (Iterator<String> it = list.iterator(); it.hasNext();)
    if (it.next().isEmpty()) it.remove();  // also safe

Comparable<T> defines the natural ordering inside the class (compareTo). Comparator<T> is an external, pluggable ordering (compare), so a type can have many.

people.sort(Comparator.comparing(Person::lastName)
        .thenComparing(Person::firstName)
        .thenComparingInt(Person::age));

• compareTo should be consistent with equals (strongly recommended), especially for TreeSet/TreeMap.

compare(a, b) == 0 iff a.equals(b). When violated, sorted collections use the comparator for identity, so they behave differently from hash-based collections.

• BigDecimal("1.0") and BigDecimal("1.00") are not equals but compareTo == 0: a TreeSet keeps one, a HashSet keeps both.

Yes for object sorting: List.sort, Collections.sort, and Arrays.sort(T[], Comparator) use TimSort (stable merge/insertion hybrid, O(n log n), near O(n) on presorted data). Arrays.sort(int[]) uses dual-pivot quicksort, which is not stable (stability is irrelevant for primitives).

• Stability allows multi-key sorting by sorting on the minor key first.
• Stream.sorted() is stable for ordered streams.

Collections.unmodifiableList(l) is a read-only view: changes to the backing list show through. List.copyOf / List.of are truly immutable (no backing, no mutators). Both are shallow: elements themselves can be mutable.

• Collections.synchronizedList wraps every method with a mutex; iteration still needs manual synchronized (list).
• Immutable factories (Java 9+) reject null.

They return compact immutable collections: mutators throw UnsupportedOperationException, nulls throw NullPointerException, Set.of/Map.of throw IllegalArgumentException on duplicates, and Set/Map iteration order is unspecified and varies per JVM run (randomized salt).

• Map.of supports up to 10 pairs; use Map.ofEntries(Map.entry(...)) for more.
• contains(null) on a List.of throws NPE, unlike ArrayList.

A fixed-size List view over the array (Arrays$ArrayList). set writes through to the array; add and remove throw UnsupportedOperationException.

• Arrays.asList(int[]) yields List<int[]> of size 1, since primitives do not autobox into varargs.
• Wrap with new ArrayList<>(Arrays.asList(...)) for a growable copy.

subList(from, to) is a live view of the parent. Writes go through both ways; structurally modifying the parent afterwards makes the view throw ConcurrentModificationException on next use.

• Idiom: list.subList(a, b).clear() removes a range efficiently.
• A long-lived subList retains the whole parent (memory leak); copy with new ArrayList<>(list.subList(a, b)).

sort, reverse, shuffle, binarySearch (requires sorted list), max/min, frequency, swap, rotate, nCopies, emptyList, singletonList, unmodifiableXxx, synchronizedXxx, disjoint, addAll, reverseOrder.

• emptyList() and singletonList() return immutable shared instances.
• binarySearch on an unsorted list gives undefined results; on LinkedList it degrades to O(n) steps.

Average costs:

• ArrayList: get O(1), add end O(1) amortized, add/remove middle O(n), contains O(n).
• LinkedList: get O(n), add/remove ends O(1), contains O(n).
• HashMap/HashSet: get/put/contains O(1) average, O(log n) worst case once a bucket is treeified (O(n) only for a long chain below the treeify threshold).
• TreeMap/TreeSet: O(log n).
• PriorityQueue: offer/poll O(log n), peek O(1), remove(Object) O(n).
• ArrayDeque: ends O(1).

Collections store references, so List<Integer> costs about 4-8 bytes per slot (compressed oops) plus 16 bytes per Integer object outside the cache, versus 4 bytes for int[].

• HashMap.Node is ~32 bytes (header 12, hash 4, key, value, next refs, aligned) on top of the table slot; HashMap<Integer,Integer> is roughly 70+ bytes per entry including boxed key/value.
• TreeMap.Entry is ~40 bytes; LinkedList.Node ~24 bytes.
• Remedies: primitive arrays, EnumMap, specialized libraries (Eclipse Collections, fastutil), right-sized capacity.

Pass an initial capacity of ceil(N / 0.75) so no resize occurs. new HashMap<>(N) is wrong because it resizes once N exceeds 0.75*N rounded to a power of two.

int cap = (int) Math.ceil(n / 0.75);
Map<String, Integer> m = new HashMap<>(cap);
// Java 19+: HashMap.newHashMap(n)

• The constructor rounds capacity up to the next power of two via tableSizeFor.
• The table is allocated lazily on first put.

String.hashCode is s[0]*31^(n-1) + ... + s[n-1] (cached). List.hashCode combines element hashes the same 31-based way. Use Objects.hash(a, b) (allocates a varargs array) or let a record generate equals/hashCode/toString.

record Point(int x, int y) {}
Set<Point> s = new HashSet<>(List.of(new Point(1, 2)));
s.contains(new Point(1, 2)); // true

Iterable produces an Iterator (enables for-each). Iterator supports hasNext, next, remove. ListIterator (lists only) adds backward traversal, add, set, nextIndex, previousIndex.

• ConcurrentHashMap: general-purpose concurrent map.
• CopyOnWriteArrayList/CopyOnWriteArraySet: read-heavy, rarely modified (listeners).
• ConcurrentLinkedQueue/Deque: lock-free unbounded.
• BlockingQueue (ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQueue, SynchronousQueue, DelayQueue): producer/consumer.
• ConcurrentSkipListMap/Set: concurrent sorted.

Java 7 used 16 lock-striped Segments (each a ReentrantLock over a mini hash table). Java 8+ removed segments: an empty bucket is filled with a lock-free CAS; otherwise it uses synchronized on the bucket's first node. Resizing is cooperative (multiple threads migrate bins), and bins treeify like HashMap.

• Reads are lock-free (volatile fields); size() uses striped CounterCells (like LongAdder), so it is an estimate under concurrency.
• No null keys or values.

Each mutation copies the backing array under a lock and publishes it via a volatile reference; reads and iterators use the array snapshot without locking.

• Mutation O(n) time and memory; excellent for many readers and rare writers (listener lists).
• Iterators never throw CME but may show stale data and do not support remove.

ArrayBlockingQueue: bounded, one lock, array. LinkedBlockingQueue: optionally bounded (default Integer.MAX_VALUE), separate put/take locks, higher throughput. PriorityBlockingQueue: unbounded heap. SynchronousQueue: zero capacity hand-off. DelayQueue: elements available after a delay. LinkedTransferQueue: transfer waits for consumer.

• Unbounded queues can cause OutOfMemoryError when producers outpace consumers.
• Executors.newFixedThreadPool uses an unbounded LinkedBlockingQueue; newCachedThreadPool uses SynchronousQueue.

JEP 431 adds SequencedCollection, SequencedSet, SequencedMap with a defined encounter order and uniform methods: getFirst, getLast, addFirst, addLast, removeFirst, removeLast, and reversed() (a live reversed view).

• List, Deque, LinkedHashSet, SortedSet (TreeSet) are sequenced; LinkedHashMap and SortedMap implement SequencedMap (firstEntry, lastEntry, pollFirstEntry, putFirst, putLast, sequencedKeySet...).
• HashSet/HashMap are not sequenced.

No, it is a live view. Changes to the original appear in the reversed view and vice versa (for modifiable lists). Copy explicitly when a snapshot is needed.

List<Integer> l = new ArrayList<>(List.of(1, 2, 3));
List<Integer> r = l.reversed();
l.add(4);
System.out.println(r); // [4, 3, 2, 1]

Iteration walks the table from index 0 up, each bucket in chain/tree-next order, so order depends on hash values, capacity and insertion history. It can change after a resize or between JVM versions.

• getOrDefault(k, d): read only, does not insert.
• putIfAbsent(k, v): inserts if absent or mapped to null; returns the old value (eagerly evaluated v).
• computeIfAbsent(k, f): lazy value creation; inserts the result unless null; returns the current value.
• merge(k, v, f): inserts v if absent, else f(old, v); a null result removes the key.
• compute(k, f): full control, null result removes.

Map<String, List<String>> g = new HashMap<>();
g.computeIfAbsent("a", k -> new ArrayList<>()).add("x");
Map<String, Integer> c = new HashMap<>();
for (String w : words) c.merge(w, 1, Integer::sum);

IdentityHashMap compares keys with == and uses System.identityHashCode (graph traversal, serialization, proxies). WeakHashMap holds keys via weak references; entries vanish after the key is garbage collected (canonicalizing caches, metadata).

• A WeakHashMap whose value strongly references its own key never gets cleared.
• Do not use interned strings, boxed small ints or class literals as WeakHashMap keys expecting eviction.

All three are live views of the map. Iterate entrySet() when you need both key and value: it avoids a lookup per key (keySet() + get), which matters for TreeMap (O(log n) per lookup).

• Removing via the view (keySet().remove, values().removeIf, entrySet().removeIf) removes from the map.
• add is unsupported on the views.

List.equals compares element by element in order. Set.equals compares membership regardless of order and implementation; Set.hashCode is the sum of element hashes. Map.equals compares entry sets.

• new ArrayList<>(List.of(1,2)).equals(new LinkedList<>(List.of(1,2))) is true.
• A List never equals a Set, even with the same elements.

List<Integer>.remove(1) calls remove(int index) and removes the element at index 1; remove(Integer.valueOf(1)) removes the first element equal to 1.

List<Integer> is not a List<Number> (generics are invariant). Use ? extends T to read (producer) and ? super T to write (consumer): Producer Extends, Consumer Super.

static <T> void copy(List<? super T> dst, List<? extends T> src) {
    dst.addAll(src);
}

• Raw types skip type checks and permit heap pollution that fails later with ClassCastException.
• Collections.checkedList can enforce types at runtime.

toArray() returns Object[]. toArray(new String[0]) returns a typed array (a new one if the supplied array is too small). Java 11 adds toArray(IntFunction), e.g. list.toArray(String[]::new).

• new String[0] is as fast or faster than presizing on modern JVMs.
• List.of(...).toArray() copies, so the result is mutable.

Stream.toList() (Java 16) returns an unmodifiable list and permits nulls; Collectors.toList() returns an unspecified, typically ArrayList. Collectors.toMap throws IllegalStateException on duplicate keys unless a merge function is given, and rejects null values.

Map<Integer, List<String>> byLen = words.stream()
    .collect(Collectors.groupingBy(String::length));
Map<String, Integer> m = items.stream()
    .collect(Collectors.toMap(Item::id, Item::qty, Integer::sum, LinkedHashMap::new));

A lock-free, sorted, concurrent NavigableMap built on a probabilistic skip list: O(log n) expected for get/put/remove, with weakly consistent iterators. Choose it when multiple threads need sorted access without a global lock.

• size() is O(n).
• For single-threaded use TreeMap has lower overhead.

Individual methods are synchronized on the wrapper, but iteration and compound actions are not atomic; hold the wrapper's lock for the whole traversal.

List<String> l = Collections.synchronizedList(new ArrayList<>());
synchronized (l) {
    for (String s : l) process(s);
}

Concurrent collections' iterators traverse elements as they existed at (or after) creation, never throw CME, and may or may not reflect later updates. Each element is returned at most once.

• Bulk operations (putAll, forEach, size) are not atomic snapshots in ConcurrentHashMap.

emptyList()/singletonList() are immutable singletons that permit null (singleton) and accept contains(null). List.of() rejects null elements and throws on contains(null).

Spliterator traverses and partitions elements, enabling parallel streams. Collections report characteristics (ORDERED, SIZED, SUBSIZED, SORTED, DISTINCT, IMMUTABLE) and split quality.

• ArrayList splits evenly (excellent for parallel); LinkedList splits poorly; HashSet is decent; TreeSet splits by tree structure.

Throws ConcurrentModificationException on the next next() call after the removal. Use l.removeIf(s -> s.equals("a")).

Prints null null 1. The entry is stored in the bucket for hash 1; get(k) now looks in bucket 2, and get(new Key(1)) finds the bucket but equals fails because the stored key has id 2. The entry is leaked and unreachable but still counted.

Almost always 2. hashCode is not overridden, so the two equal objects usually land in different buckets and equals is never consulted. Override both.

Prints [Java] (List.of is iterated in order, so the first wins). The comparator returns 0 for case-variants, so TreeSet treats them as duplicates. A HashSet would keep all three.

Prints [z, w] [z, w], then add throws UnsupportedOperationException. The list is a fixed-size write-through view of the array.

The wrapper is a view; the owner keeps mutating items, and the changes appear through the wrapper. Return List.copyOf(items) for a snapshot, or keep the owner's list private and never hand out the reference.

List<String> view = Collections.unmodifiableList(items);
items.add("new");
System.out.println(view.size()); // includes "new"

Duplicate keys throw IllegalArgumentException: duplicate key: a at creation. Any null key or value throws NullPointerException. Use HashMap + Collections.unmodifiableMap if nulls are needed.

No exception; prints 3. put on an existing key replaces the value and is not a structural modification (no modCount change). Adding a new key during iteration would throw CME.

HashMap is not thread-safe: concurrent puts can overwrite the same bucket slot (lost update), size goes out of sync, and concurrent resize can produce missing entries (Java 8) or an infinite loop (Java 7). Use ConcurrentHashMap (and atomic compound methods), or confine the map to one thread.

Only B is atomic. A is read-modify-write across two calls, so concurrent increments are lost. B executes the remapping atomically per key. For very hot keys, use ConcurrentHashMap<K, LongAdder> with computeIfAbsent(k, x -> new LongAdder()).increment().

Because List.sort is stable, you can sort by the secondary key first, then by the primary key and equal-primary items keep secondary order. Simpler and safer: one chained comparator.

list.sort(Comparator.comparing(Person::name));
list.sort(Comparator.comparingInt(Person::age)); // stable: ties stay name-sorted
// or:
list.sort(Comparator.comparingInt(Person::age).thenComparing(Person::name));

Prints [1, -2147483648] (wrong order). MIN_VALUE - 1 overflows to a positive number, so MIN_VALUE appears greater. Use Integer.compare(x, y) or Comparator.naturalOrder().

• ArrayList, LinkedList, HashSet, HashMap (one null key), LinkedHashMap: allowed.
• TreeMap/TreeSet with natural ordering: NPE.
• ConcurrentHashMap, Hashtable, ArrayDeque, PriorityQueue, List.of/Set.of/Map.of, blocking queues: NPE.
• EnumMap: null key NPE, null value allowed.

Prints [2, 3]: insertion-order mode ignores the get(1), so the eldest (1) is evicted. Pass true as the third constructor argument for access order, which would yield [1, 3].

Keep a min-heap of size K: for each element, offer; if size exceeds K, poll the smallest. Time O(N log K), memory O(K), versus O(N log N) for sorting everything.

PriorityQueue<Integer> pq = new PriorityQueue<>();
for (int x : data) { pq.offer(x); if (pq.size() > k) pq.poll(); }

1 is the head, but toString prints the internal array, e.g. [1, 2, 4, 5, 3], not sorted. Only poll() yields sorted order.

Prints 2 1 (push adds to the head), then push(null) throws NullPointerException. ArrayDeque forbids nulls.

No. 1000 rounds up to 1024, threshold 768; inserting the 769th entry triggers a resize to 2048. Correct presizing is ceil(1000 / 0.75) = 1334 -> 2048 capacity, or HashMap.newHashMap(1000) on Java 19+.

Every key lands in one bucket. Lookups cost O(n) with a chain (K is not Comparable), and once the bucket has 8+ nodes and table >= 64 it treeifies, but without Comparable the tree falls back to identity-hash tie-breaks and lookups must search both subtrees, so performance is still poor. Add Comparable to help trees, but fix the hash.

Order is unspecified and can differ between JVM runs because immutable sets/maps use a per-VM randomized salt. Never depend on it; use LinkedHashSet or List.of for stable order, or TreeSet.

IllegalStateException: Duplicate key a (attempted merging values apple and avocado). Supply a merge function (x, y) -> x, or use groupingBy to collect lists.

Prints [10, 30, 1]: remove(int index) is chosen over remove(Object), so index 1 (value 20) is removed. Use l.remove(Integer.valueOf(1)) to remove by value.

Throws ConcurrentModificationException: the parent was structurally modified after the view was created. Modifying through the view (s.add, s.clear()) is allowed and affects the parent.

Unbounded caches keyed by request-scoped data, listeners never removed, and ThreadLocal/class-keyed maps hold strong references. Fixes: bounded LRU (LinkedHashMap.removeEldestEntry, Caffeine with maximumSize and expiry), WeakHashMap for lifecycle-bound metadata, explicit removal on lifecycle end, and metrics on map size.

Neither; use ArrayDeque. ArrayList.remove(0) is O(n) shifting. LinkedList is O(1) but with heavy per-node overhead and poor locality. ArrayDeque.poll() is O(1) on a circular array.

The list is not sorted, so the result is undefined (here it may return -5 or a wrong index). Sort first, and use the same comparator for sort and search. For a missing key the result is -(insertionPoint) - 1.

Prints {aa=2}. Both keys compare equal (length 2), so the second put replaces the value but keeps the original key. Add a tie-breaker: .thenComparing(Comparator.naturalOrder()).

Collections.reverse(list) mutates in place; list.reversed() gives a live view with no copying; new ArrayList<>(list.reversed()) makes a reversed copy.

List<Integer> l = new ArrayList<>(List.of(1, 2, 3));
for (int x : l.reversed()) System.out.print(x); // 321, l unchanged

Prints NoSuchElementException. getFirst/getLast/removeFirst/removeLast throw it on empty sequenced collections, unlike get(0), which throws IndexOutOfBoundsException. Use isEmpty() guards or Deque.peekFirst for null-returning variants.

Prints {b=3, a=1}. putFirst inserts or repositions the key at the start and updates the value, unlike put where re-inserting does not change position (insertion order mode). TreeMap.putFirst throws UnsupportedOperationException.

Stream.toList() (Java 16+) returns an unmodifiable list, so add throws UnsupportedOperationException. Use collect(Collectors.toCollection(ArrayList::new)) when a mutable list is needed.

Since Java 9, HashMap.computeIfAbsent throws ConcurrentModificationException when the mapping function modifies the map (the recursive calls insert entries). On ConcurrentHashMap it can livelock or throw IllegalStateException: Recursive update. Check with get, compute, then put.

Use map.entrySet().removeIf(e -> cond) or map.values().removeIf(...), or an explicit Iterator.remove(). Calling map.remove(key) inside a for-each over the map throws CME (except ConcurrentHashMap).

List.equals compares elements in order regardless of implementation, so new ArrayList<>(List.of(1,2)).equals(Arrays.asList(1,2)) is true. assertEquals(List, Set) fails because a List never equals a Set, and array equals is identity: use Arrays.equals or assertArrayEquals.

Replace with ConcurrentHashMap + merge(k, 1, Integer::sum) or LongAdder values. Alternatives: partition per thread and merge at the end (no contention), or Collectors.groupingByConcurrent / counting in a parallel stream.

Each add copies the whole array (O(n) time and garbage), and writes serialize under a lock. Under heavy writes it floods the GC. Use ConcurrentLinkedQueue, a BlockingQueue, or a ring buffer; reserve COW for read-mostly data such as listener lists.

Integer.hashCode() is the value, 17; spread 17 ^ (17 >>> 16) = 17; index (16 - 1) & 17 = 1. So 1 and 17 collide in bucket 1 at capacity 16, and after resizing to 32, 17 moves to index 17 (1 + oldCap) because 17 & 16 != 0.

Prints {MON=m, WED=w} (declaration order, not insertion order), then put(null, ...) throws NullPointerException. get(null) just returns null.

LinkedHashSet. new LinkedHashSet<>(list) then new ArrayList<>(set) removes duplicates preserving first occurrence; stream().distinct() also preserves encounter order for ordered streams.

For single-JVM, TreeMap/TreeSet keyed by (score desc, id) gives O(log n) update and range reads (headMap, descendingMap); rank by position is O(n) in a TreeSet, so use an order-statistic tree or Redis ZSET at scale. For concurrency use ConcurrentSkipListMap.

{1=v1, 2=v2} {3=v3, 4=v4, 5=v5} null 4. headMap excludes the bound, tailMap includes it by default, floorKey(0) has no key <= 0 so returns null, ceilingKey(4) is 4.

Modifying the source during a terminal operation is interference: ArrayList.forEach or stream().forEach(l::remove) throws CME (detected at the end of traversal for ArrayList's spliterator). Collect first and remove, or use removeIf.

Callers can mutate internal state, break invariants, and cause CME while the owner iterates. Return an unmodifiable view, List.copyOf, or a stream/iterator. Also copy on the way in (constructor argument) because the caller keeps the reference.

class Order {
    private final List<Item> items;
    Order(List<Item> in) { this.items = List.copyOf(in); }
    List<Item> items() { return items; }
}

Both contain [x], but a is an anonymous subclass of ArrayList (double-brace initialization): an extra class per site, an implicit reference to the enclosing instance (memory leak if the list escapes), and getClass() is not ArrayList, which breaks equals-by-class checks and serialization. Prefer b.

The second add throws ClassCastException: Task cannot be cast to class java.lang.Comparable; the first add succeeds (Java 7+ checks only when comparing). Implement Comparable<Task> or pass a Comparator.

HashMap iteration is O(capacity + size). A map that once held millions of entries and was emptied via remove/clear keeps its giant table, so iterating scans every slot. clear() also does not shrink it. Create a new HashMap (or let the old one be GC'd) instead of reusing.

size() and isEmpty() are estimates under concurrent updates; they are exact only in quiescent state. Use mappingCount() for a long count and do not use size() for control flow decisions such as "if empty then put".

{1=2, 2=2}. The TreeMap factory gives sorted keys, and counting() yields Long values. groupingBy throws NPE if the classifier returns null for an element.

Natural-order sorting throws NullPointerException when compareTo is called on null. Use list.sort(Comparator.nullsFirst(Comparator.naturalOrder())) (or nullsLast).

For ArrayList, indexed loop and iterator are similar. For LinkedList, never loop with get(i): it is O(n^2) overall. Use the iterator or for-each, O(n). RandomAccess marker interface tells algorithms which to use.

for (int i = 0; i < linked.size(); i++) linked.get(i); // O(n^2) trap

Use ArrayBlockingQueue (or LinkedBlockingQueue(capacity)); producers put (block when full), consumers take (block when empty). Shut down with a poison pill or interrupt.

BlockingQueue<Job> q = new ArrayBlockingQueue<>(100);
// producer: q.put(job);   consumer: Job j = q.take();

false. Arrays use identity equals/hashCode. Wrap values in a List<Integer>, a record, or Arrays.hashCode in a custom key class. A List key works but must never be mutated after insertion.

Estimate about 100+ bytes per entry (table slot, Node 32, boxed Long 16-24, String + byte[] ~50+), so roughly 0.5-1 GB. Presize to avoid copy spikes (a resize needs old and new tables briefly), consider primitive maps (fastutil Long2ObjectOpenHashMap), bounded eviction, and off-heap or Redis if too large; measure with a heap dump or JOL.

Wrap tasks with an AtomicLong sequence number and compare by priority then sequence, since PriorityQueue is not stable.

record Item<T>(int prio, long seq, T task) {}
var pq = new PriorityQueue<Item<Runnable>>(
    Comparator.comparingInt((Item<Runnable> i) -> i.prio())
              .thenComparingLong(Item::seq));