Immutability — Find the Bug¶

12 buggy snippets where a mutability, aliasing, or shared-state mistake causes a real, shippable bug. Each one looks correct on a casual read. Find the leak first — who else holds a reference to this object, and when does it change underneath them? — then read the fix.

Table of Contents¶

1. Snippet 1 — Getter returns the internal slice (Go)
2. Snippet 2 — Mutable default argument (Python)
3. Snippet 3 — Frozen record, mutable list (Java)
4. Snippet 4 — Mutated map key (Python)
5. Snippet 5 — Constructor aliasing (Java)
6. Snippet 6 — Shared backing array via slice (Go)
7. Snippet 7 — Stored time mutated after the fact (Python)
8. Snippet 8 — Shallow copy where deep was needed (Java)
9. Snippet 9 — "Immutable" wrapper around a mutable map (Java)
10. Snippet 10 — Concurrent readers of a mutated singleton (Go)
11. Snippet 11 — Mutating a caller's argument (Python)
12. Snippet 12 — Set membership lost after element mutation (Java)
13. Scorecard
14. Related Topics

How to Use¶

For each snippet:

1. Read the code and ask the immutability questions: Who else holds a reference to this data? Can it change after I hand it out? Is this "constant" actually shared?
2. Write down the exact line where the aliasing or mutation happens and the observable symptom (corrupted state, wrong result, lost map entry, data race).
3. Open the answer. Confirm you found the leak (the shared reference) and not just the mutation (the write). The fix almost always means copying at the boundary or making the type genuinely immutable.

Difficulty is marked per snippet. The mutation that triggers the bug is rarely on the same line as the mistake that allowed it — that distance is the whole point.

Snippet 1 — Getter returns the internal slice (Go)¶

Difficulty: Easy

package order

type Order struct {
    id    string
    items []string
}

func NewOrder(id string) *Order {
    return &Order{id: id, items: []string{}}
}

func (o *Order) AddItem(item string) {
    o.items = append(o.items, item)
}

// Items returns the order's line items.
func (o *Order) Items() []string {
    return o.items
}

// Caller code:
func auditTopItems(o *Order) []string {
    items := o.Items()
    // Auditor only wants the first 3, sorted, for a report.
    sort.Strings(items)
    if len(items) > 3 {
        items = items[:3]
    }
    return items
}

Where is the bug?

func (o *Order) Items() []string {
    out := make([]string, len(o.items))
    copy(out, o.items)
    return out
}

Snippet 2 — Mutable default argument (Python)¶

Difficulty: Easy

def append_event(event, log=[]):
    log.append(event)
    return log


def make_session_logger():
    """Each call should start a fresh, empty log."""
    return append_event


# Two unrelated requests:
req1 = append_event("login")
req2 = append_event("logout")

print(req1)  # expected: ['login']
print(req2)  # expected: ['logout']

Where is the bug?

req1 == ['login', 'logout']
req2 == ['login', 'logout']

def append_event(event, log=None):
    if log is None:
        log = []
    log.append(event)
    return log

Snippet 3 — Frozen record, mutable list (Java)¶

Difficulty: Medium

import java.util.List;
import java.util.ArrayList;

// A "value object" meant to be immutable.
public record Invoice(String id, List<LineItem> lines) {

    public double total() {
        return lines.stream().mapToDouble(LineItem::amount).sum();
    }
}

// Usage:
List<LineItem> lines = new ArrayList<>();
lines.add(new LineItem("Widget", 10.0));
Invoice invoice = new Invoice("INV-001", lines);

double snapshot = invoice.total();   // 10.0
sendToBilling(invoice);              // bills $10.00

// ... elsewhere, the same `lines` list is reused as a scratch buffer:
lines.add(new LineItem("Surprise fee", 999.0));

Where is the bug?

public record Invoice(String id, List<LineItem> lines) {
    public Invoice {                          // compact constructor
        lines = List.copyOf(lines);           // immutable snapshot, defensive copy
    }
    public List<LineItem> lines() {
        return lines;                          // already unmodifiable
    }
}

Snippet 4 — Mutated map key (Python)¶

Difficulty: Medium

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __hash__(self):
        return hash((self.x, self.y))

    def __eq__(self, other):
        return (self.x, self.y) == (other.x, other.y)


# Cache keyed by point:
heat = {}
p = Point(1, 1)
heat[p] = 42

print(heat[p])      # 42

# Reuse the same Point object to scan the next cell:
p.x = 2
p.y = 2
heat[p] = 7

print(heat.get(Point(1, 1)))   # expected to still find 42?
print(len(heat))

Where is the bug?

from dataclasses import dataclass

@dataclass(frozen=True)
class Point:
    x: int
    y: int

heat = {}
heat[Point(1, 1)] = 42
heat[Point(2, 2)] = 7   # must construct a NEW point — cannot mutate the old one

Snippet 5 — Constructor aliasing (Java)¶

Difficulty: Medium

import java.util.List;

public class Team {
    private final List<String> members;

    public Team(List<String> members) {
        this.members = members;   // stored by reference
    }

    public List<String> getMembers() {
        return members;
    }
}

// Usage:
List<String> roster = new ArrayList<>(List.of("Ada", "Linus"));

Team teamA = new Team(roster);
Team teamB = new Team(roster);   // same list passed to both

teamA.getMembers().add("Grace");

System.out.println(teamB.getMembers());  // who is on team B?

Where is the bug?

public Team(List<String> members) {
    this.members = new ArrayList<>(members);   // own copy, no aliasing
}

public List<String> getMembers() {
    return Collections.unmodifiableList(members);  // callers cannot mutate internals
}

Snippet 6 — Shared backing array via slice (Go)¶

Difficulty: Hard

package main

import "fmt"

// splitBatch returns the first n items as a "batch" and the rest as "remaining".
func splitBatch(items []int, n int) (batch, remaining []int) {
    batch = items[:n]
    remaining = items[n:]
    return
}

func main() {
    items := []int{1, 2, 3, 4, 5}
    batch, remaining := splitBatch(items, 2)

    // Tag every item in the batch as processed by negating it.
    batch = append(batch, -1) // append a sentinel to mark end-of-batch

    fmt.Println("batch:", batch)         // [1 2 -1]
    fmt.Println("remaining:", remaining) // expected [3 4 5]?
}

Where is the bug?

batch:     [1 2 -1]
remaining: [-1 4 5]   // index 0 got stomped, not [3 4 5]

batch = items[:n:n]   // len=n, cap=n  -> append must reallocate
remaining = items[n:]

Snippet 7 — Stored time mutated after the fact (Python)¶

Difficulty: Medium

from datetime import datetime, timedelta


class AuditEntry:
    def __init__(self, action, occurred_at):
        self.action = action
        self.occurred_at = occurred_at


def record_actions(actions, clock):
    """clock is a mutable cursor advanced as we walk the actions."""
    entries = []
    for action in actions:
        entries.append(AuditEntry(action, clock))
        clock += timedelta(seconds=1)  # advance the cursor
    return entries


start = datetime(2026, 1, 1, 12, 0, 0)
entries = record_actions(["login", "view", "logout"], start)

for e in entries:
    print(e.action, e.occurred_at)

Where is the bug?

// Java with the mutable legacy Calendar — the bug DOES fire:
Calendar clock = Calendar.getInstance();
List<AuditEntry> entries = new ArrayList<>();
for (String action : actions) {
    entries.add(new AuditEntry(action, clock));   // stores the SAME Calendar ref
    clock.add(Calendar.SECOND, 1);                // mutates that shared object
}
// Every entry now reports the FINAL time — all three are 12:00:02.

entries.add(new AuditEntry(action, Instant.now()));   // java.time is immutable

Snippet 8 — Shallow copy where deep was needed (Java)¶

Difficulty: Hard

import java.util.*;

public class Board {
    private List<List<Integer>> grid;   // grid of rows

    public Board(List<List<Integer>> grid) {
        this.grid = grid;
    }

    // Return a copy so callers can experiment with moves without
    // affecting the original board.
    public Board copy() {
        return new Board(new ArrayList<>(this.grid));
    }

    public void set(int row, int col, int value) {
        grid.get(row).set(col, value);
    }

    public int get(int row, int col) {
        return grid.get(row).get(col);
    }
}

// Usage:
Board original = new Board(List.of(
    new ArrayList<>(List.of(0, 0)),
    new ArrayList<>(List.of(0, 0))
));

Board trial = original.copy();
trial.set(0, 0, 9);                 // experiment on the copy

System.out.println(original.get(0, 0));  // expected 0?

Where is the bug?

public Board copy() {
    List<List<Integer>> deep = new ArrayList<>(grid.size());
    for (List<Integer> row : grid) {
        deep.add(new ArrayList<>(row));   // copy each row
    }
    return new Board(deep);
}

Snippet 9 — "Immutable" wrapper around a mutable map (Java)¶

Difficulty: Hard

import java.util.*;

public final class Config {
    private final Map<String, String> settings;

    public Config(Map<String, String> settings) {
        // Wrap in an unmodifiable view so the config is "immutable".
        this.settings = Collections.unmodifiableMap(settings);
    }

    public String get(String key) {
        return settings.get(key);
    }
}

// Usage:
Map<String, String> raw = new HashMap<>();
raw.put("timeout", "30");
Config config = new Config(raw);

System.out.println(config.get("timeout"));  // 30

// Much later, the loader reuses `raw` to build the next config:
raw.put("timeout", "5000");

System.out.println(config.get("timeout"));  // still 30?

Where is the bug?

public Config(Map<String, String> settings) {
    this.settings = Map.copyOf(settings);   // immutable snapshot, severs aliasing
}

Snippet 10 — Concurrent readers of a mutated singleton (Go)¶

Difficulty: Hard

package featureflags

import "sync"

// flags is treated as a read-only, "effectively immutable" snapshot
// after startup, so reads are done without locking for speed.
var flags = map[string]bool{}
var mu sync.Mutex

func Load(initial map[string]bool) {
    flags = initial
}

// Enabled is called on the hot path by many goroutines, no lock.
func Enabled(name string) bool {
    return flags[name]
}

// Refresh is called by a background goroutine every 30s.
func Refresh(updates map[string]bool) {
    mu.Lock()
    defer mu.Unlock()
    for k, v := range updates {
        flags[k] = v   // mutate the live map in place
    }
}

Where is the bug?

import (
    "sync/atomic"
)

var flags atomic.Pointer[map[string]bool]

func Load(initial map[string]bool) {
    m := initial
    flags.Store(&m)
}

func Enabled(name string) bool {
    m := flags.Load()
    return (*m)[name]   // reading a map that is never mutated after publish
}

func Refresh(updates map[string]bool) {
    old := *flags.Load()
    next := make(map[string]bool, len(old)+len(updates))
    for k, v := range old {
        next[k] = v
    }
    for k, v := range updates {
        next[k] = v
    }
    flags.Store(&next)   // atomic swap; old snapshot stays valid for in-flight readers
}

Snippet 11 — Mutating a caller's argument (Python)¶

Difficulty: Easy

def normalize_tags(tags):
    """Lowercase and dedupe tags, returning the cleaned list."""
    for i in range(len(tags)):
        tags[i] = tags[i].lower()
    seen = set()
    result = []
    for t in tags:
        if t not in seen:
            seen.add(t)
            result.append(t)
    return result


# Caller:
original = ["Python", "GO", "python"]
cleaned = normalize_tags(original)

print(cleaned)    # ['python', 'go']
print(original)   # what is in here now?

Where is the bug?

cleaned  == ['python', 'go']
original == ['python', 'go', 'python']   # lowercased, NOT deduped, mutated

def normalize_tags(tags):
    seen = set()
    result = []
    for t in tags:
        low = t.lower()
        if low not in seen:
            seen.add(low)
            result.append(low)
    return result

Snippet 12 — Set membership lost after element mutation (Java)¶

Difficulty: Medium

import java.util.*;

public class Tag {
    String name;
    Tag(String name) { this.name = name; }

    @Override public int hashCode() { return name.hashCode(); }
    @Override public boolean equals(Object o) {
        return o instanceof Tag t && t.name.equals(this.name);
    }
}

// Usage:
Set<Tag> tags = new HashSet<>();
Tag t = new Tag("draft");
tags.add(t);

System.out.println(tags.contains(t));  // true

// Rename the tag in place:
t.name = "published";

System.out.println(tags.contains(t));   // still true?
System.out.println(tags.contains(new Tag("published")));

Where is the bug?

public final class Tag {
    private final String name;
    public Tag(String name) { this.name = name; }
    public String name() { return name; }
    @Override public int hashCode() { return name.hashCode(); }
    @Override public boolean equals(Object o) {
        return o instanceof Tag t && t.name.equals(this.name);
    }
}

// To rename:
tags.remove(t);
tags.add(new Tag("published"));

Scorecard¶

Track how many you diagnosed correctly. For each, the real test is whether you named the leak (the shared reference), not just the symptom.

Scoring:

• 10–12: You reflexively ask "who else holds this reference?" before handing out or storing any object. This is the senior instinct.
• 7–9: Strong. Revisit the two you missed and identify the exact line that created the alias, separate from the line that mutated.
• 4–6: You spot mutations but not the aliasing that enables them. Re-read snippets 5, 6, 8, and 9 — they all turn on the difference between copying a reference and copying the data.
• 0–3: Work through the chapter README on defensive copying and genuine immutability, then return.

The recurring fix across almost every snippet: copy at the boundary (defensive copy on input and output) or make the type genuinely immutable so the dangerous mutation cannot be written at all.

Related Topics¶

• README.md — the positive rules of this chapter: immutable value objects, defensive copying, copy-on-write.
• junior.md — foundational definitions: aliasing, references vs. values, shallow vs. deep copy.
• tasks.md — exercises to convert mutable, alias-prone types into immutable ones.
• Code Smells — Mutable Data and Feature Envy smells that frequently accompany these bugs.
• Anti-Patterns — broader catalog of design mistakes, including shared-state and global-mutable-state anti-patterns.