[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":84,"_73":85,"_35":86},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70,"_71":72},"id",124,"title","Performance Pitfalls","slug","java-collections-part-28-performance-pitfalls","excerpt","Real-world performance: why Big-O hides constant factors, actual memory footprints, JMH benchmarking, JFR/JMC monitoring, and collection-specific antipatterns.","# Part 28: Performance, Memory & Production Pitfalls\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| **Focus** | Real-world performance, memory footprint, common production issues |\n| **Key Insight** | Big-O complexity hides constant factors that dominate in practice |\n| **Profiling Tools** | JMH for benchmarks, JFR/JMC for production monitoring |\n| **Memory Reality** | ArrayList of 1M Integers: 4MB data + ~20MB overhead |\n| **Top Pitfalls** | Wrong collection type, forgetting to size, memory leaks |\n\n> **One-liner**: Understanding collection performance means knowing both complexity AND real-world behavior under production load.\n\n---\n\n## 🎯 What You'll Learn\n\n1. Why Big-O complexity doesn't tell the whole story\n2. Memory footprint of different collection types\n3. How to benchmark collections properly with JMH\n4. Production monitoring with JFR and JMC\n5. Common performance pitfalls and how to avoid them\n6. Memory leak patterns specific to collections\n\n---\n\n## Prerequisites\n\nBefore reading this article, ensure you understand:\n\n- Part 6-7: ArrayList and LinkedList internals\n- Part 12-13: HashMap internals and tree bins\n- Part 18-19: ConcurrentHashMap\n- Part 27: Testing and debugging techniques\n\n---\n\n## Production Story: The N+1 That Wasn't in the Database\n\nThe alert came at 2 AM: payment processing latency had spiked from 50ms to 800ms. The on-call engineer checked the usual suspects—database queries, external APIs, network—all looked fine.\n\nAfter enabling JFR in production, the flame graph revealed something unexpected. Most time was spent not in I/O, but in... `HashMap.get()`.\n\n```java\n// The code that seemed innocent\npublic PaymentResult processPayment(Order order) {\n Map rules = loadPricingRules(); // 50,000 rules\n\n BigDecimal total = BigDecimal.ZERO;\n for (OrderItem item : order.getItems()) {\n for (String tag : item.getTags()) { // N tags per item\n for (String ruleKey : rules.keySet()) { // 50,000 iterations!\n if (ruleKey.startsWith(tag)) { // String allocation\n PricingRule rule = rules.get(ruleKey);\n total = rule.apply(total, item);\n }\n }\n }\n }\n return new PaymentResult(total);\n}\n```\n\nThe problem? **O(n²) hidden in collection iteration**, not a database N+1.\n\n**Root Cause Analysis:**\n\n1. `rules.keySet()` creates an iterator for 50,000 elements\n2. `startsWith()` comparison on each key creates substring checks\n3. For an order with 10 items × 5 tags = 50 iterations × 50,000 = 2.5 million operations\n\n**The Fix:**\n\n```java\n// Pre-indexed structure eliminates O(n²)\npublic class PricingEngine {\n private final Map> rulesByPrefix;\n\n public PricingEngine(Map rules) {\n this.rulesByPrefix = rules.entrySet().stream()\n .collect(Collectors.groupingBy(\n e -> extractPrefix(e.getKey()),\n Collectors.mapping(Map.Entry::getValue, Collectors.toList())\n ));\n }\n\n public PaymentResult processPayment(Order order) {\n BigDecimal total = BigDecimal.ZERO;\n for (OrderItem item : order.getItems()) {\n for (String tag : item.getTags()) {\n List applicable = rulesByPrefix.getOrDefault(tag, List.of());\n for (PricingRule rule : applicable) {\n total = rule.apply(total, item);\n }\n }\n }\n return new PaymentResult(total);\n }\n}\n```\n\n**Result:** Latency dropped from 800ms to 12ms—a 67x improvement by choosing the right data structure.\n\n---\n\n## Mental Model: The Performance Iceberg\n\n```\n What you see in Big-O:\n ┌─────┐\n │O(1) │ ← HashMap.get()\n └─────┘\n ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Water Line\n\n What actually happens:\n ┌──────────────────────────────────────┐\n │ hashCode() computation │\n │ Array access (L1/L2/L3 cache miss?) │\n │ equals() comparison │\n │ Tree traversal (if bin > 8) │\n │ Memory allocation for iterator │\n │ GC pressure from temporary objects │\n │ CPU branch prediction misses │\n │ Memory locality / cache coherence │\n └──────────────────────────────────────┘\n```\n\n### Constant Factors That Matter\n\n```\nHashMap.get() \"O(1)\":\n├── hashCode(): 1-100ns (depends on key type)\n├── Array access: 1ns (L1) to 100ns (RAM)\n├── equals(): 1ns (int) to 1μs (deep object)\n└── Potential tree walk: +O(log n)\n\nArrayList.get(i) \"O(1)\":\n├── Bounds check: 1ns\n├── Array access: 1-100ns (cache dependent)\n└── Boxing/unboxing: 20-50ns (if primitives)\n\nTreeMap.get() \"O(log n)\":\n├── Each compare: 10-100ns\n├── Tree depth: log₂(n) comparisons\n├── Better cache locality than HashMap!\n└── At n=1000: ~10 comparisons ≈ 1μs\n```\n\n### When O(log n) Beats O(1)\n\n```\nPerformance crossover point (typical):\n\nOperations │\nper second │\n │ TreeMap\n 10M ───│────●───────────────────────\n │ / HashMap\n 1M ───│──/─────────────────●───────\n │ / /\n 100K ───│/─────────────────/─────────\n │ /\n └────┬────┬────┬────┬────────\n 10 100 1K 10K elements\n\nFor small collections (< 1000 elements):\n- TreeMap often faster due to cache locality\n- HashMap overhead (array, load factor) dominates\n- Profile don't assume!\n```\n\n---\n\n## Deep Dive: Memory Footprint Reality\n\n### Object Headers and Alignment\n\n```\nEvery Java object has overhead:\n\n┌─────────────────────────────────────────┐\n│ 64-bit JVM Object Layout │\n├─────────────────────────────────────────┤\n│ Mark Word: 8 bytes │\n│ Class Pointer: 4 bytes (compressed) │\n│ Array Length: 4 bytes (arrays only) │\n│ Padding: to 8-byte boundary │\n└─────────────────────────────────────────┘\n\nInteger object: 16 bytes for 4 bytes of data!\n- Mark word: 8 bytes\n- Class pointer: 4 bytes\n- int value: 4 bytes\n- Total: 16 bytes (4x overhead!)\n```\n\n### Collection Memory Calculator\n\n```java\npublic class CollectionMemoryEstimator {\n\n /**\n * ArrayList memory footprint\n *\n * Base: 24 bytes (object header + size + modCount + array ref)\n * Array: 16 + 4*capacity bytes (header + elements)\n * Elements: depends on type\n */\n public static long arrayListMemory(int size, int elementSize) {\n int capacity = calculateCapacity(size);\n long base = 24; // ArrayList object\n long array = 16 + 4L * capacity; // Object[] array\n long elements = (long) size * elementSize; // Stored objects\n return base + array + elements;\n }\n\n /**\n * HashMap memory footprint\n *\n * Base: 48 bytes (header + fields)\n * Table: 16 + 4*capacity bytes\n * Entries: 32 bytes each (Node object)\n * Keys + Values: depends on types\n */\n public static long hashMapMemory(int size, int keySize, int valueSize) {\n int capacity = tableSizeFor(size);\n long base = 48; // HashMap object\n long table = 16 + 4L * capacity; // Node[] array\n long entries = 32L * size; // Node objects\n long keysValues = (long) size * (keySize + valueSize);\n return base + table + entries + keysValues;\n }\n\n private static int calculateCapacity(int size) {\n // ArrayList grows by 50%\n return Math.max(10, (int) (size * 1.5));\n }\n\n private static int tableSizeFor(int size) {\n // HashMap uses power of 2 >= size / 0.75\n int n = (int) (size / 0.75) + 1;\n n--;\n n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16;\n return n + 1;\n }\n}\n```\n\n### Memory Comparison Table\n\n```\nStoring 1,000,000 integers:\n\nCollection Type | Memory Used | Overhead\n-------------------------|-------------|----------\nint[] (primitive) | 4 MB | 0%\nArrayList | 24 MB | 500%\nLinkedList | 48 MB | 1100%\nHashSet | 56 MB | 1300%\nTreeSet | 64 MB | 1500%\n\nWhy such high overhead?\n- Integer boxing: 16 bytes per element (vs 4 bytes)\n- Node/Entry objects: 32-40 bytes each\n- Array overhead and slack space\n```\n\n### Primitive Collection Libraries\n\n```java\n// Standard Java - 24 MB for 1M integers\nList standard = new ArrayList<>();\nfor (int i = 0; i < 1_000_000; i++) {\n standard.add(i); // Boxing overhead!\n}\n\n// Eclipse Collections - 4 MB for 1M integers\nIntList primitive = IntLists.mutable.empty();\nfor (int i = 0; i < 1_000_000; i++) {\n primitive.add(i); // No boxing!\n}\n\n// Trove4j - similar memory efficiency\nTIntArrayList trove = new TIntArrayList();\n\n// FastUtil - high-performance primitive collections\nIntArrayList fastutil = new IntArrayList();\n```\n\n---\n\n## Deep Dive: JMH Benchmarking\n\n### Setting Up JMH\n\n```xml\n\n\n \n org.openjdk.jmh\n jmh-core\n 1.37\n \n \n org.openjdk.jmh\n jmh-generator-annprocess\n 1.37\n provided\n \n\n```\n\n### Collection Benchmark Example\n\n```java\n@BenchmarkMode(Mode.AverageTime)\n@OutputTimeUnit(TimeUnit.NANOSECONDS)\n@State(Scope.Benchmark)\n@Warmup(iterations = 5, time = 1)\n@Measurement(iterations = 10, time = 1)\n@Fork(2)\npublic class CollectionBenchmark {\n\n @Param({\"100\", \"10000\", \"1000000\"})\n private int size;\n\n private List arrayList;\n private List linkedList;\n private Set hashSet;\n private Set treeSet;\n private Integer lookupValue;\n\n @Setup\n public void setup() {\n arrayList = new ArrayList<>();\n linkedList = new LinkedList<>();\n hashSet = new HashSet<>();\n treeSet = new TreeSet<>();\n\n Random random = new Random(42);\n for (int i = 0; i < size; i++) {\n Integer value = random.nextInt(size * 2);\n arrayList.add(value);\n linkedList.add(value);\n hashSet.add(value);\n treeSet.add(value);\n }\n lookupValue = arrayList.get(size / 2);\n }\n\n @Benchmark\n public boolean arrayListContains() {\n return arrayList.contains(lookupValue);\n }\n\n @Benchmark\n public boolean linkedListContains() {\n return linkedList.contains(lookupValue);\n }\n\n @Benchmark\n public boolean hashSetContains() {\n return hashSet.contains(lookupValue);\n }\n\n @Benchmark\n public boolean treeSetContains() {\n return treeSet.contains(lookupValue);\n }\n\n @Benchmark\n public int arrayListIteration() {\n int sum = 0;\n for (Integer i : arrayList) {\n sum += i;\n }\n return sum;\n }\n\n @Benchmark\n public int linkedListIteration() {\n int sum = 0;\n for (Integer i : linkedList) {\n sum += i;\n }\n return sum;\n }\n\n public static void main(String[] args) throws Exception {\n Options opt = new OptionsBuilder()\n .include(CollectionBenchmark.class.getSimpleName())\n .build();\n new Runner(opt).run();\n }\n}\n```\n\n### Sample Benchmark Results\n\n```\nBenchmark (size) Mode Cnt Score Error Units\nCollectionBenchmark.arrayListContains 100 avgt 20 48.234 ± 1.231 ns/op\nCollectionBenchmark.arrayListContains 10000 avgt 20 4823.456 ± 45.678 ns/op\nCollectionBenchmark.arrayListContains 1000000 avgt 20 523456.789 ± 1234.5 ns/op\n\nCollectionBenchmark.hashSetContains 100 avgt 20 8.234 ± 0.456 ns/op\nCollectionBenchmark.hashSetContains 10000 avgt 20 9.123 ± 0.567 ns/op\nCollectionBenchmark.hashSetContains 1000000 avgt 20 12.456 ± 0.789 ns/op\n\nCollectionBenchmark.treeSetContains 100 avgt 20 15.234 ± 0.678 ns/op\nCollectionBenchmark.treeSetContains 10000 avgt 20 45.678 ± 1.234 ns/op\nCollectionBenchmark.treeSetContains 1000000 avgt 20 98.765 ± 2.345 ns/op\n\nKey insight: HashSet.contains() scales O(1), ArrayList scales O(n)\nAt 1M elements: HashSet is 42,000x faster for lookups!\n```\n\n### Common Benchmarking Mistakes\n\n```java\n// WRONG: JIT will eliminate dead code\n@Benchmark\npublic void badBenchmark() {\n list.contains(value); // Result not used!\n}\n\n// CORRECT: Return the result\n@Benchmark\npublic boolean goodBenchmark() {\n return list.contains(value);\n}\n\n// WRONG: Constant folding\n@Benchmark\npublic int badSum() {\n List local = List.of(1, 2, 3, 4, 5);\n return local.stream().mapToInt(i -> i).sum();\n}\n\n// CORRECT: Use @State fields\n@Benchmark\npublic int goodSum() {\n return stateList.stream().mapToInt(i -> i).sum();\n}\n\n// WRONG: Loop inside benchmark (measures loop overhead)\n@Benchmark\npublic void badLoop() {\n for (int i = 0; i < 1000; i++) {\n map.get(keys[i]);\n }\n}\n\n// CORRECT: Use @BenchmarkMode(Mode.Throughput) or single operation\n@Benchmark\n@OperationsPerInvocation(1000)\npublic void goodLoop(Blackhole bh) {\n for (int i = 0; i < 1000; i++) {\n bh.consume(map.get(keys[i]));\n }\n}\n```\n\n---\n\n## Deep Dive: Production Monitoring with JFR\n\n### Enabling JFR\n\n```bash\n# Start with JFR enabled\njava -XX:+FlightRecorder \\\n -XX:StartFlightRecording=duration=60s,filename=app.jfr \\\n -jar application.jar\n\n# Or attach to running process\njcmd JFR.start duration=60s filename=app.jfr\n\n# Continuous recording with rotation\njava -XX:+FlightRecorder \\\n -XX:StartFlightRecording=disk=true,maxsize=500m,maxage=1d \\\n -jar application.jar\n```\n\n### Programmatic JFR Events\n\n```java\n@Name(\"com.example.CollectionOperation\")\n@Label(\"Collection Operation\")\n@Category({\"Application\", \"Collections\"})\n@StackTrace(true)\npublic class CollectionOperationEvent extends Event {\n\n @Label(\"Collection Type\")\n public String collectionType;\n\n @Label(\"Operation\")\n public String operation;\n\n @Label(\"Size\")\n public int size;\n\n @Label(\"Duration (ns)\")\n @Timespan(Timespan.NANOSECONDS)\n public long duration;\n}\n\n// Usage in application\npublic class MonitoredMap implements Map {\n private final Map delegate;\n\n @Override\n public V get(Object key) {\n CollectionOperationEvent event = new CollectionOperationEvent();\n event.begin();\n try {\n return delegate.get(key);\n } finally {\n event.collectionType = delegate.getClass().getSimpleName();\n event.operation = \"get\";\n event.size = delegate.size();\n event.end();\n event.commit();\n }\n }\n}\n```\n\n### JFR Collection Analysis Queries\n\n```java\n// Analyzing JFR recordings programmatically\npublic class JfrCollectionAnalyzer {\n\n public void analyzeRecording(Path jfrFile) throws IOException {\n try (RecordingFile recording = new RecordingFile(jfrFile)) {\n Map statsByType = new HashMap<>();\n\n while (recording.hasMoreEvents()) {\n RecordedEvent event = recording.readEvent();\n\n if (event.getEventType().getName()\n .equals(\"com.example.CollectionOperation\")) {\n String type = event.getString(\"collectionType\");\n long duration = event.getLong(\"duration\");\n\n statsByType.computeIfAbsent(type,\n k -> new LongSummaryStatistics()).accept(duration);\n }\n }\n\n statsByType.forEach((type, stats) ->\n System.out.printf(\"%s: count=%d, avg=%.2fns, max=%dns%n\",\n type, stats.getCount(), stats.getAverage(), stats.getMax()));\n }\n }\n}\n```\n\n---\n\n## Common Performance Pitfalls\n\n### Pitfall 1: Not Pre-sizing Collections\n\n```java\n// BAD: ArrayList resizes 17 times for 100,000 elements\n// 10 → 15 → 22 → 33 → ... → 100,000+ (with copies each time!)\nList list = new ArrayList<>();\nfor (int i = 0; i < 100_000; i++) {\n list.add(\"item\" + i);\n}\n\n// GOOD: No resizing\nList list = new ArrayList<>(100_000);\nfor (int i = 0; i < 100_000; i++) {\n list.add(\"item\" + i);\n}\n\n// Performance difference:\n// Without pre-sizing: ~50ms\n// With pre-sizing: ~20ms (2.5x faster)\n// Plus less GC pressure from discarded arrays\n```\n\n### Pitfall 2: Wrong Map for Access Pattern\n\n```java\n// BAD: Iteration-heavy code with HashMap\nMap scores = new HashMap<>();\n// ... populate ...\n\n// Frequent iteration with consistent order needed\nfor (Map.Entry entry : scores.entrySet()) {\n processInOrder(entry); // Order is unpredictable!\n}\n\n// GOOD: LinkedHashMap preserves insertion order\nMap scores = new LinkedHashMap<>();\n\n// Or if you need sorted iteration:\nMap scores = new TreeMap<>();\n```\n\n### Pitfall 3: Contains on Wrong Collection\n\n```java\n// BAD: O(n) for each contains check\nList whitelist = loadWhitelist(); // 10,000 items\nfor (Request request : requests) { // 1,000,000 requests\n if (whitelist.contains(request.getUser())) { // 10^10 operations!\n process(request);\n }\n}\n\n// GOOD: O(1) for each contains check\nSet whitelist = new HashSet<>(loadWhitelist());\nfor (Request request : requests) {\n if (whitelist.contains(request.getUser())) { // 10^6 operations\n process(request);\n }\n}\n\n// Real impact: 10,000x faster\n```\n\n### Pitfall 4: Streams on Small Collections\n\n```java\n// Overhead dominates for small collections\nList small = List.of(1, 2, 3, 4, 5);\n\n// BAD: Stream overhead ~100ns for simple operation\nint sum = small.stream().mapToInt(i -> i).sum();\n\n// GOOD: Loop is faster for < 100 elements\nint sum = 0;\nfor (int i : small) {\n sum += i;\n}\n\n// Break-even point is typically 100-1000 elements\n// Below that, traditional loops win\n```\n\n### Pitfall 5: Creating Collections in Hot Paths\n\n```java\n// BAD: New collection on every call\npublic boolean isAllowed(String permission) {\n Set allowed = new HashSet<>(Arrays.asList(\n \"READ\", \"WRITE\", \"EXECUTE\"\n )); // Allocation on every call!\n return allowed.contains(permission);\n}\n\n// GOOD: Static final set\nprivate static final Set ALLOWED = Set.of(\n \"READ\", \"WRITE\", \"EXECUTE\"\n);\n\npublic boolean isAllowed(String permission) {\n return ALLOWED.contains(permission);\n}\n\n// Performance: 100x faster (no allocation)\n```\n\n### Pitfall 6: Boxing in Primitive Operations\n\n```java\n// BAD: Massive boxing overhead\nMap counts = new HashMap<>();\nfor (int i = 0; i < 1_000_000; i++) {\n counts.merge(i % 100, 1, Integer::sum);\n // Each operation: 2 boxing, 1 unboxing, method refs\n}\n\n// GOOD: Primitive-specialized library\nInt2IntMap counts = new Int2IntOpenHashMap();\nfor (int i = 0; i < 1_000_000; i++) {\n counts.addTo(i % 100, 1); // No boxing!\n}\n\n// Performance: 5-10x faster, 4x less memory\n```\n\n### Pitfall 7: ConcurrentHashMap Compound Operations\n\n```java\n// BAD: Race condition between check and put\nConcurrentHashMap map = new ConcurrentHashMap<>();\n\npublic void increment(String key) {\n Integer current = map.get(key); // Read\n // Another thread could modify here!\n map.put(key, current == null ? 1 : current + 1); // Write\n}\n\n// GOOD: Atomic compound operation\npublic void increment(String key) {\n map.merge(key, 1, Integer::sum); // Atomic!\n}\n\n// Or for complex logic:\nmap.compute(key, (k, v) -> {\n // Entire lambda is atomic for this key\n return v == null ? 1 : v + 1;\n});\n```\n\n---\n\n## Memory Leak Patterns\n\n### Pattern 1: Static Collection Growing Forever\n\n```java\n// MEMORY LEAK: Entries never removed\npublic class EventCache {\n private static final Map cache = new HashMap<>();\n\n public static void recordEvent(String id, Event event) {\n cache.put(id, event); // Grows forever!\n }\n}\n\n// FIX: Use bounded cache or WeakHashMap\npublic class EventCache {\n private static final Map cache =\n Collections.synchronizedMap(new LinkedHashMap<>(1000, 0.75f, true) {\n @Override\n protected boolean removeEldestEntry(Map.Entry eldest) {\n return size() > 1000; // Bounded!\n }\n });\n}\n\n// Or use Caffeine cache\nprivate static final Cache cache = Caffeine.newBuilder()\n .maximumSize(1000)\n .expireAfterWrite(Duration.ofHours(1))\n .build();\n```\n\n### Pattern 2: Listener Collections\n\n```java\n// MEMORY LEAK: Listeners never removed\npublic class EventBus {\n private final List listeners = new ArrayList<>();\n\n public void addListener(EventListener listener) {\n listeners.add(listener); // Strong reference\n }\n // No removeListener called = leak!\n}\n\n// FIX: Use weak references\npublic class EventBus {\n private final List> listeners =\n new CopyOnWriteArrayList<>();\n\n public void addListener(EventListener listener) {\n listeners.add(new WeakReference<>(listener));\n }\n\n public void fireEvent(Event event) {\n listeners.removeIf(ref -> {\n EventListener listener = ref.get();\n if (listener == null) return true; // Cleaned up\n listener.onEvent(event);\n return false;\n });\n }\n}\n```\n\n### Pattern 3: Thread-Local Collections\n\n```java\n// MEMORY LEAK in thread pools\npublic class RequestContext {\n private static final ThreadLocal> context =\n ThreadLocal.withInitial(HashMap::new);\n\n public static void set(String key, Object value) {\n context.get().put(key, value);\n }\n\n // Thread pool reuses threads - data accumulates!\n}\n\n// FIX: Always clean up\npublic static void clear() {\n context.remove(); // Must call in finally block!\n}\n\n// Better: Use try-with-resources pattern\npublic class RequestScope implements AutoCloseable {\n public RequestScope() {\n context.get().clear();\n }\n\n @Override\n public void close() {\n context.remove();\n }\n}\n\n// Usage:\ntry (RequestScope scope = new RequestScope()) {\n RequestContext.set(\"user\", currentUser);\n processRequest();\n} // Automatically cleaned up\n```\n\n### Pattern 4: Key Objects That Change\n\n```java\n// MEMORY LEAK: Modified key can't be found\npublic class MutableKey {\n private String value;\n\n public void setValue(String value) { this.value = value; }\n\n @Override\n public int hashCode() { return value.hashCode(); }\n\n @Override\n public boolean equals(Object o) {\n return o instanceof MutableKey && ((MutableKey) o).value.equals(value);\n }\n}\n\nMap map = new HashMap<>();\nMutableKey key = new MutableKey();\nkey.setValue(\"original\");\nmap.put(key, data);\n\nkey.setValue(\"modified\"); // Hash changed!\nmap.get(key); // Returns null - can't find it\nmap.containsKey(key); // Returns false\n// But entry is still in map, orphaned!\n\n// FIX: Always use immutable keys\npublic record ImmutableKey(String value) {}\n```\n\n### Detecting Memory Leaks\n\n```java\n// Add monitoring for suspicious collections\npublic class LeakDetector {\n private static final Map collectionSizes =\n new ConcurrentHashMap<>();\n\n public static void monitor(String name, Collection collection) {\n int previousSize = collectionSizes.getOrDefault(name, 0);\n int currentSize = collection.size();\n\n if (currentSize > previousSize * 2 && currentSize > 1000) {\n log.warn(\"Collection {} grew from {} to {} - possible leak?\",\n name, previousSize, currentSize);\n }\n\n collectionSizes.put(name, currentSize);\n }\n}\n\n// Use in application\n@Scheduled(fixedRate = 60000)\npublic void monitorCollections() {\n LeakDetector.monitor(\"userSessions\", userSessions);\n LeakDetector.monitor(\"eventCache\", eventCache);\n}\n```\n\n---\n\n## GC Implications\n\n### Collection Type and GC Pressure\n\n```\nGC Impact by Collection Type:\n\nArrayList:\n├── Single large array (few objects)\n├── Resizing creates garbage (old arrays)\n├── Good for G1/ZGC (humongous object handling)\n└── Pre-size to minimize GC\n\nLinkedList:\n├── Many small Node objects\n├── High allocation rate during adds\n├── Scattered in memory (poor locality)\n└── Avoid in throughput-critical paths\n\nHashMap:\n├── Entry nodes per element\n├── Resize copies entire table\n├── Tree bins at threshold (more objects)\n└── Use initial capacity wisely\n\nTreeMap:\n├── TreeNode per element\n├── Rebalancing doesn't create garbage\n├── More predictable GC behavior\n└── Good for real-time systems\n```\n\n### Reducing GC Pressure\n\n```java\n// Pattern 1: Object pooling for heavy objects\npublic class PooledArrayList {\n private static final Queue> pool =\n new ConcurrentLinkedQueue<>();\n\n @SuppressWarnings(\"unchecked\")\n public static ArrayList acquire() {\n ArrayList list = pool.poll();\n if (list == null) {\n return new ArrayList<>();\n }\n list.clear();\n return (ArrayList) list;\n }\n\n public static void release(ArrayList list) {\n if (list.size() < 1000) { // Don't pool huge lists\n pool.offer(list);\n }\n }\n}\n\n// Pattern 2: Flyweight keys\npublic class InternedKeyMap {\n private final Map keyIntern = new HashMap<>();\n private final Map data = new HashMap<>();\n\n public void put(String key, V value) {\n String internedKey = keyIntern.computeIfAbsent(key, k -> k);\n data.put(internedKey, value);\n }\n}\n```\n\n---\n\n## Debug This! Collection Performance Challenges\n\n### Challenge 1: The Slow Aggregation\n\n```java\n// This code is slow with large input. Why?\npublic Map> groupByCustomer(\n List transactions) {\n Map> result = new HashMap<>();\n\n for (Transaction t : transactions) {\n String customerId = t.getCustomerId();\n if (!result.containsKey(customerId)) {\n result.put(customerId, new ArrayList<>());\n }\n result.get(customerId).add(t);\n }\n\n return result;\n}\n```\n\n

Solution

\n\n**Problem:** Two hash lookups per transaction (`containsKey` + `get`).\n\n```java\n// Fixed: Single lookup with computeIfAbsent\npublic Map> groupByCustomer(\n List transactions) {\n Map> result = new HashMap<>();\n\n for (Transaction t : transactions) {\n result.computeIfAbsent(t.getCustomerId(), k -> new ArrayList<>())\n .add(t);\n }\n\n return result;\n}\n\n// Or even better with streams:\nreturn transactions.stream()\n .collect(Collectors.groupingBy(Transaction::getCustomerId));\n```\n\n**Performance improvement:** 30-50% faster for large datasets.\n

\n\n### Challenge 2: Memory Mystery\n\n```java\n// This cache uses more memory than expected. Why?\npublic class StringCache {\n private final Map cache = new HashMap<>(10_000);\n\n public void cache(String key, String value) {\n cache.put(key, value);\n }\n\n public String get(String key) {\n return cache.get(key);\n }\n}\n\n// Usage:\nStringCache cache = new StringCache();\nfor (String line : readLargeFile()) { // 10MB file\n String[] parts = line.split(\",\");\n cache.cache(parts[0], parts[1]); // Only caching parts\n}\n// Expected: small cache\n// Actual: 10MB+ memory used!\n```\n\n

Solution

\n\n**Problem:** `String.split()` returns substrings that reference the original large string (in some JVM versions) or still allocate full strings. The bigger issue is that we're keeping references to strings derived from the large file content.\n\n```java\n// Fixed: Explicit new String() to break reference\npublic void cache(String key, String value) {\n cache.put(new String(key), new String(value));\n}\n\n// Or use substring properly in modern Java (post-JDK 7u6):\n// Modern JVMs copy the array, but split() still allocates\n// The issue might be:\n// 1. HashMap overhead (Entry objects)\n// 2. Not pre-sizing HashMap\n// 3. String object overhead\n\n// Better approach:\npublic void cache(String key, String value) {\n cache.put(key.intern(), value); // Use string pool for keys\n}\n```\n\n

\n\n### Challenge 3: The Concurrent Bottleneck\n\n```java\n// This concurrent code doesn't scale. Why?\npublic class ConcurrentStats {\n private final Map stats =\n Collections.synchronizedMap(new HashMap<>());\n\n public void increment(String key) {\n synchronized (stats) {\n Long current = stats.getOrDefault(key, 0L);\n stats.put(key, current + 1);\n }\n }\n\n public Map getSnapshot() {\n synchronized (stats) {\n return new HashMap<>(stats);\n }\n }\n}\n```\n\n

Solution

\n\n**Problem:** Global lock creates contention; all threads wait on single lock.\n\n```java\n// Fixed: Use ConcurrentHashMap with atomic operations\npublic class ConcurrentStats {\n private final ConcurrentHashMap stats =\n new ConcurrentHashMap<>();\n\n public void increment(String key) {\n stats.computeIfAbsent(key, k -> new LongAdder()).increment();\n }\n\n public Map getSnapshot() {\n return stats.entrySet().stream()\n .collect(Collectors.toMap(\n Map.Entry::getKey,\n e -> e.getValue().sum()\n ));\n }\n}\n```\n\n**Why LongAdder?**\n- Lock-free increment\n- Striped counters reduce contention\n- 10-100x better throughput under high contention\n

\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Benchmark ArrayList vs LinkedList Insertion\n\nWrite a JMH benchmark comparing insertion performance:\n\n```java\n// TODO: Complete the benchmark\n@State(Scope.Benchmark)\npublic class InsertionBenchmark {\n\n @Param({\"100\", \"10000\"})\n private int size;\n\n // Benchmark inserting at beginning\n // Benchmark inserting at middle\n // Benchmark inserting at end\n // Compare ArrayList vs LinkedList\n}\n```\n\n

Solution

\n\n```java\n@BenchmarkMode(Mode.AverageTime)\n@OutputTimeUnit(TimeUnit.MICROSECONDS)\n@State(Scope.Benchmark)\n@Warmup(iterations = 3)\n@Measurement(iterations = 5)\n@Fork(2)\npublic class InsertionBenchmark {\n\n @Param({\"100\", \"10000\"})\n private int size;\n\n private List arrayList;\n private List linkedList;\n\n @Setup(Level.Invocation)\n public void setup() {\n arrayList = new ArrayList<>();\n linkedList = new LinkedList<>();\n for (int i = 0; i < size; i++) {\n arrayList.add(i);\n linkedList.add(i);\n }\n }\n\n @Benchmark\n public void arrayListInsertBeginning() {\n arrayList.add(0, -1);\n }\n\n @Benchmark\n public void linkedListInsertBeginning() {\n linkedList.add(0, -1);\n }\n\n @Benchmark\n public void arrayListInsertMiddle() {\n arrayList.add(size / 2, -1);\n }\n\n @Benchmark\n public void linkedListInsertMiddle() {\n linkedList.add(size / 2, -1);\n }\n\n @Benchmark\n public void arrayListInsertEnd() {\n arrayList.add(-1);\n }\n\n @Benchmark\n public void linkedListInsertEnd() {\n linkedList.add(-1);\n }\n}\n\n/*\nExpected results (approximate):\n (size) Mode Score\narrayListInsertBeginning 100 avgt 0.5 μs\narrayListInsertBeginning 10000 avgt 50.0 μs\nlinkedListInsertBeginning 100 avgt 0.02 μs\nlinkedListInsertBeginning 10000 avgt 0.02 μs\n\nKey insight: LinkedList O(1) at beginning, but finding middle is O(n)!\n*/\n```\n

\n\n### Exercise 2: Find the Memory Leak\n\n```java\npublic class SessionManager {\n private final Map activeSessions = new HashMap<>();\n private final Map sessionTimestamps = new HashMap<>();\n\n public void createSession(String sessionId, Session session) {\n activeSessions.put(sessionId, session);\n sessionTimestamps.put(sessionId, System.currentTimeMillis());\n }\n\n public Session getSession(String sessionId) {\n Session session = activeSessions.get(sessionId);\n if (session != null) {\n sessionTimestamps.put(sessionId, System.currentTimeMillis());\n }\n return session;\n }\n\n public void invalidateSession(String sessionId) {\n activeSessions.remove(sessionId);\n // Bug: sessionTimestamps not cleaned!\n }\n\n // Called every hour\n public void cleanupExpiredSessions() {\n long now = System.currentTimeMillis();\n long oneHour = 3600_000;\n\n activeSessions.entrySet().removeIf(entry -> {\n Long timestamp = sessionTimestamps.get(entry.getKey());\n return timestamp != null && now - timestamp > oneHour;\n });\n // Bug: sessionTimestamps not cleaned after removal!\n }\n}\n```\n\n

Solution

\n\n```java\npublic class SessionManager {\n private final Map activeSessions = new HashMap<>();\n private final Map sessionTimestamps = new HashMap<>();\n\n public void createSession(String sessionId, Session session) {\n activeSessions.put(sessionId, session);\n sessionTimestamps.put(sessionId, System.currentTimeMillis());\n }\n\n public Session getSession(String sessionId) {\n Session session = activeSessions.get(sessionId);\n if (session != null) {\n sessionTimestamps.put(sessionId, System.currentTimeMillis());\n }\n return session;\n }\n\n public void invalidateSession(String sessionId) {\n activeSessions.remove(sessionId);\n sessionTimestamps.remove(sessionId); // FIX: Clean both maps\n }\n\n public void cleanupExpiredSessions() {\n long now = System.currentTimeMillis();\n long oneHour = 3600_000;\n\n // Collect keys to remove first\n Set toRemove = new HashSet<>();\n\n for (Map.Entry entry : sessionTimestamps.entrySet()) {\n if (now - entry.getValue() > oneHour) {\n toRemove.add(entry.getKey());\n }\n }\n\n // Remove from both maps\n for (String sessionId : toRemove) {\n activeSessions.remove(sessionId);\n sessionTimestamps.remove(sessionId);\n }\n }\n\n // Better approach: Single map with composite value\n public record SessionEntry(Session session, long lastAccessed) {}\n private final Map sessions = new HashMap<>();\n}\n```\n

\n\n### Exercise 3: Optimize This Code\n\n```java\n// This reporting code is slow. Optimize it.\npublic class SalesReport {\n\n public Map calculateTotalsByRegion(\n List sales) {\n Map totals = new HashMap<>();\n\n for (Sale sale : sales) {\n String region = sale.getRegion();\n BigDecimal currentTotal = totals.get(region);\n if (currentTotal == null) {\n currentTotal = BigDecimal.ZERO;\n }\n totals.put(region, currentTotal.add(sale.getAmount()));\n }\n\n return totals;\n }\n\n public List filterByAmountAndSort(\n List sales, BigDecimal minAmount) {\n List filtered = new ArrayList<>();\n\n for (Sale sale : sales) {\n if (sale.getAmount().compareTo(minAmount) >= 0) {\n filtered.add(sale);\n }\n }\n\n Collections.sort(filtered, (a, b) ->\n b.getAmount().compareTo(a.getAmount()));\n\n return filtered;\n }\n\n public Set findUniqueProducts(List sales) {\n List products = new ArrayList<>();\n for (Sale sale : sales) {\n products.addAll(sale.getProducts());\n }\n return new HashSet<>(products);\n }\n}\n```\n\n

Solution

\n\n```java\npublic class SalesReport {\n\n // Optimization 1: Use merge() for single lookup\n public Map calculateTotalsByRegion(\n List sales) {\n Map totals = new HashMap<>(\n estimateRegionCount(sales)); // Pre-size\n\n for (Sale sale : sales) {\n totals.merge(sale.getRegion(), sale.getAmount(), BigDecimal::add);\n }\n\n return totals;\n }\n\n // Or with streams:\n public Map calculateTotalsByRegionStream(\n List sales) {\n return sales.stream()\n .collect(Collectors.groupingBy(\n Sale::getRegion,\n Collectors.reducing(BigDecimal.ZERO,\n Sale::getAmount, BigDecimal::add)\n ));\n }\n\n // Optimization 2: Single pass filter + sort with stream\n public List filterByAmountAndSort(\n List sales, BigDecimal minAmount) {\n return sales.stream()\n .filter(sale -> sale.getAmount().compareTo(minAmount) >= 0)\n .sorted(Comparator.comparing(Sale::getAmount).reversed())\n .collect(Collectors.toCollection(\n () -> new ArrayList<>(sales.size() / 4))); // Estimate\n }\n\n // Optimization 3: Build set directly, avoid intermediate list\n public Set findUniqueProducts(List sales) {\n return sales.stream()\n .flatMap(sale -> sale.getProducts().stream())\n .collect(Collectors.toSet());\n\n // Or without streams:\n Set products = new HashSet<>();\n for (Sale sale : sales) {\n products.addAll(sale.getProducts());\n }\n return products;\n }\n\n private int estimateRegionCount(List sales) {\n // Assume ~50 regions or 10% of sales, whichever is smaller\n return Math.min(50, sales.size() / 10 + 1);\n }\n}\n```\n

\n\n---\n\n## Senior-Level Interview Questions\n\n### Question 1: When would you choose TreeMap over HashMap despite O(log n) vs O(1)?\n\n**Strong Answer:**\n\nSeveral scenarios favor TreeMap:\n\n1. **Need sorted iteration**: HashMap iteration order is undefined\n2. **Range queries**: `subMap()`, `headMap()`, `tailMap()` are O(log n)\n3. **NavigableMap operations**: `floorKey()`, `ceilingKey()`, `higherKey()`\n4. **Small collections**: Constant factors make TreeMap competitive under ~1000 elements\n5. **Memory-constrained**: TreeMap has more predictable memory usage\n6. **Real-time systems**: No sudden O(n) resize operations\n7. **Consistent iteration performance**: Better cache locality than HashMap\n\n```java\n// TreeMap excels at range operations\nNavigableMap events = new TreeMap<>();\n// Get events for Q1\nMap q1Events = events.subMap(\n LocalDate.of(2024, 1, 1),\n LocalDate.of(2024, 4, 1)\n);\n```\n\n---\n\n### Question 2: How would you diagnose a collection-related memory leak in production?\n\n**Strong Answer:**\n\nSystematic approach:\n\n1. **Identify symptoms**: OOM errors, growing heap, GC pauses increasing\n2. **Enable monitoring**: JFR recording, heap metrics via JMX\n3. **Capture heap dump**: `jmap -dump:live,format=b,file=heap.hprof `\n4. **Analyze with MAT/VisualVM**:\n - Dominator tree shows retention paths\n - Look for collections with unexpected size\n - Check for static fields holding collections\n\n```java\n// Common patterns to look for:\n// 1. Static collections that only grow\nstatic Map cache = new HashMap<>(); // Unbounded!\n\n// 2. Listeners not removed\nlisteners.add(callback); // Never removed\n\n// 3. Thread-local collections in pools\nThreadLocal> buffer = ...; // Not cleared\n\n// 4. Keys that changed hashCode after insertion\nmutableKey.setValue(\"new\"); // Now unreachable but retained\n```\n\n5. **Add preventive monitoring**:\n```java\n// Micrometer metrics\nGauge.builder(\"cache.size\", cache, Map::size)\n .register(meterRegistry);\n```\n\n---\n\n### Question 3: Explain the performance implications of ConcurrentHashMap's design choices.\n\n**Strong Answer:**\n\nConcurrentHashMap makes several design trade-offs:\n\n**Segmented locking (pre-Java 8) → Node-level CAS (Java 8+)**\n\n```\nPre-Java 8: Segments (16 default)\n├── Each segment is independent lock\n├── 16x improvement over synchronized HashMap\n└── But still lock contention within segment\n\nJava 8+: Per-node synchronization + CAS\n├── Lock only the bin being modified\n├── CAS for updates when possible\n├── Scales much better with core count\n└── Size tracked with LongAdder (striped counters)\n```\n\n**Key operations**:\n- `get()`: Lock-free with volatile reads\n- `put()`: CAS for empty bin, synchronized for collision\n- `size()`: Approximate (sum of counters) unless forced\n- `computeIfAbsent()`: Atomic but may block bin\n\n**Performance implications**:\n```java\n// GOOD: Lock-free read\nmap.get(key); // No synchronization!\n\n// OK: CAS when lucky\nmap.putIfAbsent(key, value); // CAS if bin empty\n\n// CAREFUL: Locks entire bin during computation\nmap.computeIfAbsent(key, k -> expensiveOperation());\n// Don't do I/O inside compute!\n\n// AVOID: Full traversal under lock\nmap.forEach((k, v) -> ...); // May see inconsistent state\n```\n\n---\n\n### Question 4: How do you benchmark collection performance properly?\n\n**Strong Answer:**\n\nProper benchmarking requires understanding JVM behavior:\n\n1. **Use JMH** - handles warmup, JIT compilation, dead code elimination\n2. **Avoid common mistakes**:\n```java\n// WRONG: Dead code elimination\n@Benchmark\npublic void bad() {\n list.contains(x); // Result unused, JIT removes it!\n}\n\n// CORRECT: Use Blackhole or return\n@Benchmark\npublic boolean good() {\n return list.contains(x);\n}\n```\n\n3. **Control state properly**:\n```java\n@State(Scope.Benchmark) // Shared across threads\n@State(Scope.Thread) // Per-thread state\n\n@Setup(Level.Trial) // Once per benchmark run\n@Setup(Level.Iteration) // Once per measurement iteration\n@Setup(Level.Invocation) // Before each method call (expensive!)\n```\n\n4. **Measure what matters**:\n```java\n@BenchmarkMode(Mode.Throughput) // Ops per second\n@BenchmarkMode(Mode.AverageTime) // Time per op\n@BenchmarkMode(Mode.SampleTime) // Latency percentiles\n```\n\n5. **Account for GC**:\n```java\n@Fork(value = 2, jvmArgs = {\"-Xms4g\", \"-Xmx4g\"}) // Fixed heap\n```\n\n6. **Verify with `-prof gc`** to see allocation rates\n\n---\n\n### Question 5: What's the N+1 problem with collections and how do you avoid it?\n\n**Strong Answer:**\n\nN+1 with collections occurs when:\n\n```java\n// N+1 pattern\nMap> ordersByCustomer = loadOrders(); // 1 query\n\nfor (Customer customer : customers) { // N customers\n List orders = ordersByCustomer.get(customer.getId());\n for (Order order : orders) {\n OrderDetails details = loadDetails(order.getId()); // N×M queries!\n }\n}\n```\n\n**Solutions**:\n\n1. **Batch loading**:\n```java\nSet orderIds = orders.stream()\n .map(Order::getId)\n .collect(Collectors.toSet());\nMap detailsMap = loadDetailsBatch(orderIds); // 1 query\n```\n\n2. **Pre-indexed structures**:\n```java\n// Build lookup structure upfront\nMap> detailsByOrder = allDetails.stream()\n .collect(Collectors.groupingBy(OrderDetails::getOrderId));\n```\n\n3. **JOIN FETCH in JPA**:\n```java\n@Query(\"SELECT c FROM Customer c JOIN FETCH c.orders o JOIN FETCH o.details\")\nList findAllWithOrdersAndDetails();\n```\n\n4. **Stream with proper batching**:\n```java\nLists.partition(orderIds, 1000).stream()\n .flatMap(batch -> loadDetailsBatch(batch).stream())\n .collect(Collectors.toList());\n```\n\n---\n\n### Question 6: How do you choose initial capacity for HashMap?\n\n**Strong Answer:**\n\nHashMap capacity planning:\n\n```java\n// Formula: capacity = expectedSize / loadFactor + 1\n// Default loadFactor = 0.75\n// So for 100 elements: 100 / 0.75 + 1 = 134.33 → next power of 2 = 256\n\n// But HashMap already does this calculation!\n// Just pass expected size:\nnew HashMap<>(100); // Will allocate 256 internally\n\n// However, for maximum efficiency:\nnew HashMap<>((int) (expectedSize / 0.75f) + 1);\n```\n\n**Why it matters**:\n```\nWithout pre-sizing (adding 1M elements):\n├── Start: capacity 16\n├── Resize at 12: copy 12 elements, new capacity 32\n├── Resize at 24: copy 24 elements, new capacity 64\n├── ... 17 more resizes ...\n├── Each resize: O(n) copy + O(n) rehash\n└── Total extra work: ~2M operations, ~2M garbage objects\n\nWith pre-sizing:\n├── Start: capacity 1,398,102 (next power of 2)\n├── No resizes needed\n└── Total extra work: 0\n```\n\n**Best practices**:\n- Pre-size when you know approximate size\n- For streams: use `Collectors.toMap()` (no control) or collect to sized map\n- Consider load factor trade-off: lower = more memory, fewer collisions\n\n---\n\n## Summary & Key Takeaways\n\n### Performance Reality Checklist\n\n```\n✓ Big-O is guidance, not gospel\n - Constant factors matter at small N\n - Cache locality can dominate\n - Profile, don't assume\n\n✓ Memory awareness\n - Object headers: 12-16 bytes each\n - Boxing: 16 bytes per Integer vs 4 bytes per int\n - Collection overhead: 32-64 bytes per entry\n\n✓ Benchmarking discipline\n - Use JMH for accurate results\n - Watch for dead code elimination\n - Include GC in measurements\n\n✓ Production monitoring\n - JFR for non-invasive profiling\n - Metrics for collection sizes\n - Alerts for unbounded growth\n\n✓ Common pitfalls avoided\n - Pre-size when possible\n - Right collection for access pattern\n - Clean up listeners and caches\n - Immutable keys for maps\n```\n\n### Performance Decision Quick Reference\n\n```\nFor lookup-heavy code:\n├── HashSet/HashMap: O(1) average\n├── Pre-size to avoid resizing\n└── Good hashCode() is critical\n\nFor iteration-heavy code:\n├── ArrayList: best cache locality\n├── LinkedHashMap: predictable order\n└── Avoid LinkedList\n\nFor concurrent access:\n├── ConcurrentHashMap: fine-grained locking\n├── CopyOnWriteArrayList: read-heavy, rare writes\n└── Avoid Collections.synchronized*\n\nFor memory efficiency:\n├── Primitive collections (Eclipse, Trove, FastUtil)\n├── EnumSet/EnumMap for enum keys\n└── ArrayList over LinkedList\n```\n\n---\n\n## Conclusion\n\nPerformance optimization is about understanding trade-offs, not memorizing complexity tables. The N+1 problem in our production story wasn't a database issue—it was a data structure issue. By restructuring our pricing rules into a prefix-indexed map, we achieved a 67x performance improvement.\n\nKey principles to remember:\n\n1. **Profile first**: Don't optimize based on assumptions\n2. **Constant factors matter**: O(1) can be slower than O(log n) in practice\n3. **Memory matters**: GC pressure from collection overhead is real\n4. **Right tool for the job**: HashMap isn't always the answer\n5. **Monitor in production**: Unbounded collections become memory leaks\n\nIn Part 29, we'll bring everything together with a comprehensive decision guide and quick reference cheatsheet for choosing the right collection.\n\n---\n\n## 📅 Review Schedule\n\n- **Day 1**: Review performance comparison table and memory footprint calculations\n- **Day 3**: Complete one JMH benchmark exercise\n- **Day 7**: Practice memory leak detection patterns\n- **Day 14**: Review interview questions and explain concepts aloud\n- **Day 30**: Revisit production story and implement monitoring in your codebase\n\n---\n\n## Series Navigation\n\n- **Previous**: [Part 27: Testing & Debugging Collections](/articles/java-collections-part-27-testing-debugging)\n- **Next**: [Part 29: Decision Guide & Quick Reference](/articles/java-collections-part-29-cheatsheet-decision-guide)\n- **Series Start**: [Part 0: How to Use This Series](/articles/java-collections-part-0-how-to-use-this-series)\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:26.212635Z","createdAt","2026-06-10T07:19:26.213531Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",25,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId",5,"seriesOrder",28,"author",{"_31":55,"_100":57,"_101":102,"_103":104,"_105":-5,"_106":-5,"_107":-5,"_108":-5,"_109":-5},"category",{"_31":62,"_73":59,"_35":94,"_76":98,"_99":-5},"tags",[79,80,81,82,83],"series",{"_31":62,"_73":74,"_35":75,"_76":77,"_78":23},"name","Java Collections Compendium: From Fundamentals to Production Mastery","java-collections-compendium","description","A comprehensive 30-part series covering everything about Java Collections Framework. From foundational concepts like generics and equals/hashCode contract, through deep dives into ArrayList, LinkedList, HashMap, TreeMap, ConcurrentHashMap, to modern features like immutable collections, Java 21 sequenced collections, streams & collectors, and production patterns with JPA, Jackson & Spring. Includes real production stories, mental models, exercises, and 50+ interview questions.","isActive",{"_31":95,"_73":96,"_35":97},{"_31":93,"_73":59,"_35":94},{"_31":90,"_73":91,"_35":92},{"_31":87,"_73":88,"_35":89},{"_31":84,"_73":85,"_35":86},382,"Pitfalls","pitfalls",118,"Performance","performance",224,"Optimization","optimization",14,"java",119,"Big-o","big-o","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]