{"title":"StringBuffer","description":"","content":"`StringBuffer` is the thread-safe counterpart to the `StringBuilder` you used in the previous lesson. It exposes the same builder API, the same `append`, `insert`, `delete`, `reverse`, `setLength`, and `capacity` you already know, but every mutating method is marked `synchronized`. That one keyword is the entire reason `StringBuffer` exists. This lesson focuses on what that synchronization buys you, what it costs, and when to use `StringBuffer` instead of the faster `StringBuilder`.\n\n---\n\n# A Brief History\n\n`StringBuffer` shipped with Java 1.0 in 1996. At the time, it was the only mutable string class in the JDK, so the language designers made it thread-safe by default. Every public method that changes the internal buffer is `synchronized`, which guarantees correct behavior even when multiple threads share the same instance.\n\nThat safety cost performance for the most common case, which is a single thread building a string inside one method. To fix that, Java 5 (2004) added `StringBuilder`. It has the same API but drops the `synchronized` keyword. Both classes extend the package-private `AbstractStringBuilder`, which holds the shared implementation. `StringBuilder` is `AbstractStringBuilder` with a thin public wrapper, and `StringBuffer` is the same wrapper with synchronization added on top.\n\nThe practical result is that almost all modern Java code uses `StringBuilder`. `StringBuffer` is left over for the rare cases where the same builder is shared across threads, and for legacy code that has used it since before Java 5.\n\n\n```mermaid\nflowchart LR\n Abs[AbstractStringBuilder
package-private
shared logic]:::cyan --> SB[StringBuilder
Java 5
not synchronized]:::orange\n Abs --> Buf[StringBuffer
Java 1.0
synchronized]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the relationship. Both public classes inherit the same buffer-management code, and the only meaningful difference is whether each public method takes a lock.\n\n---\n\n# API Parity with StringBuilder\n\nAnything you can do with `StringBuilder` you can also do with `StringBuffer`. The method names, parameter lists, return types, and observable behavior all match. The compiled signatures, however, carry the `synchronized` modifier.\n\n\n```java\npublic class BufferApi {\n public static void main(String[] args) {\n StringBuffer label = new StringBuffer();\n label.append(\"Order #\");\n label.append(1042);\n label.append(\" - \");\n label.append(\"Shipped\");\n label.insert(0, \"[LOG] \");\n System.out.println(label);\n System.out.println(\"Length: \" + label.length());\n }\n}\n```\n\n\nIf you swap `StringBuffer` for `StringBuilder` in that code, the output is identical. The chains, fluent style, and method behavior are the same. Here are the signatures the JDK actually publishes for the most common mutating methods:\n\n\n```java\npublic synchronized StringBuffer append(String str)\npublic synchronized StringBuffer append(int i)\npublic synchronized StringBuffer append(char c)\npublic synchronized StringBuffer insert(int offset, String str)\npublic synchronized StringBuffer delete(int start, int end)\npublic synchronized StringBuffer deleteCharAt(int index)\npublic synchronized StringBuffer reverse()\npublic synchronized StringBuffer replace(int start, int end, String str)\npublic synchronized void setLength(int newLength)\npublic synchronized int length()\npublic synchronized int capacity()\npublic synchronized String toString()\n```\n\n\nEven read-only methods like `length()`, `capacity()`, and `toString()` are synchronized. That's intentional. Reading state that another thread might be writing also needs a lock to see a consistent value.\n\nEvery call into a `StringBuffer` acquires its monitor and releases it before returning. For a single uncontended thread the JVM optimizes this, but the overhead is non-zero. A tight loop of millions of `append` calls on a `StringBuffer` is measurably slower than the same loop on a `StringBuilder`.\n\nWhat differs is what happens when more than one thread touches the same instance.\n\n---\n\n# What `synchronized` Actually Gives You\n\nEvery Java object has an intrinsic lock, sometimes called a monitor. When a thread enters a `synchronized` instance method, it must acquire that object's monitor. If another thread already holds it, the second thread waits. Only one thread can be inside any synchronized method on the same instance at a time.\n\nThat mutual exclusion solves two related problems for `StringBuffer`:\n\n1. **Atomicity of compound updates.** An `append` reads the current length, writes new characters at that offset, and updates the length. Without a lock, two threads could read the same length and overwrite each other's characters. With a lock, the read-write-update sequence runs as one indivisible unit.\n2. **Memory visibility.** A write done outside a lock isn't guaranteed to be visible to other threads. The Java Memory Model says that when one thread releases a monitor and another thread acquires it, the second thread sees everything the first one wrote before releasing. Synchronized methods give you that visibility automatically.\n\nThe cost is also two-sided: the lock acquire and release work itself, plus the time threads spend blocked when they all want the same lock. In `StringBuffer`'s case, every public mutating method is synchronized on `this`, so the entire object is one big lock. There's no fine-grained locking inside.\n\n\n```mermaid\nflowchart LR\n T1[Thread 1
orderHandler]:::cyan --> Lock{StringBuffer
monitor}:::orange\n T2[Thread 2
shippingHandler]:::teal --> Lock\n Lock -- holds lock --> Inside[Inside append
writing characters]:::green\n Lock -- waits --> Queue[Blocked thread
waiting for monitor]:::red\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram shows two threads racing for the same buffer. Only one of them runs inside `append` at a time. The other one parks until the monitor is free. The order in which they win the race isn't fixed, but the resulting string is always well-formed.\n\n---\n\n# A Concurrent E-Commerce Example\n\nConsider an e-commerce service where two background threads write to a shared shipping audit log. One thread records order events, the other records shipping events, and both append to the same log buffer.\n\nThe version that uses `StringBuffer`:\n\n\n```java\npublic class ShippingLogSafe {\n public static void main(String[] args) throws InterruptedException {\n StringBuffer auditLog = new StringBuffer();\n\n Runnable orderEvents = () -> {\n for (int i = 1; i <= 5; i++) {\n auditLog.append(\"[ORDER #\").append(i).append(\" placed]\\n\");\n }\n };\n\n Runnable shippingEvents = () -> {\n for (int i = 1; i <= 5; i++) {\n auditLog.append(\"[ORDER #\").append(i).append(\" shipped]\\n\");\n }\n };\n\n Thread t1 = new Thread(orderEvents);\n Thread t2 = new Thread(shippingEvents);\n\n t1.start();\n t2.start();\n t1.join();\n t2.join();\n\n System.out.println(auditLog);\n System.out.println(\"Total characters: \" + auditLog.length());\n }\n}\n```\n\n\n**Output (one possible run):**\n\n\n```shell\n[ORDER #1 placed]\n[ORDER #1 shipped]\n[ORDER #2 placed]\n[ORDER #2 shipped]\n[ORDER #3 placed]\n[ORDER #3 shipped]\n[ORDER #4 placed]\n[ORDER #4 shipped]\n[ORDER #5 placed]\n[ORDER #5 shipped]\nTotal characters: 200\n```\n\n\nThe exact interleaving of order events and shipping events varies from run to run. What's guaranteed is that every individual `append` completes before any other `append` can start, so no two log entries collide. The total length is always correct, and every entry is intact.\n\nEach `auditLog.append(\"[ORDER #\")` call acquires the lock, writes its characters, and releases the lock. Then `.append(i)` does the same, then `.append(\" placed]\\n\")` does the same. The three appends inside one log line are three separate critical sections. The lock is released between them, so another thread can slip in and write its own entry between two appends of the first thread.\n\nThe order of log entries isn't what you might want for an audit log. Synchronization makes the buffer consistent, not the events well-ordered. If you need atomic multi-step entries, wrap the three appends in your own synchronized block:\n\n\n```java\npublic class ShippingLogAtomic {\n public static void main(String[] args) throws InterruptedException {\n StringBuffer auditLog = new StringBuffer();\n\n Runnable orderEvents = () -> {\n for (int i = 1; i <= 3; i++) {\n synchronized (auditLog) {\n auditLog.append(\"[ORDER #\").append(i).append(\" placed]\\n\");\n }\n }\n };\n\n Runnable shippingEvents = () -> {\n for (int i = 1; i <= 3; i++) {\n synchronized (auditLog) {\n auditLog.append(\"[ORDER #\").append(i).append(\" shipped]\\n\");\n }\n }\n };\n\n Thread t1 = new Thread(orderEvents);\n Thread t2 = new Thread(shippingEvents);\n\n t1.start();\n t2.start();\n t1.join();\n t2.join();\n\n System.out.println(auditLog);\n }\n}\n```\n\n\n**Output (one possible run):**\n\n\n```shell\n[ORDER #1 placed]\n[ORDER #1 shipped]\n[ORDER #2 placed]\n[ORDER #2 shipped]\n[ORDER #3 placed]\n[ORDER #3 shipped]\n```\n\n\nNow the three calls inside each iteration run as one critical section. The whole log line appears intact before the other thread gets a turn. The intrinsic lock on `StringBuffer` is reentrant, so the inner synchronized calls inside `append` don't deadlock when wrapped in an outer `synchronized (auditLog)` block.\n\nWrapping calls in your own `synchronized` block adds work, but it's the same lock the buffer already uses, so there's no extra contention. The blocked time grows with how long each critical section runs, so keep the work inside the lock small.\n\n---\n\n# What Goes Wrong with StringBuilder\n\nIf you take the first example and swap `StringBuffer` for `StringBuilder`, the program will still compile and usually print something that looks plausible. The data race is silent most of the time and breaks in unpredictable ways under load.\n\n**What's wrong with this code?**\n\n\n```java\npublic class ShippingLogBroken {\n public static void main(String[] args) throws InterruptedException {\n StringBuilder auditLog = new StringBuilder();\n\n Runnable writer = () -> {\n for (int i = 1; i <= 10_000; i++) {\n auditLog.append(\"X\");\n }\n };\n\n Thread t1 = new Thread(writer);\n Thread t2 = new Thread(writer);\n\n t1.start();\n t2.start();\n t1.join();\n t2.join();\n\n System.out.println(\"Expected length: 20000\");\n System.out.println(\"Actual length: \" + auditLog.length());\n }\n}\n```\n\n\nEach thread tries to append `10_000` characters, so the final length should always be `20_000`. With `StringBuilder` there's no lock around the internal length field or the character array. Two threads can read the same length, write to the same slot, and then both bump the length, so one of the writes is lost. A typical run prints something like this:\n\n\n```shell\nExpected length: 20000\nActual length: 17643\n```\n\n\nWorse outcomes are possible. If one thread sees a length that has already been incremented but a slot that hasn't been written, `toString()` can produce a string with stray null characters. Under the right timing, `StringBuilder` can throw `ArrayIndexOutOfBoundsException` from inside `append` because the internal grow logic ran twice with a stale length.\n\n**Fix:**\n\nSwitch to `StringBuffer`, or keep `StringBuilder` and add external synchronization. Both are valid. The choice depends on whether every caller goes through the same code path:\n\n\n```java\npublic class ShippingLogFixed {\n public static void main(String[] args) throws InterruptedException {\n StringBuffer auditLog = new StringBuffer();\n\n Runnable writer = () -> {\n for (int i = 1; i <= 10_000; i++) {\n auditLog.append(\"X\");\n }\n };\n\n Thread t1 = new Thread(writer);\n Thread t2 = new Thread(writer);\n\n t1.start();\n t2.start();\n t1.join();\n t2.join();\n\n System.out.println(\"Expected length: 20000\");\n System.out.println(\"Actual length: \" + auditLog.length());\n }\n}\n```\n\n\nThe length is now correct every run, because each `append` is a full critical section.\n\n---\n\n# The Performance Cost of Synchronization\n\nSynchronization isn't free, but it's not catastrophic for single-thread use either. The JVM can detect when a lock is only ever acquired by one thread and apply a series of optimizations. Older HotSpot versions used \"biased locking\" (deprecated in Java 15 and removed in Java 18) which made the first thread's acquire nearly as cheap as a non-synchronized call. Even on modern JVMs, a single-thread uncontended `synchronized` method costs on the order of a few nanoseconds per call, far less than the cost of growing the internal buffer.\n\nThe cost gets real in two situations:\n\n1. **Inside a tight loop on a hot path.** If your code does millions of `append` calls per second on the same buffer from one thread, the per-call overhead adds up. Microbenchmarks routinely show `StringBuilder` running about 10 to 30 percent faster than `StringBuffer` for single-thread workloads.\n2. **Under heavy contention.** When several threads compete for the same lock, the loser threads block and the OS may park them. A heavily contended `StringBuffer` can become a serialization point for the whole system.\n\nThere's another cost. The JVM uses an optimization called escape analysis to put short-lived objects on the stack instead of the heap. A `StringBuilder` declared and used inside one method is a clear escape-analysis candidate. A `StringBuffer` is harder to optimize this way because its synchronized methods make the JIT compiler more conservative about transforming the code.\n\nA quick microbenchmark to see the difference on your own machine:\n\n\n```java\npublic class BuilderVsBuffer {\n public static void main(String[] args) {\n int iterations = 5_000_000;\n\n long start1 = System.nanoTime();\n StringBuilder builder = new StringBuilder();\n for (int i = 0; i < iterations; i++) {\n builder.append(\"x\");\n }\n long builderTime = System.nanoTime() - start1;\n\n long start2 = System.nanoTime();\n StringBuffer buffer = new StringBuffer();\n for (int i = 0; i < iterations; i++) {\n buffer.append(\"x\");\n }\n long bufferTime = System.nanoTime() - start2;\n\n System.out.println(\"StringBuilder: \" + builderTime / 1_000_000 + \" ms\");\n System.out.println(\"StringBuffer: \" + bufferTime / 1_000_000 + \" ms\");\n }\n}\n```\n\n\n**Output (sample run on a recent JVM):**\n\n\n```shell\nStringBuilder: 38 ms\nStringBuffer: 52 ms\n```\n\n\nNumbers vary by JVM version, hardware, and warmup, but `StringBuilder` is consistently faster on a single thread. For a one-off log entry, the difference is invisible. For a function that runs ten thousand times per second on a server, the gap matters.\n\nSynchronized methods inhibit some JIT optimizations, including stack allocation and method inlining across the lock boundary. If profiling points at a single-thread builder being a hotspot, switching from `StringBuffer` to `StringBuilder` is one of the first changes to try.\n\n---\n\n# When to Use Which\n\nA short decision table covers most cases:\n\n\n| Situation | Recommended choice |\n| --------- | ------------------ |\n| Local variable inside a method, never escapes | `StringBuilder` |\n| Field of a class used by one thread only | `StringBuilder` |\n| Field of a class with concurrent writers from multiple threads | `StringBuffer`, or refactor to remove the sharing |\n| Field shared across threads but only one writer | `StringBuilder` with safe publication, or `StringBuffer` as a defensive default |\n| Building strings inside a `synchronized` block you already hold | `StringBuilder` (the outer lock already protects it) |\n| Modernizing legacy code that uses `StringBuffer` everywhere | Leave it alone unless profiling flags it |\n\n\nDefault to `StringBuilder`. Use `StringBuffer` only when the buffer truly has to be shared. In practice, sharing a mutable string builder across threads is often a sign that the design needs rethinking. Two cleaner alternatives:\n\n1. **Per-thread builders, joined at the end.** Each thread builds its own `StringBuilder` locally and submits the finished string to a shared `ConcurrentLinkedQueue`. A coordinator thread joins them when all workers finish. This avoids contention entirely.\n2. **Thread-local builders.** A `ThreadLocal` gives each thread a private builder it reuses across calls. The builders are never shared, so no synchronization is needed.\n\nBoth approaches usually scale better than a single `StringBuffer` under heavy load, because there's no shared lock to fight over. `StringBuffer` is the simple, correct fallback when there's no time to redesign and the safety is needed today.\n\n---\n\n# Common Pitfalls\n\nA few traps come up enough in real code to call out.\n\n**Trap 1: A synchronized buffer isn't a synchronized algorithm.**\n\n\n```java\npublic class CompoundOp {\n public static void main(String[] args) {\n StringBuffer cartLabel = new StringBuffer(\"cart-\");\n // Two threads doing this can interleave the two appends,\n // even though each append is atomic on its own.\n cartLabel.append(System.currentTimeMillis()).append(\"-end\");\n System.out.println(cartLabel);\n }\n}\n```\n\n\nEach `append` is atomic, but the chain of two appends isn't. If multiple threads run this code, the timestamp and `-end` suffix from different threads can interleave. Wrap the whole compound operation in `synchronized (cartLabel) { ... }` if you need it to run as one unit.\n\n**Trap 2: `toString()` returns a snapshot.**\n\nCalling `toString()` is synchronized, so it sees a consistent value at that moment. It returns a new `String` object. Any further `append` to the buffer doesn't affect the returned string. This is the desired behavior, though it can be surprising if the result is expected to \"live update\".\n\n**Trap 3: Mixing `StringBuilder` and `StringBuffer` in the same hot path.**\n\nA common cleanup mistake is leaving a few `StringBuffer` references in code that has been mostly converted to `StringBuilder`. The remaining `StringBuffer` calls pay synchronization cost without buying any safety, because the surrounding code already runs in a single thread. Decide on one and stick with it for a given path.\n\n**Trap 4: Treating `StringBuffer` as a general thread-safe collection.**\n\n`StringBuffer` is only safe for the operations it exposes. If you read its length, then call `setLength`, then `append`, the sequence as a whole isn't atomic. Other threads can change the state between your calls. For multi-step logic, you still need your own lock around the whole sequence.\n\nA chain of three synchronized calls acquires and releases the same lock three times. If you already hold the lock externally, the inner acquires are cheap because the lock is reentrant, but they still aren't free.","pageType":"java"}

StringBuffer

Get Premium