What Are the Pros and Cons of Multithreading?

Multithreading lets one program run several threads at the same time, which keeps a user interface responsive, uses every CPU core, and overlaps waiting on I/O with useful work. The costs are race conditions, deadlocks, bugs that appear only under load, about 1 MB of stack memory per thread, and a speedup that is capped by the part of the program that cannot run in parallel.

Multithreading is worth its cost when a program has independent work to do at the same time. It is not worth its cost for a short script or a program whose steps depend on each other in a strict sequence.

Advantages and disadvantages in one table

The advantages of multithreading

Responsiveness. A desktop or phone app keeps its screen thread free and runs network calls, file reads and long computations on other threads. The user can keep scrolling while a download runs. Without threads the screen freezes until the slow call returns.

Use of every core. A single thread runs on one core, so on an 8-core machine it leaves 7 cores idle. A CPU-bound job such as image processing or compression divides into 8 pieces and finishes in about one eighth of the time.

Overlapped I/O. A web server thread that waits 50 ms for a database does no work during that wait. With 200 threads, 199 other requests are served during it. This is the reason web servers such as Tomcat and ASP.NET use thread pools.

Cheap sharing. Threads in one process share the heap. A cache, a connection pool or a configuration object is loaded once and used by every thread. Processes would each need their own copy, or would copy data through pipes.

Advantages of multithreading in Java specifically. Java has built-in thread support, a complete java.util.concurrent library, and, from Java 21, virtual threads that let a server hold a million blocked threads cheaply. Concurrency questions in interviews are most often written in Java for this reason.

The disadvantages of multithreading

Race conditions. When two threads read and write the same variable without a lock, the result depends on which one runs first. A counter incremented by two threads 1,000 times each can end well below 2,000, because increments are lost when both threads read the same old value. Preventing this needs locks, atomic operations or immutable data, and every one of those is a place to make a mistake.

Deadlocks. Thread A holds lock 1 and waits for lock 2. Thread B holds lock 2 and waits for lock 1. Neither ever proceeds. Deadlocks are prevented by always taking locks in the same order, or by using timeouts, but a codebase with many locks makes that hard to guarantee.

Hard debugging and testing. A race may appear once in ten thousand runs, only on a machine with more cores, or only under production load. A debugger changes the timing and can hide the bug. Unit tests pass and the bug ships.

Memory and switching cost. Each thread reserves a stack, 1 MB by default in the JVM and on Windows. Ten thousand threads reserve about 10 GB of address space. Each switch between threads costs a few microseconds plus lost cache contents. Lock contention adds more: threads waiting for a lock use no CPU but deliver no work.

A limited speedup. Amdahl's law states that if a fraction p of a program can run in parallel, the maximum speedup on n cores is 1 / ((1 - p) + p / n). A program that is 90 percent parallel gains at most a factor of 4.7 on 8 cores and can never exceed 10, however many cores are added. The sequential 10 percent sets the ceiling.

When to use multithreading

Use threads when the program has CPU-bound work that divides into independent pieces, when it must stay responsive while doing slow work, or when it serves many clients that spend most of their time waiting. Prefer an event loop, such as Node.js or Python asyncio, when the program holds tens of thousands of mostly idle connections. Prefer separate processes when isolation matters more than sharing, or when the language cannot run threads in parallel, as Python cannot under its global interpreter lock.

Do not add threads to a short script, to code whose steps strictly depend on each other, or to a program that is already limited by a single database or network link. Threads add cost there and no speed.

Does multithreading improve performance?

It improves throughput when there is parallel work and idle cores. It improves latency when slow work can be moved off the thread the user waits on. It does not improve a program that is limited by one shared resource, and it can make one slower through lock contention and switching. Measure before and after with the real workload.