String vs StringBuilder vs StringBuffer in Java

Why interviewers love this: it quickly reveals whether you understand Java string handling, performance, and thread safety instead of just memorizing class names.

Question: What is the difference between String, StringBuilder, and StringBuffer in Java, and when should you use each one?

Answer: String is immutable, which means every change creates a new object. StringBuilder and StringBuffer are mutable, so they let you change the same object without creating a new one every time. The big difference between the two builders is that StringBuffer is synchronized, meaning it is safe for simple shared use across threads, while StringBuilder is faster but not thread-safe.

Interview-Ready Answer: I use String when the text will not change, StringBuilder when I am doing lots of concatenation in a single thread, and StringBuffer only when I need a mutable string with built-in synchronization. The key performance idea is that repeated + concatenation on String can create many temporary objects, while a builder reuses one buffer.

What each class really is

Detailed Explanation: These three classes all help you work with text, but they solve different problems. String is the standard text type in Java. A StringBuilder is a mutable character sequence, meaning its contents can be changed after creation. StringBuffer is also mutable, but it adds synchronization, which is a mechanism that prevents two threads from changing the same object at the same time.

How they work under the hood

1. String stores characters in an internal array and cannot be modified in place. When you do s = s + "x", Java creates a new string with the combined content.
2. StringBuilder keeps a resizable internal character buffer. When it runs out of space, it grows the buffer, usually by allocating a larger array and copying the old content over.
3. StringBuffer uses the same basic idea as StringBuilder, but its methods are synchronized so only one thread at a time can safely mutate it.
4. Because of that lock, StringBuffer has extra overhead, so it is usually slower than StringBuilder in single-threaded code.
5. In modern Java, the compiler may optimize simple string concatenation with StringBuilder behind the scenes, but that does not change the rule of thumb: in loops, use a builder explicitly when you are repeatedly appending.

When to use each one

• Use String for names, IDs, file paths, HTTP headers, log messages, and any value that should not change.
• Use StringBuilder when you are assembling text in a loop, building SQL fragments, formatting output manually, or generating JSON-like text in a single thread.
• Use StringBuffer only when you truly need a mutable string object shared by multiple threads and you want built-in synchronization.

Performance and complexity

Appending one piece at a time with a builder is usually close to O(n) total for the final text size, because the buffer grows occasionally. Repeated String concatenation in a loop can behave much worse because each step copies the whole current text again, which can push it toward O(n^2) work in practice. The default initial capacity of StringBuilder and StringBuffer is typically 16 characters, so tiny strings may reallocate as they grow. That growth strategy is why builders are efficient for assembling larger text pieces.

Important edge cases and gotchas

• StringBuilder and StringBuffer are not immutable, so if you pass them around and multiple parts of code mutate them, the final result can be surprising.
• StringBuffer is thread-safe for individual method calls, but that does not automatically make a whole multi-step sequence logically safe. You may still need external synchronization for a larger operation.
• toString() on a builder creates a new String. That is usually what you want before returning or storing text.
• For one or two concatenations, plain String is perfectly fine. Prematurely using a builder everywhere can make code harder to read without helping performance.

Memory hook

Think of String as a sealed letter, StringBuilder as a whiteboard, and StringBuffer as a whiteboard with a lock on the door.

Real-World Story: Imagine a checkout service that builds a long order summary for emails and receipts. If the code concatenates dozens of fields with String inside a loop, every appended line can allocate a new object, which adds GC pressure and slows the request path. A StringBuilder keeps the summary in one growable buffer, so the service stays faster under load.

A misunderstanding here can cause a real outage pattern: CPU rises, latency climbs, and the garbage collector works harder because thousands of short-lived strings are being created every second. In logs you might see normal business events but increasing response times, especially during bulk order exports or notification runs. The fix is often boring but effective: switch repeated concatenation to a builder and reduce temporary object creation.

Follow-up & Tricky Questions:

• What is the difference between StringBuilder and StringBuffer?
  Both are mutable, but StringBuffer synchronizes its methods, so it is safer for shared use across threads but usually slower.
• Why is repeated + concatenation in a loop slow?
  Because each step may create a new string and copy the old contents again, which creates lots of temporary objects and extra copying.
• When would you still use StringBuffer?
  Mostly in legacy code or rare cases where a mutable text object is shared across threads and you want method-level synchronization without adding your own lock.
• Does StringBuilder ever grow automatically?
  Yes. When its internal buffer fills up, it allocates a larger array and copies the existing characters into it.
• Is String always slower than StringBuilder?
  No. For one-off values or a small number of concatenations, String is fine and often clearer. Builders pay off when you do many appends.
• Tricky: Is StringBuffer enough to make any code thread-safe?
  No. It only makes individual method calls synchronized; a larger multi-step workflow may still need external synchronization.
• Tricky: Does StringBuilder.append(null) throw a NullPointerException?
  No. It appends the text "null", which surprises many candidates.
• Tricky: Is new String("abc") useful?
  Usually no. It creates a new object unnecessarily in most cases, because the string literal already exists or can be reused.

Common Mistakes:

• Using String in a loop for heavy concatenation — fix it by switching to StringBuilder.
• Choosing StringBuffer by default — fix it by using StringBuilder unless you truly need synchronization.
• Thinking synchronization makes everything safe — fix it by remembering that thread safety of a whole operation may need more than synchronized methods.
• Forgetting to call toString() before returning text — fix it by converting builders to immutable String at the boundary.

Memory Hook: Letter, Whiteboard, Locked Whiteboard — String is a sealed letter, StringBuilder is a writable whiteboard, and StringBuffer is a writable whiteboard with a lock.

Cheat Sheet:

• String = immutable text.
• StringBuilder = fast mutable text, single-thread use.
• StringBuffer = mutable text with synchronization.
• Use StringBuilder for repeated append operations.
• Use String for read-only values and simple cases.
• StringBuffer is mainly for legacy or synchronized shared use.

Practice Tasks:

• Rewrite a loop that builds a comma-separated list using StringBuilder.
• Compare the output and readability of String concatenation vs StringBuilder in a report generator.
• Take a shared text-building example and decide whether it really needs StringBuffer or a different synchronization strategy.