Java StringBuffer

Java StringBuffer

Java has three classes for working with strings: String, StringBuilder, and StringBuffer. Two of them — StringBuilder and StringBuffer — look almost identical. They have the same methods, the same mutable buffer design, and even the same API. The difference is a single word: synchronised.

StringBuffer was introduced in Java 1.0 as the mutable alternative to the immutable String. Every method in StringBuffer is synchronised — meaning only one thread can execute it at a time. This thread safety came at a performance cost. When Java 1.5 introduced StringBuilder as an unsynchronised alternative, most single-threaded use cases migrated to StringBuilder. But StringBuffer still has its place — any time a single mutable string object must be safely shared and modified across multiple threads.

What Is StringBuffer?

StringBuffer is a thread-safe, mutable sequence of characters in java.lang. Like StringBuilder, it maintains an internal character buffer that grows as content is added. Unlike StringBuilder, every method that reads or modifies the buffer carries the synchronized keyword — the JVM enforces that only one thread can be inside any of these methods at a time.

StringBuffer internal structure:

  StringBuffer sb = new StringBuffer("Hello");

  ┌─────────────────────────────────────────────┐
  │  StringBuffer object                        │
  │                                             │
  │  char[] value = ['H','e','l','l','o', , , ]│  ← internal buffer
  │  int count = 5                              │  ← current length
  │  int capacity = 21                          │  ← buffer size
  │                                             │
  │  All methods: synchronized                  │
  │  Only ONE thread can enter at a time        │
  └─────────────────────────────────────────────┘

  Thread 1 calling append("!") ──► acquires lock ──► appends ──► releases lock
  Thread 2 calling append("?") ──► waits for lock ──► appends ──► releases lock
                                   (never interleaves)

The synchronisation is per-method. If two threads call append() concurrently, one waits for the other to finish. This prevents character interleaving and corrupt internal state — the two main risks when multiple threads write to the same buffer simultaneously.

Creating a StringBuffer

Output:
Empty capacity : 16
Empty length   : 0
128 capacity   : 128
Content        : DevStackFlow
Content length : 12
Content cap    : 28
From CharSeq   : Learning Java

Auto capacity  : 12
Content        : Hello World!

The capacity behaviour is identical to StringBuilder — starts at 16 by default, grows to (oldCapacity * 2) + 2 when content exceeds it.

Core Methods of StringBuffer

StringBuffer shares all the same methods as StringBuilder. Every one of them is synchronised.

append()

Output:
Order ID : ORD-2024-001
Amount   : Rs.1299.5
Quantity : 3
Paid     : true

========================================
  INVOICE SUMMARY
========================================

insert(), delete(), replace(), reverse()

Output:
After insert   : Hello, World
After delete   : World
After delChar  : Worl
After replace  : Java
After reverse  : avaJ

After setCharAt: Java
indexOf('abc')     : 0
indexOf('abc', 1)  : 3
lastIndexOf('abc') : 6

Thread Safety — What It Actually Means

The synchronized keyword on every StringBuffer method means the JVM locks the object before any thread can execute the method. This section demonstrates the problem StringBuffer solves.

Output:
StringBuilder (unsafe):
  Expected length: 2000
  Actual   length: 1893    ← unpredictable — may differ each run

StringBuffer (thread-safe):
  Expected length: 2000
  Actual   length: 2000    ← always correct

StringBuilder's length may be less than 2000 because two threads can read the same length value, both compute the same next write position, and overwrite each other's character — a classic race condition. StringBuffer's lock prevents this: only one thread appends at a time, so every "A" is written correctly.

StringBuffer vs StringBuilder vs String — Comparison Table

When to Choose StringBuffer Over StringBuilder

The decision comes down to one question: is this buffer accessed by more than one thread at the same time?

Single-threaded (most common case):

  Method generates a report:              Use StringBuilder
  ┌─────────────────────────────────┐
  │  void generateReport() {        │
  │    StringBuilder sb = new ...   │  ← local variable, never shared
  │    sb.append(data);             │
  │    return sb.toString();        │
  │  }                              │
  └─────────────────────────────────┘

Multi-threaded (StringBuffer needed):

  Shared log buffer for all threads:      Use StringBuffer
  ┌─────────────────────────────────┐
  │  class Logger {                 │
  │    StringBuffer log =           │  ← instance field, shared
  │      new StringBuffer();        │     by multiple threads
  │                                 │
  │    void write(String msg) {     │
  │      log.append(msg);           │  ← multiple threads call this
  │    }                            │
  │  }                              │
  └─────────────────────────────────┘

Output:
REPORT
====================
Laptop          Rs.45999.00
Mouse           Rs.599.00
Keyboard        Rs.1299.00

=== Shared Audit Log (all 9 entries) ===
Total entries: 9
Log length is non-zero: true

buildReport uses StringBuilder — it is a local variable never seen by another thread. SharedAuditLog uses StringBuffer — three threads write to the same buffer concurrently, and synchronisation prevents corruption.

Basic Example

Output

Expected length: 2000
Actual length  : 2000

How it works:

1. ›buffer is a single StringBuffer shared by two threads.
2. ›Both threads run appendTask, each calling append("x") 1000 times.
3. ›Because every StringBuffer method is synchronized, only one thread can execute append() at a time — the other waits its turn.
4. ›This guarantees no characters are lost or overwritten, so the final length is always exactly 2000, no matter how the threads interleave.

Best Practices

Use StringBuilder by default — switch to StringBuffer only when you confirm shared multi-thread access. The synchronisation overhead of StringBuffer is unnecessary in single-threaded code. Local variables in a method are never shared between threads. Instance fields accessed from multiple threads are the primary case for StringBuffer.

Consider synchronized StringBuilder or ReentrantLock as alternatives to StringBuffer. If you need fine-grained control — locking only specific sections, not every method call — wrapping StringBuilder in explicit synchronized blocks gives you more control than StringBuffer's method-level synchronisation. For complex multi-threaded string building, java.util.concurrent tools often offer better designs.

Always call toString() once at the end. Every toString() call creates a new String from the buffer content. Calling it inside a loop or multiple times in one build sequence creates unnecessary intermediate objects. Build completely, then convert once.

Prefer String.join() or streams for assembling known collections. For building comma-separated lists or joining items with a delimiter from a known collection, String.join(", ", list) is cleaner than a StringBuffer loop. Use StringBuffer when the building is iterative, conditional, or sequential — not for simple joins.

Common Mistakes

Mistake 1 — Using StringBuffer When StringBuilder Is Sufficient

Mistake 2 — Assuming StringBuffer Makes the Entire Operation Atomic

Each individual method call is synchronised. A sequence of calls — length() followed by insert() — is not atomic unless you add external synchronisation around the sequence.

Mistake 3 — Calling toString() Inside a Loop

Mistake 4 — Using StringBuffer for String Constants

Interview Questions

Q1. What is StringBuffer in Java and how is it different from StringBuilder?

StringBuffer is a thread-safe, mutable sequence of characters introduced in Java 1.0. Every method in StringBuffer — append(), insert(), delete(), replace(), reverse() — is declared synchronized, meaning only one thread can execute any of these methods on the same object at a time. StringBuilder, introduced in Java 1.5, has identical functionality but without synchronisation. The practical guideline: use StringBuilder for single-threaded string building (most cases) and StringBuffer when the same buffer object is shared and modified by multiple threads simultaneously.

Q2. Why was StringBuilder introduced when StringBuffer already existed?

When Java 1.0 introduced StringBuffer, thread safety was built in by default. As Java applications grew more complex, developers recognised that the vast majority of string building happens within a single thread — local variables in a method, response builders in a service layer, query constructors. These never need synchronisation. StringBuffer's mandatory locking on every method call was an unnecessary performance overhead for these single-threaded cases. Java 1.5 introduced StringBuilder as the unsynchronised alternative, letting developers choose the right tool: StringBuilder for performance in single-threaded code, StringBuffer where thread safety is genuinely needed.

Q3. Is StringBuffer completely thread-safe for all operations?

Each individual method call is thread-safe — the synchronized keyword ensures one thread at a time. However, a sequence of calls is not atomically thread-safe. If Thread A calls sb.length() and then sb.insert(length, value), Thread B could execute between those two calls and change the buffer's length. The result of Thread A's insert would then be at a position that no longer reflects the buffer state it read. For compound operations — read-then-modify sequences — callers must add explicit synchronisation around the entire sequence using synchronized (sb) { ... }.

Q4. When would you use StringBuffer over other alternatives in modern Java?

StringBuffer is appropriate when a single mutable String object is genuinely shared and concurrently modified by multiple threads — shared in-memory log buffers, concurrent message builders, shared response aggregators in multi-threaded systems. In most modern Java code, alternatives are preferred: StringBuilder for single-threaded work, String.join() or streams for assembling collections, and ConcurrentLinkedDeque or thread-local patterns for logging. Choose StringBuffer when the simplest correct solution for your specific multi-threaded mutable string need is direct method-level synchronisation.

Q5. What is the default capacity of StringBuffer and how does it grow?

The default capacity is 16 characters when created with new StringBuffer(). When the content would exceed the current capacity, StringBuffer allocates a new internal array of size Math.max(minimumNeeded, (currentCapacity + 1) * 2) — roughly doubling the capacity each time. For predictable workloads, setting an appropriate initial capacity with new StringBuffer(n) avoids these resize operations and the associated memory copy overhead.

Q6. What is the output of new StringBuffer("hello").reverse().toString()?

"olleh". reverse() reverses the entire character sequence of the buffer in place and returns this. toString() then creates a String from the reversed buffer. This is a common interview warm-up question — the important concept is that reverse() modifies the buffer itself and returns the same StringBuffer object, which is what enables the chaining with toString().

FAQs

Is StringBuffer still used in modern Java code?

Yes, but rarely compared to StringBuilder. Most string building in modern Java happens in single threads — method-local builders, response construction, query assembly — where StringBuilder is the correct choice. StringBuffer appears in legacy code from Java 1.0 era (before StringBuilder existed), and in genuinely multi-threaded scenarios where a single mutable buffer is shared. When reviewing or maintaining older codebases, you will encounter StringBuffer frequently.

Can you convert between StringBuilder and StringBuffer?

Yes. new StringBuffer(stringBuilder.toString()) creates a StringBuffer from a StringBuilder. new StringBuilder(stringBuffer.toString()) does the reverse. Both constructors accept CharSequence — the interface both implement — so you can also use new StringBuffer(charSequence) and new StringBuilder(charSequence) where charSequence is either type.

Does StringBuffer handle null appends?

Yes. sb.append(null) appends the four characters "null" to the buffer without throwing an exception. This applies to all append() overloads that accept reference types — passing null converts it to the string "null". If you do not want nulls appended as text, add an explicit null check: if (value != null) sb.append(value).

What does the capacity() method return versus length()?

length() returns the current number of characters stored in the buffer — the content size. capacity() returns the size of the internal character array — how much space is allocated. capacity() is always greater than or equal to length(). When length() == capacity(), the next append that increases the content will trigger a resize. ensureCapacity(n) can be called to pre-allocate capacity proactively.

Should you use StringBuffer in new code written today?

Only when you have a demonstrated multi-threaded need for a shared mutable string. For new single-threaded code, use StringBuilder. For assembling strings from collections, use String.join() or streams. For thread-safe string composition where ordering matters, consider synchronized blocks around a StringBuilder. StringBuffer remains valid but should be a deliberate choice based on specific threading requirements, not a default.

Summary

StringBuffer is the thread-safe mutable String type in Java. It solves the problem that String is immutable (creating new objects on every modification) and that StringBuilder is not safe for concurrent access. Every method is synchronised — one thread at a time — making it correct for concurrent writes from multiple threads.

The practical decision is straightforward: use StringBuilder by default for its performance advantage. Use StringBuffer when the same buffer object is demonstrably shared and modified by multiple threads simultaneously. Do not use String concatenation in loops for either case.

For interviews, the core answer is thread safety: StringBuffer synchronises every method, StringBuilder does not. Know that individual method calls are thread-safe but sequences of calls need external synchronisation. Know that StringBuilder was introduced in Java 1.5 specifically to provide an unsynchronised alternative for the common single-threaded case.

What to Read Next