All 15 Collections Framework questions
More in Collections Framework
What is the purpose of the Deque interface, and how does it unify both stack (LIFO) and queue (FIFO) behavior in a single interface? What is the purpose of the Collections utility class's synchronization wrappers (Collections.synchronizedList(), etc.), and how do they differ from genuinely concurrent collections like ConcurrentHashMap? How does PriorityQueue work internally (as a binary heap), and what ordering does it use by default versus with a custom Comparator? How does HashMap's internal implementation work (hashing, bucket array, treeification), and how did its collision-handling strategy change in Java 8? How does TreeMap/TreeSet's red-black tree implementation guarantee O(log n) operations, and what role does the Comparable/Comparator interface play in maintaining sorted order? How would you implement a custom Comparator with multiple sort criteria (e.g., sort by last name, then by first name as a tiebreaker) using the Comparator.comparing() and thenComparing() fluent API? How does the Collections Framework's fail-fast modCount mechanism actually work internally, and why is it described as "best-effort" rather than a strict guarantee? How would you choose the correct initial capacity for a HashMap to avoid unnecessary resizing overhead, given the relationship between capacity, load factor, and resize threshold?
Advertisement
Back to results for “Collections”
Java › Collections Framework

How do you choose between HashMap, LinkedHashMap, and TreeMap based on their different ordering guarantees and performance characteristics?

Advanced

Answer

HashMap provides no ordering guarantee whatsoever (iteration order can even change between runs or after resizing), offering the best average-case O(1) performance for get/put/remove; LinkedHashMap maintains insertion order (or optionally access order, useful for implementing an LRU cache) by additionally threading a doubly-linked list through entries, at a small additional memory and performance cost over plain HashMap; TreeMap maintains keys in sorted order (natural ordering or a custom Comparator) using a red-black tree internally, giving O(log n) operations (slower than HashMap's O(1)) but enabling range queries and guaranteed sorted iteration, which neither HashMap nor LinkedHashMap can provide.
// LinkedHashMap configured for LRU eviction behavior
Map<String, String> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
    @Override
    protected boolean removeEldestEntry(Map.Entry<String, String> eldest) {
        return size() > 100;  // evict oldest-accessed entry once capacity exceeded
    }
};

// TreeMap for sorted iteration and range queries
TreeMap<Integer, String> sortedMap = new TreeMap<>();
sortedMap.put(3, "c"); sortedMap.put(1, "a"); sortedMap.put(2, "b");
System.out.println(sortedMap.firstKey());  // 1, always sorted
System.out.println(sortedMap.headMap(3));  // entries with keys < 3
Real-world example A simple in-memory LRU cache implementation extends LinkedHashMap with access-order enabled and overrides removeEldestEntry(), leveraging the JDK's built-in linked-list-ordering support rather than hand-implementing LRU eviction logic from scratch with a separate data structure.

Common follow-ups: What's the performance cost of LinkedHashMap's extra linked-list maintenance compared to plain HashMap?;How does TreeMap's red-black tree implementation guarantee O(log n) worst-case (unlike HashMap's amortized-but-not-guaranteed O(1))?

Design Patterns in Java;Caching
All 15 Collections Framework questions