StringBuilder vs StringBuffer — does the difference still matter in modern code?

“StringBuilder vs StringBuffer — does the difference still matter in modern code?”

StringBuilder

not synchronized — faster, default

StringBuffer

synchronized — legacy

Reality

buffers are local → no sharing → no lock needed

StringBuilder sb = new StringBuilder(64); // pre-size to avoid resizes
for (Order o : orders) sb.append(o.id()).append(',');
String csv = sb.toString();

Time:

O(n) total — vs O(n²) for String + in a loop

Building a large CSV/JSON payload with `result += line` in a loop is a frequent cause of CPU spikes; switching to a pre-sized StringBuilder fixes it.

Keywords they're listening for:

• ✓ synchronized vs not
• ✓ default to StringBuilder
• ✓ + in loop is O(n²)
• ✓ pre-sizing capacity

• ✗Using StringBuffer 'just in case' for thread-safety it doesn't need
• ✗String += inside a loop
• ✗Not pre-sizing when the length is known

• ✓Default to StringBuilder; pre-size with an initial capacity
• ✓Reserve StringBuffer for genuinely shared mutable buffers (rare)
• ✓Use String.join / Collectors.joining for simple cases

1. 1How does StringBuilder grow its internal array?
2. 2What does the compiler do with a + b + c in one expression?
3. 3When is StringBuffer ever justified?

• String.join
• Collectors.joining
• StringConcatFactory (invokedynamic)