Comparing Java ExecutorService Thread Pool and Message Queues for Asynchronous Processing

It asks what the differences are between two approaches—using a thread‑pool ExecutorService and using a message queue—and which scenarios each is suitable for.

Using a thread‑pool ExecutorService: The author notes that ExecutorService internally uses a queue (e.g., LinkedBlockingQueue), so from a design perspective it is similar to a message‑queue middleware. However, the application server acts as both producer and consumer, making this approach appropriate for non‑distributed, single‑server architectures.

Using a message queue: Middleware such as ActiveMQ, RabbitMQ, Kafka, or Redis is deployed on separate machines, incurring network overhead. For decoupling purposes, the latter is more reasonable because the application server typically has limited memory and cannot hold long queues. This fits distributed architectures.

1. Using JDK's asynchronous framework ExecutorService

threadPool.execute(new Runnable() {
    @Override
    public void run() {
        // Asynchronous, time‑consuming logic such as database operations
        userService.setDefaultAddressId(user.getUserId(), bookingForm.getAddressId());
    }
});

2. Sending a message to a queue (simple Redis List implementation) and consuming it in a background thread

// Produce message
redisTemplate.opsForList().leftPush(LOG_MQ_KEY, JsonUtil.beanToJson(httpRequestLog));

// Background thread consumes message
String popValue = redisTemplate.opsForList().rightPopAndLeftPush(LOG_MQ_KEY, TEMP_LOG_MQ_KEY);

Message queues offer greater extensibility, support more scenarios, and provide automatic persistence. The author recommends exploring RabbitMQ, the AMQP protocol, and JMS. While Kafka excels in high‑throughput data‑statistics use cases, it does not guarantee 100% message delivery and is therefore less suitable for core business functions.

Thread pools differ in that their execution state is opaque; you cannot easily know consumption rates or implement features such as message rejection. The author uses a thread pool for simple event forwarding rather than heavy processing, e.g., after a user registration transaction ends, a RegisterUserEvent is sent via a thread pool, a RegisterUserListener picks it up, and the event is forwarded to RabbitMQ for downstream services like points, coupons, or cloud storage.

Java has many analogous comparisons, such as Ehcache vs Redis for caching, or Java concurrency utilities vs Redis locks.

Initially, the author suggests using ExecutorService but monitoring the queue size with a timer to detect blocking. When server load rises and the thread pool becomes a bottleneck, upgrading to middleware may be considered, though most sites rarely reach such load unless there are bugs.

Use ExecutorService unless the scenario involves cross‑service business (e.g., orders, payments) or requires business decoupling (e.g., logging where the upstream does not need to know the downstream success).

Introducing a message queue adds design complexity: handling network jitter, setting max queue length, timeout values, QoS, appropriate consumer count, channel cache size, and avoiding resource contention that could cause a whole MQ failure.

In short, avoid adding components unless necessary.