Sandeep Bhardwaj

Backend Engineer • SaaS Builder

Creating a Thread manually is easy.

Scaling a system built around raw thread creation is not.

That is the real reason the executor framework matters.

The problem is not that new Thread(...).start() is illegal or obsolete. The problem is that once a system handles real traffic, raw threads force application code to take on responsibilities it handles badly:

  • sizing
  • reuse
  • queuing
  • lifecycle
  • instrumentation
  • overload policy

This post is the bridge from low-level concurrency primitives into real concurrent service architecture.

Problem Statement

Suppose every incoming request or job creates its own thread.

That looks direct and appealing:

  • a task arrives
  • a thread runs it
  • done

But as concurrency rises, the system starts paying for that simplicity in all the wrong places:

  • memory per thread
  • thread scheduling overhead
  • context switching
  • startup and teardown cost
  • lack of global capacity control

The result is that thread creation becomes not just a coding style choice, but an operational scaling problem.

The Naive Pattern

This is the classic shape:

class ReportService {
    void generateAsync(String reportId) {
        Thread thread = new Thread(() -> generate(reportId));
        thread.start();
    }

    void generate(String reportId) {
        // expensive work
    }
}

This may be perfectly fine for:

  • one tool
  • one background action
  • one-off utility code

It becomes fragile when the task rate is no longer tiny and predictable.

The missing question is:

  • how many threads are we willing to create at once

If the answer is “however many requests arrive,” the design is already in trouble.

Why Raw Threads Fail Under Load

1. Threads consume real resources

A thread is not just a lightweight callback.

It carries:

  • stack memory
  • scheduler bookkeeping
  • CPU context-switch cost
  • lifecycle overhead

If thread count climbs too high, the system may spend more time scheduling and managing threads than doing useful work.

2. There is no built-in admission control

Raw thread creation usually means:

  • every task tries to become active immediately

That is the opposite of bounded concurrency.

If the system receives 20,000 tasks, raw thread design tends to create 20,000 pressure points instead of making an explicit choice about what to queue, reject, or delay.

3. Reuse is lost

Most application tasks are not long-lived enough to justify one brand new thread each.

If the system can reuse a worker thread for the next task, that is usually cheaper than constantly creating and tearing down threads.

4. Lifecycle becomes scattered

Who owns the threads? Who shuts them down? Who names them? Who tracks failures?

With raw threads, those answers often become inconsistent across the codebase.

Runnable Example

The following example is intentionally small, but it shows the design smell clearly.

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;

public class RawThreadCreationDemo {

    public static void main(String[] args) throws Exception {
        List<Thread> threads = new ArrayList<>();

        for (int i = 1; i <= 50; i++) {
            int taskId = i;
            Thread thread = new Thread(() -> doWork(taskId), "raw-task-" + taskId);
            threads.add(thread);
            thread.start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("Completed " + threads.size() + " raw-thread tasks");
    }

    static void doWork(int taskId) {
        try {
            TimeUnit.MILLISECONDS.sleep(200);
            System.out.println(Thread.currentThread().getName() + " handled task " + taskId);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Nothing here is “wrong” at 50 tasks. That is what makes this pattern deceptive.

The problem emerges when:

  • task count becomes unbounded
  • work blocks on I/O
  • multiple call sites all do the same thing independently

Then raw threads stop being a small implementation detail and become a distributed capacity leak.

Production-Style Failure Modes

Raw-thread systems commonly fail in these ways:

  • thread count spikes during bursts
  • memory rises because stacks and task objects accumulate
  • latency becomes unpredictable due to scheduling overhead
  • shutdown hangs because nobody owns all created threads cleanly
  • logs become unreadable because thread naming is inconsistent or absent

These failures are especially common in services that mix:

  • request-driven concurrency
  • background jobs
  • retries
  • slow network or disk operations

At that point, raw thread creation usually means the application has no central concurrency policy at all.

What Executors Fix

Executors separate two ideas that raw-thread code keeps coupled:

  • what work should run
  • how worker threads should be managed

That separation allows the runtime boundary to own:

  • thread reuse
  • queueing
  • bounded parallelism
  • shutdown
  • task submission
  • failure reporting through futures

This is why executors are not just convenience APIs. They are concurrency architecture tools.

When Raw Threads Are Still Fine

Raw threads are still acceptable when:

  • one or two long-lived threads are created intentionally
  • the thread represents a named application component
  • lifecycle is explicit and bounded

Examples:

  • a single dedicated monitoring thread
  • a tiny utility program
  • carefully controlled low-level infrastructure code

The smell is not “raw threads exist.” The smell is “raw threads are the default scaling model.”

Common Mistakes

Creating one thread per request

This is the classic anti-pattern.

Ignoring ownership

If no component owns thread lifecycle, shutdown and observability suffer immediately.

Assuming more threads always means more throughput

Past a certain point, more threads often mean more contention and more scheduler cost.

Recreating pools manually with lists of threads

Once you start building your own ad hoc worker management, you are usually rebuilding a worse executor.

Decision Guide

Use raw threads when:

  • there are very few of them
  • they are long-lived by design
  • ownership and shutdown are explicit

Move to executors when:

  • tasks arrive repeatedly
  • worker reuse matters
  • you need queueing or bounded concurrency
  • lifecycle and monitoring need one central control point

For backend systems, that usually means:

  • raw threads for rare dedicated infrastructure roles
  • executors for ordinary task execution

Key Takeaways

  • Raw thread creation does not scale because it pushes capacity, lifecycle, and reuse problems into application code.
  • The main failure modes are thread explosion, memory growth, poor overload behavior, and weak ownership.
  • Executors exist to centralize worker management and concurrency policy.
  • new Thread(...).start() is not wrong in isolation; it is wrong as a default system-wide execution model.

Next post: Executor Framework Overview in Java

Comments

You may also enjoy