Scheduling, Async & Caching

Don't rely on the default log-only handler. Register a custom AsyncUncaughtExceptionHandler (via AsyncConfigurer) that logs with context, emits metrics, and alerts or dead-letters. For work needing results or retries, return CompletableFuture and handle failures explicitly, and propagate trace/MDC context onto async threads.

CacheManager is a factory that returns named Cache instances (getCache(name), getCacheNames()). Cache is the store interface: get, put, evict, clear, and get(key, Callable) for atomic loading. The @Cacheable/@CacheEvict annotations are just declarative sugar over these two interfaces, so any provider that implements them plugs in unchanged.

The default TaskScheduler is single-threaded, so tasks serialize and a slow one delays others. Supply your own ThreadPoolTaskScheduler with adequate size, handle graceful shutdown, make tasks idempotent, and add cluster coordination since Spring scheduling isn't cluster-aware.

The HttpServletRequest and request-scoped beans live only for the request; once it completes the request/response may be recycled and its attributes cleared. Copying RequestContextHolder to a pool thread risks touching a dead request. Safer: extract the plain values you need before submitting, and pass them explicitly.

An uncaught exception from a fixedDelay or fixedRate task is logged but the schedule keeps running — future executions still fire. Only if you use a one-shot future would it stop. Make jobs resilient by catching and handling exceptions inside the method rather than letting them propagate.

PROXY (default) wraps beans in a proxy, so only external calls to public methods become async. ASPECTJ weaves the async advice into the bytecode, so self-invocation and non-public methods also work. ASPECTJ needs the AspectJ weaver and compile/load-time weaving setup, which is more complex.