A teammate proposes using StringBuffer as a shared field so several worker threads can append log lines to it concurrently. Critique this design.

## The proposal and the hidden assumption The idea: one `StringBuffer` field, many threads each calling `append(line)`. The assumption is that because StringBuffer is 'thread-safe', this is correct and efficient. Both halves of that assumption are weak. ## What StringBuffer's thread safety actually buys **Synchronized** methods mean only one thread executes a given method on the object at a time, via an internal lock. So a single `append` call cannot interleave with another and corrupt the backing array — no torn writes, no lost characters within one call. That is *all* it guarantees. ## Problem 1: ordering is non-deterministic Thread safety per call is not the same as a meaningful global order. If thread A appends `"A: started\n"` and thread B appends `"B: started\n"`, the lock decides who goes first arbitrarily, run to run. For a log you usually want either timestamp ordering or at least per-line atomicity with a sensible interleave — neither is guaranteed. And if any writer does *two* appends to compose one line, those two can be split by another thread's append, interleaving partial lines. ## Problem 2: contention destroys parallelism The whole point of multiple workers is to do work in parallel. But every `append` now takes the *same* lock, so the threads serialize at exactly that point. Under load this single hot lock becomes a **contention bottleneck**: threads spend time waiting for the lock instead of working. You have added the cost of concurrency (context switches, lock handoffs) while removing its benefit at the shared point. ## Problem 3: safe reading is still unsolved When do you read the result? Calling `toString()` or `length()` while writers are mid-flight gives a snapshot of an in-progress buffer. Each call is synchronized, but you have no clean 'everyone is done' boundary unless you add one (e.g. a join/latch). So the design also needs external coordination it did not account for. ## Better designs 1. **Thread confinement (usually best).** Each worker owns a private `StringBuilder` (no synchronization, fast). When all finish, merge the pieces: ```java List<String> parts = workers.parallelStream() .map(w -> { StringBuilder local = new StringBuilder(); w.run(local); // appends only to its own builder return local.toString(); }) .toList(); String all = String.join("", parts); // one merge, no shared lock ``` No shared mutable state, full parallelism, deterministic merge order. 2. **A concurrent collection built for many producers.** e.g. each thread offers lines to a `ConcurrentLinkedQueue<String>` or a `BlockingQueue<String>` drained by a single consumer thread that writes them out. These structures are engineered for low-contention multi-producer access. 3. **A real logging framework.** For actual logging, libraries (Log4j2/SLF4J with async appenders) already solve ordering, batching, and back-pressure far better than a hand-rolled buffer. ## The principle Prefer **not sharing mutable state** over making shared mutable state thread-safe. StringBuffer's per-method lock is a low-level safety net, not a concurrency architecture; reaching for it signals that the real ownership/coordination question hasn't been answered. The senior-plus move is to redesign so the contention and ordering problems don't exist. ## Summary - Synchronized appends prevent corruption only, not ordering or sequence atomicity. - One shared lock serializes the workers — a contention bottleneck. - Reading the result still needs a completion boundary. - Prefer thread confinement (per-thread StringBuilder + merge) or a concurrent queue / logging framework.