Java String vs StringBuilder vs StringBuffer

Java String vs StringBuilder vs StringBuffer

Three classes. All three work with text. All three live in java.lang. A developer writing their first Java program uses String without thinking twice. A developer working on a report generator that builds a ten-thousand-line output discovers that using + in a loop is unbearably slow and switches to StringBuilder. A developer building a shared logging system for a multi-threaded application learns that StringBuilder is not safe to share between threads and reaches for StringBuffer.

Each class exists because the previous one could not handle a specific real-world need. Understanding when to use each — and why — separates code that works from code that works well.

The Core Distinction in One Place

String           — Immutable.  Every change creates a new object.
                   Safe for sharing. Safe for equality comparison.
                   Use for values you do not build iteratively.

StringBuilder    — Mutable.    Modifies the same buffer in place.
                   NOT thread-safe. Fastest for building strings.
                   Use inside loops and single-threaded builders.

StringBuffer     — Mutable.    Same API as StringBuilder.
                   Thread-safe — every method is synchronised.
                   Use only when multiple threads share one buffer.

Performance order (fastest to slowest for building):
  StringBuilder  >  StringBuffer  >  String (+)
  (no sync)         (sync overhead)   (new obj each concat)

1 — String: Immutable, Safe, Everywhere

Every String operation returns a new String. The original is never modified. This is not a limitation — it is a deliberate design that makes Strings safe to share between threads without any synchronisation, safe to use as HashMap keys, and eligible for pool reuse.

Output:
Original  : mumbai
Upper     : MUMBAI
Replaced  : delhi
city still: mumbai

Name: Priya | Role: Developer

Loop result: item1,item2,item3,item4,item5,

Is placed: true

2 — StringBuilder: Mutable, Fast, Single-Threaded

StringBuilder maintains a single internal buffer. Every append(), insert(), delete(), and replace() modifies the same buffer. No new objects are created until toString() is called. It is not synchronised — safe and fast in a single thread, undefined behaviour if shared across threads.

Output:
Loop result: item1,item2,item3,item4,item5,

Modified: avaJ!!!

Order: ORD-001 | Customer: Priya | Amount: Rs.1299 | Status: PLACED

This is safe to use here.

3 — StringBuffer: Mutable, Thread-Safe, Shared

StringBuffer is identical to StringBuilder in every method — same append(), insert(), delete(), replace(), reverse(). The only difference: every method carries synchronized. One thread at a time. Correct for concurrent access, slower than StringBuilder due to locking.

Output:
StringBuffer — all messages present:
Message count : 9
Contains T1   : true
Contains T2   : true
Contains T3   : true
No data loss  : true

Original  : Java StringBuffer
insert    : Java is StringBuffer
delete    : is StringBuffer
replace   : IS StringBuffer
reverse   : reffuBgnirtS SI

Side-by-Side Performance Comparison

Output:
Performance comparison (100000 iterations):
─────────────────────────────────────────────
String (+)           :  2843 ms
StringBuilder        :     7 ms
StringBuffer         :    18 ms
─────────────────────────────────────────────
String is ~406x slower than StringBuilder
StringBuffer is ~2x slower than StringBuilder

StringBuilder is the fastest. StringBuffer is around 2x slower due to the synchronisation overhead. String + in a loop is hundreds of times slower because it creates a new String object on every iteration — for 100,000 iterations, the total amount of data copied grows quadratically.

Complete Comparison Table

Decision Guide — Which One to Use

START: Do you need to BUILD a string by combining parts?
         |
        NO → Use String
              Examples:
              — "ORDER_PLACED" (constant)
              — comparing: "admin".equals(role)
              — method parameters: void process(String name)
         |
        YES → Is the building happening INSIDE A LOOP
              or does it need insert/delete/replace?
                  |
                 NO → Small, fixed number of + concatenations
                       Compiler handles it → String + is fine
                       "Name: " + name + " | Age: " + age
                  |
                 YES → Will the buffer be SHARED BETWEEN
                       MULTIPLE THREADS simultaneously?
                           |
                          NO → Use StringBuilder
                                — local variable in a method
                                — building a report / email
                                — constructing a SQL query
                                — assembling a JSON string
                           |
                          YES → Use StringBuffer
                                — shared log buffer
                                — concurrent event collector
                                — multi-thread message aggregator

When Each One Is Correct — Real Examples

Output:
=== String ===
Is PLACED: true
Is PLACED: false
Default  : PENDING

=== StringBuilder ===
CSV: ORD-001,Priya,1299.50,PLACED
HTML: <ul><li>Laptop</li><li>Mouse</li><li>Keyboard</li></ul>

=== StringBuffer ===
Log has content: true
Log line count : 3

The Compiler and String +

A common misconception is that String + is always bad. The Java compiler is smarter than that. For simple, non-loop expressions, it automatically converts + to StringBuilder internally.

Output:
Name: Priya | Age: 24 | Role: Developer

Loop with + : 01234
Loop with SB: 01234

Same output, very different performance for large loops.
Compiler optimises simple expressions, NOT loops.

The two outputs are identical, but the performance is not. The + loop creates a new StringBuilder and a new String object on every single iteration. For 100,000 iterations, that is 100,000 StringBuilder and 100,000 String objects created and discarded. The explicit StringBuilder loop uses one buffer throughout.

Basic Example

Output

String        : Hi there
StringBuilder : Hi there
StringBuffer  : Hi there

How it works:

1. ›s = s + " there" does not modify the original "Hi" — it builds a new String object and makes s point to it.
2. ›sb.append(" there") modifies the same StringBuilder buffer in place — no new object is created for the append.
3. ›sbf.append(" there") does the same as StringBuilder, but the method is synchronized, so it is safe even if multiple threads shared this buffer.
4. ›All three produce the identical text, but they get there differently — which is why the right choice depends on whether you are building text in a loop (StringBuilder), sharing it across threads (StringBuffer), or just holding a fixed value (String).

Best Practices

Default to String for values you read but do not build. Configuration values, method parameters, comparison targets, HashMap keys, and return values that come from a single expression are all best represented as String. Immutability means safe sharing, safe use as map keys, and no defensive copying needed.

Default to StringBuilder for anything you build iteratively. Any time you write a for loop or while loop that builds a string piece by piece, use StringBuilder. The performance difference over String + grows from negligible at 5 iterations to hundreds of times faster at 100,000 iterations.

Use StringBuffer only when you have confirmed multi-threaded shared access. The synchronisation overhead is real — StringBuffer is about twice as slow as StringBuilder. Introducing that overhead in single-threaded code is a performance regression with no correctness benefit.

For simple fixed concatenations outside loops, String + is fine. The Java compiler converts "Hello, " + name + "!" to StringBuilder internally. You gain nothing by writing new StringBuilder().append("Hello, ").append(name).append("!").toString() for two or three parts outside a loop.

Common Mistakes

Mistake 1 — String + in a Loop

Mistake 2 — StringBuilder in a Multi-Threaded Shared Context

Mistake 3 — Comparing StringBuilder or StringBuffer With equals()

Neither StringBuilder nor StringBuffer overrides equals(). Calling equals() on them compares object references, not content. Always call toString() before comparing.

Mistake 4 — Using StringBuilder as a HashMap Key

StringBuilder's hashCode() is based on its object identity — not its content. Even if it were content-based, mutating the key after insertion would corrupt the map. Always use immutable String as HashMap keys.

Interview Questions

Q1. What are the main differences between String, StringBuilder, and StringBuffer?

String is immutable — every modification creates a new object. It is thread-safe by design, eligible for String Pool reuse, and correct for equality comparison via equals(). StringBuilder is mutable — it modifies its internal buffer in place, is not thread-safe, and is the fastest option for building strings iteratively in a single thread. StringBuffer is mutable with the same API as StringBuilder but every method is synchronised, making it thread-safe at the cost of performance overhead. Use String for fixed values, StringBuilder for loops, StringBuffer for multi-threaded shared buffers.

Q2. When should you use StringBuilder over String concatenation with +?

Whenever string building happens inside a loop or involves a variable number of parts. The Java compiler converts simple multi-part + expressions outside loops into StringBuilder automatically — so "Hello, " + name + "!" is already efficient. But in a loop, each iteration creates a new StringBuilder and discards it, producing O(n²) character copy work. An explicit StringBuilder declared outside the loop reuses the same buffer for all iterations, reducing copy work to O(n). The difference is negligible for 5 iterations and hundreds of times for 100,000.

Q3. Is StringBuffer fully thread-safe for compound operations?

Each individual method call is thread-safe — only one thread can execute any given method at a time. But a sequence of calls is not atomic. If Thread A reads sb.length() and then calls sb.insert(length, value), Thread B could modify the buffer between those two calls. The result of Thread A's insert would then target a position that no longer reflects what it read. For compound read-then-modify operations, callers must wrap the sequence in a synchronized (buffer) block themselves.

Q4. Does the Java compiler optimise String + automatically?

Yes, for simple expressions. The compiler converts "a" + b + "c" to equivalent StringBuilder code. However, this optimisation does not apply across loop iterations. Each iteration of result = result + item compiles to a new StringBuilder that wraps the current result, appends item, and calls toString() — creating a new String each time. For loops, explicit StringBuilder outside the loop is required to get the performance benefit.

Q5. Why can you not use StringBuilder as a HashMap key?

StringBuilder does not override hashCode() or equals(). Its hashCode() is based on object identity — the memory address — not on content. If you put a StringBuilder as a key and then mutate it (which is easy since it is mutable), the hash code changes and the map can no longer find the key. HashMap stores entries by initial hash — after mutation, lookups compute a different hash, land in a different bucket, and find nothing. Always use immutable String as map keys — its content-based hashCode() is stable.

Q6. What is the output of new StringBuilder("hello").equals(new StringBuilder("hello"))?

false. StringBuilder inherits equals() from Object, which compares references — not content. Two different StringBuilder objects with the same content are not equal by equals(). To compare content, call toString() first: sb1.toString().equals(sb2.toString()). This is a common interview trap — unlike String, which overrides equals() to compare characters, StringBuilder and StringBuffer do not.

FAQs

Can you convert between String, StringBuilder, and StringBuffer?

Yes. new StringBuilder(str) creates a StringBuilder from a String. sb.toString() converts a StringBuilder back to a String. new StringBuffer(sb.toString()) converts from StringBuilder to StringBuffer. All three also accept CharSequence in their constructors — the interface that all three implement — so conversion is always straightforward.

Does String.format() use StringBuilder internally?

Yes. String.format() builds the result using a Formatter which internally uses StringBuilder. So String.format("Name: %s | Age: %d", name, age) is efficient — no multiple String objects are created in the process. For formatting a single structured output string, String.format() is clean and readable. For building many formatted strings in a loop, pre-allocate a StringBuilder and use Formatter or String.format() per item, appending results.

Which should you use in a Spring Boot REST controller?

For building response bodies, JSON strings, or HTML in a controller method — use StringBuilder. These methods run in a single thread per request (the request-handling thread). The StringBuilder is local to the method — it is never shared. For any shared state that multiple request threads write to concurrently (like a shared in-memory log), use StringBuffer or better: a ConcurrentLinkedQueue or logging framework.

Do modern Java features replace StringBuilder?

For many common cases, yes. Java 8 String.join() replaces delimiter-separated list building. Streams with Collectors.joining() replace loop-based aggregation. Java 15 text blocks replace multi-line string construction with +. For complex dynamic building — conditional appends, template filling, HTML generation — StringBuilder is still the clearest tool.

Is there any case where String + is faster than StringBuilder?

For a single concatenation — "Hello, " + name — the compiler-generated StringBuilder code and manual StringBuilder produce identical bytecode. For two or three fixed parts outside a loop, there is no performance difference. String + only becomes significantly slower when it is inside a loop where the compiler cannot carry the same StringBuilder across iterations.

Summary

String, StringBuilder, and StringBuffer each exist because the others could not handle a specific real-world need efficiently and correctly.

String is the default — immutable, safe to share, eligible for pool reuse, correct for equality comparison. Use it for everything that is not iteratively built.

StringBuilder is the loop workhorse — single mutable buffer, fastest possible building, not thread-safe. Use it any time you assemble a string in a loop or through multiple conditional appends in one thread.

StringBuffer is the concurrent option — same methods as StringBuilder with synchronisation on every call. Use it when one buffer object is written by multiple threads simultaneously.

The decision is almost never difficult in practice: String for values, StringBuilder for building, StringBuffer only when the building is concurrent.

What to Read Next