Various Implementation Strategies for Delayed Tasks in Java: Quartz, DelayQueue, HashedWheelTimer, Redis, and RabbitMQ

In many backend systems a delayed task is required, such as automatically cancelling an unpaid order after 30 minutes or sending an SMS after 60 seconds.

Unlike scheduled tasks, delayed tasks have no fixed trigger time, no periodic execution, and usually handle a single job after an event occurs.

Solution 1: Database polling (Quartz)

Idea: A thread periodically scans the order table and cancels orders that have timed out. Implementation uses the org.quartz-scheduler library with a Maven dependency and a MyJob class that prints "Scanning database…" every 3 seconds.

Pros: Simple, works in small projects, supports clustering. Cons: High memory consumption, latency up to the scan interval, heavy DB load when order volume is large.

Solution 2: JDK DelayQueue

Idea: Use the unbounded blocking DelayQueue where each element implements Delayed . The queue releases an element only after its delay expires.

Key code includes the OrderDelay class implementing Delayed and a demo that enqueues five orders with a 3‑second delay, producing output every 3 seconds.

Pros: High efficiency, low trigger latency. Cons: Data loss on server restart, difficult cluster scaling, possible OOM when many delayed orders exist, higher code complexity.

Solution 3: Time‑wheel algorithm (HashedWheelTimer)

Idea: Netty's HashedWheelTimer mimics a clock; each tick moves a pointer. Tasks are placed in slots based on their delay.

Implementation adds the netty-all dependency and a HashedWheelTimerTest that schedules a MyTimerTask to run after 5 seconds, printing a message each second until execution.

Pros: Efficient, lower latency than DelayQueue , simpler code. Cons: Same restart‑loss issue and cluster scaling difficulty as the DelayQueue solution.

Solution 4: Redis sorted set (ZSET)

Idea: Store order IDs as members and their expiration timestamps as scores. A consumer periodically queries the ZSET for the smallest score and processes orders whose score is less than the current time.

Sample code shows adding orders with ZADD , querying with ZRANGE , and removing with ZREM . The approach suffers from duplicate consumption in high‑concurrency scenarios.

Pros: Simple API, fast look‑ups. Cons: Requires Redis maintenance, potential race conditions without additional locking.

Solution 5: Redis key‑space notifications

Idea: Enable notify-keyspace-events Ex in redis.conf so Redis publishes an event when a key expires. A subscriber listens on the __keyevent@0__:expired channel and processes the cancelled order.

Pros: Reliable persistence of messages, easy horizontal scaling, accurate timing. Cons: Needs extra Redis configuration and management.

Solution 6: RabbitMQ delayed queue

Idea: Use RabbitMQ's x-message-ttl and dead‑letter exchange to implement delayed messages. When the TTL expires, the message is routed to a consumer queue.

Pros: High efficiency, built‑in clustering, message persistence for reliability. Cons: Additional operational overhead of managing RabbitMQ and higher complexity.

Overall, the article provides a comparative analysis of each method, helping architects choose the most suitable delayed‑task solution based on performance, reliability, and operational considerations.