Async Tasks, Thread Pools and Scheduling

This article solves one problem: some work should not make the user wait. Writing the order to the database is the main flow — the user must wait for it. Sending the SMS, the email, recalculating points — none of that affects "the order succeeded", so move it to the background. Spring gives you two annotations: @Async (someone else runs it, I do not wait) and @Scheduled (run it when the clock says so).

But neither annotation creates a thread. They only hand the task over. What decides whether you survive is the thing that catches it — the thread pool. That is why half of this article is about pools: it is not a detour, it is the point.

Six terms, one line each (used throughout):

• Thread: one line of execution. Your request normally runs on a Tomcat worker; going async means starting another line to do the work
• Thread pool: a set of threads built in advance and reused, like a rostered crew; tasks are jobs, whoever is free picks them up
• Core threads (corePoolSize): the permanent members of the pool — they stay even when idle
• Work queue (queueCapacity): when every permanent member is busy, new tasks wait here for a free hand
• Max threads (maxPoolSize): only once the queue is full does the pool hire temporary extra hands, up to this number
• Rejection policy (RejectedExecutionHandler): what to do when both crew and queue are full — throw, make the submitter run it, drop it, or drop the oldest

That comparison is the first life-or-death line of this article: if @Async gets no configured pool, you are in the left column (a fresh new Thread() per task, no bound, no reuse) — Section 3 shows the source evidence. The animation below is how the right column actually behaves internally, and note the part almost everyone remembers backwards — when core threads are busy, tasks are enqueued first, not answered with new threads:

After this article you should be able to answer three questions:

• A @Async method throws an exception — why does neither your log nor the HTTP response show it, and what must you add to catch it?
• Calling your own @Async method via this.sendSms() inside the same class — why does it run synchronously?
• You deploy three replicas — why did the daily reconciliation job run three times, and how do you make it run once?

Production reported that "the order endpoint sometimes takes 8 seconds to return". Investigation found that right after writing to the database, the main flow also called two external services synchronously — sending an SMS and sending an email. Each takes 1–3 seconds, and neither has anything to do with the outcome: the user only needs to know the order succeeded; an SMS two seconds late is fine.

This is exactly what async tasks solve: move "unrelated to the main result and slow" work onto a background thread and return immediately. Spring offers two annotations: @Async (run asynchronously) and @Scheduled (run on a schedule). They look trivial and hide many traps; this article covers both from usage through thread pools, context propagation and duplicate execution in a cluster.

First add @EnableAsync to a config class, then mark the method @Async:

The return type decides what the caller can get — the easiest part to misuse:

Two annotations switch async on, but the part that actually ships is a block of configuration. Do not copy somebody else's yml — tick the options you need, generate the file, and read why each line exists and what breaks without it:

@Async defaults to SimpleAsyncTaskExecutor, whose name is lovely and whose source is alarming: it calls new Thread() for every task, never reuses, and has no upper bound.

The consequences:

• No concurrency limit: ten thousand requests spawn ten thousand threads and blow up CPU and memory, possibly OOM.
• No reuse: every task is born and dies, wasting creation/destruction cost.
• No observability: no queue, no rejection policy, no metrics.

So production must define a custom pool. Use ThreadPoolTaskExecutor:

The pool's working order is: core threads → queue → max threads → rejection policy. Many people wrongly assume "more tasks means new threads up to max":

Those four rows are literally the script of the animation below; watch frames ②→③ in particular: what separates them is "the queue is full", not "the core threads are busy" — once that lands, every later discussion about capacity stops being confusing.

The four rejection policies:

The table above writes those four stages as four lines of prose, but "which one happens first" is exactly the thing prose cannot teach. Every cell below is clickable, and clicking it tells you what that stage does:

To feel how those three numbers fight each other, drag the queue capacity. The same @Async method has a completely different fate between 0 and 20000:

Like @Transactional, @Async depends on a proxy; if the call bypasses the proxy, the annotation vanishes:

Exceptions from void methods disappear silently by default; catch them explicitly:

That table has six rows and nobody memorises six rows. An annotation silently not working is something you only remember after it has bitten you once. So play a round: click a symptom on the left, then the cause you believe fits — miss one and it explains itself right there.

Recall Section 3's core fact: async tasks run on another thread. Yet many Spring / SLF4J / transaction contexts live in ThreadLocal, which does not travel automatically:

• Lost MDC traceId: the main thread's logs carry a traceId while the async thread's don't, breaking the trace. Fix with a TaskDecorator that copies the MDC when submitting:

Those are the conclusions, but "why it breaks" is not something conclusions teach. The lab below really runs it in your browser: the same handful of lines, read once on exec-3 and once on task-1.

Now spread the same story out as a debug session. The left pane is the code you are stepping through; the right pane refreshes the variables and the call stack. Press Step five times and watch the exact moment the thread name changes from exec-3 to task-1:

Those "through the proxy" and "handed to the pool" moves from steps ② and ③ deserve their own look — the lab below prints every move AsyncExecutionInterceptor makes:

The correct way to move context, drawn as one picture — all four moves matter, and the fourth (giving it back) is the one people skip:

When the app receives a shutdown signal, killing the process outright loses every async task still in the queue. Two settings together form the full chain:

Enable with @EnableScheduling, then annotate methods with @Scheduled. It has three triggers with very different semantics:

Timeline, with a 3-second task and a 2-second interval:

A cron expression has six fields: second minute hour day-of-month month day-of-week (Java's cron adds the "second" field that Linux's lacks):

initialDelay postpones the first run, handy for "wait until the app is fully ready":

@Scheduled uses a single-threaded TaskScheduler by default. That means all scheduled tasks share one thread, and whoever runs longest blocks the rest.

Fix it with a custom multi-threaded TaskScheduler:

The animation below plays this trap out frame by frame — pay attention to step ③: task B has reached its trigger time and nobody runs it. It did not fail; it is waiting for the one and only thread.

Dragging this number around makes what "1" costs obvious:

Everything above assumes one instance. Deploy several replicas and every replica fires the same scheduled task: a 5-minute report runs three times, duplicate bills go out. Three solutions:

A lightweight Redis SETNX de-dup implementation:

Sections 1-10 were reading material; this section is buttons. First the analogy that should stay with you throughout:

Section 4's table says core → queue → max → reject, but "enqueue before growing" is counter-intuitive enough that almost nobody gets it right on the first try. Press it out with a lab:

Once you have seen that curve, Section 3's conclusion gets concrete: the default per-task executor has no stage ② at all — it never queues, it just opens a thread per arrival, so every parameter described in Section 4 is decoration on it. The 200/200 position of the Section 12 sandbox — "threads pile up, downstream collapses, shutdown cannot drain" — is exactly that default behaviour scaled up.

These two dominate async incident reports, and both are silent:

A very common use of @Async is pairing it with event listeners: the main flow publishes, side effects move to listeners. Mind the default semantics of publishing — many beginners assume "publish and forget", yet by default listeners run one after another on the same thread:

And as soon as an async method writes to the database, you hit Section 6's boundary head-on: a transaction cannot be carried across. Act it out with propagation types:

Finally, back to the resource itself. Async protects the order endpoint's latency by leaning on bounded resources plus queuing; the same model has a more famous name on database connections — the connection pool. Watch it borrow and return, and "the queue" stops being abstract:

That is enough clicking on buttons — time to type. The console below talks to the same in-browser container, and every answer is computed by the Java kernel rather than read from a script. Start with beans, then run the lab commands one by one:

corePoolSize / maxPoolSize / queueCapacity bite each other, and a table gives you no feel for it. The sandbox exposes two switches (the third value is fixed at a queue of 500); every position shows throughput, backlog, rejections and shutdown loss together:

Then make the division of labour explicit: annotations only hand work over; the pool decides how it finishes — the left column below is the code you write, the right column is where every parameter, trap and tuning knob actually lands:

A warm-up on the order of stages that people remember backwards, straight from Section 4:

Now a combined question threading Sections 5, 6, 9 and 10:

Copy every snippet below straight into a search box — do not paraphrase or shorten it. Beginners stall in three places: tasks rejected, exceptions nowhere to be found, schedules drifting.

Section 6 promised that touching the request from async code always blows up, so let a real stack trace close the argument. This is the highest-frequency variant in production — read it, then pick the frame you think is guilty before looking at the answer:

Goal: with a small runnable Spring project, print the full chain "main flow returns instantly → the work happens on an async thread → the exception is visible only on that thread", and watch self-invocation degrade async into sync.

Step one, pom.xml (Java 17; swapping in Boot's spring-boot-starter works identically):

Step two, the pool plus the exception safety net (src/main/java/com/example/async/AsyncConfig.java) — one class supplies both hooks of AsyncConfigurer:

Step three, the async service (NotifyService.java). It is called from another bean, so those calls pass through the proxy:

Step four, the main flow (OrderService.java), containing both the good case and the counter-example: cross-bean call vs same-class self-invocation.

Step five, the launcher (Main.java):

Run main. Expected output — the thread names are the only evidence, match them line by line (the [notify] line may float slightly depending on scheduling):

Acceptance checklist: ① point at the thread-name difference between the [inline] and [notify] lines and say which call really went async; ② remove @EnableAsync and rerun — the container then creates no async proxy for these beans at all, so you will observe all three notification lines printing on main in strict sequence, while IllegalStateException no longer appears in AsyncConfig's error log but propagates up the call stack into main and kills the program (proof that "whether anyone catches the exception" depends on the proxy existing, not on how many handlers you wrote); ③ explain why "createOrder returned in 2ms" and the SMS still went out.

Change exactly one thing per run and the conclusion flips:

1. Set queueCapacity to Integer.MAX_VALUE and submit 5000 tasks in a loop. You will observe: active threads stays frozen at corePoolSize=2, maxPoolSize=4 never engages, everything piles up in the queue and memory climbs — Section 4's "an unbounded queue makes max useless", reproduced.
2. Restore queueCapacity=2 with corePoolSize=2, maxPoolSize=4, then submit 100 tasks concurrently. You will observe: TaskRejectedException ... did not accept task in the log with queued tasks = 2 and active threads = 4 both pinned — read those three numbers against the 8/16|AbortPolicy position of the Section 12 sandbox.
3. Swap the rejection handler for new ThreadPoolExecutor.CallerRunsPolicy(), changing nothing else. You will observe: rejections disappear but the main thread starts running tasks itself, and createOrder returned in jumps from 2ms to hundreds — "lossless" billed to the submitter, i.e. the backpressure the sandbox describes.
4. Add a @Scheduled(fixedRate = 1000) method that sleeps 4 seconds, plus a lightweight job printing every 2 seconds. You will observe: the lightweight job now prints only every ~4 seconds — the default scheduler owns a single thread. Register the ThreadPoolTaskScheduler(poolSize=4) from Section 9 and the two lines separate again.
5. Annotate failingAsync() with @Transactional, insert a row and then throw, while the main flow also runs in a transaction. You will observe: the two rollbacks ignore each other and the async write follows its own transaction's rules — empirical proof of Section 6's boundary; watch it alongside the REQUIRES_NEW case in the txprop lab.

Tip: after variants 2 and 3, return to the Section 12 sandbox, flip both switches to the matching positions, and confirm the readings agree.

Write an "async observability" component so any future project's pool state is visible at a glance and safe to shut down.

Requirements:

• A PoolMetricsReporter printing, every 5 seconds, for each ThreadPoolTaskExecutor: poolSize / activeCount / queueSize / queueRemainingCapacity / completedTaskCount / rejectCount
• Do not guess rejectCount: wrap a custom RejectedExecutionHandler that increments a counter and then delegates to the original policy (keep Abort / CallerRuns / DiscardOldest selectable)
• Allow per-pool parameters from configuration, and validate at startup: warn loudly if queueCapacity == Integer.MAX_VALUE or maxPoolSize <= corePoolSize (turn the Section 4 and Section 12 traps into a boot self-check)
• Install a TaskDecorator carrying the MDC, log the submission timestamp so queue wait is computable as "started at − submitted at"
• On graceful shutdown print "tasks remaining / seconds actually waited", and alert explicitly if awaitTerminationSeconds is exceeded

Acceptance checklist: ① under load, queueSize tracks traffic and rejectCount increments at the exact moment of a rejection; ② deliberately set the queue to Integer.MAX_VALUE and the startup WARN must appear; ③ shutdown logs show "N remaining, waited Xs"; ④ the async log's traceId matches the HTTP request that triggered it (MDC carried successfully); ⑤ not one business method changes.