Why Adding Thread Pools in Business Logic Often Hurts Performance

Hello, I am Su San.

Recently I saw a colleague complain that after three years of work he never used multithreading.

Even though we know the theory, we rarely write thread‑pool code directly in business logic, which can be risky.

My view is that you should understand thread pools thoroughly, but use them sparingly in business code.

Demo

We set up a quick Dubbo demo (consumer and provider) and added an HTTP interface to the consumer module to simulate a front‑end request.

The demo follows the official quick‑start steps.

After starting the demo, invoking the HTTP endpoint produces logs on both provider and consumer sides.

In this demo, the consumer code contains no explicit thread‑pool usage—only CRUD business logic.

However, the request is handled by a web container (Tomcat, Jetty, Netty, Undertow), which uses its own thread pool. The thread name http-nio-8081-exec-1 shows it runs inside Tomcat's pool.

Dumping the stack trace reveals multiple container threads, confirming the presence of a thread pool even though we did not write one.

Similarly, RPC frameworks like Dubbo also have thread pools—often several, such as IO pool and business pool, to achieve isolation.

When performance issues arise (e.g., low throughput), the first step is to tune the existing container or framework thread pools rather than inserting a new one in business logic.

Tomcat provides configurable executor parameters; Dubbo documents its threading model and performance‑tuning options.

Adding a custom thread pool in the middle can actually reduce throughput downstream, causing cascading failures.

In such cases, using a message queue for asynchronous processing is safer, or at least coordinate with downstream services to ensure they can handle increased load.

When is a thread pool appropriate? If a request needs to fetch data from multiple independent services, parallelizing those calls with a pool can improve latency.

// Example without custom pool
ArrayList initOrderInfoList = queryInitOrderInfoList();
for (OrderInfo orderInfo : initOrderInfoList) {
    try {
        String orderStatus = queryOrderStatus(orderInfo.getOrderId);
        updateOrderInfo(orderInfo.getOrderId, orderStatus);
    } catch (Exception e) {
        // handle
    }
}

Here the framework’s pool processes each request sequentially.

To speed up processing, you can introduce a custom pool inside the loop:

// Example with custom pool
for (OrderInfo orderInfo : initOrderInfoList) {
    executor.execute(() -> {
        try {
            String orderStatus = queryOrderStatus(orderInfo.getOrderId);
            updateOrderInfo(orderInfo.getOrderId, orderStatus);
        } catch (Exception e) {
            // handle
        }
    });
}

Choosing appropriate pool parameters is crucial, and the pool’s role is similar to the web container’s pool.

For HTTP or RPC calls, the existing framework pool should be fully utilized and tuned before adding another layer.

If the goal is merely to make the service appear faster without true parallelism, a message queue is often a better choice.