Does Append Always Allocate New Memory
Fast recall
Quick revision
Core answer
Practical understanding of Append And Growth.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
It depends entirely on where the length sits relative to capacity, and the distinction has real correctness consequences — not just performance ones.
Spare capacity: append writes the element into the next slot of the existing backing array. No allocation, no copy — and every other slice sharing that array sees the write. This is the fastest path, and it's the one that makes sub-slice-then-append change the original slice, the classic aliasing surprise.
At capacity: append allocates a new array sized for growth, copies the old elements in, appends the new one, and returns the new header. Slices still viewing the old array don't see any of this — they've permanently forked.
So the honest phrasing is 'may allocate'. Any code whose correctness depends on either branch — sharing preserved, or sharing severed — needs to control capacity deliberately rather than rely on append's choice.
Does Append Always Allocate New Memory
Direct Answer
No — below capacity it writes in place into the existing array, visible to every alias. Only at len == cap does it allocate, copy, and fork.
Deep Dive & Architecture
The two modes, traced against the same start:
// Mode A: spare capacity — in-place
a := make([]int, 2, 4) // len 2, cap 4 — two spare slots
b := append(a, 9) // writes a's array[2] — shared
b[0] = 100
fmt.Println(a[0]) // 100 — a sees it, same array
// Mode B: at capacity — fork
c := []int{1, 2} // len 2, cap 2 — no spare
d := append(c, 9) // allocates new array, copies
d[0] = 100
fmt.Println(c[0]) // 1 — c points at the old array
Same operation, opposite sharing outcomes — the only variable was capacity. This is why append-heavy APIs document their aliasing behavior: callers who pass a sub-slice and later read the original need to know which mode they'll get.
The performance angle is real too — pre-sizing with make([]T, 0, n) pins every append to mode A, turning an O(n²) grow-copy chain into O(n) total — but it's the correctness angle that bites in code review.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Append And Growth, and when would you use it?
- How would you compare Append And Growth with an alternative?
- What is a common mistake when using Append And Growth?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.