What are the beforeExecute(Thread, Runnable) and afterExecute(Runnable, Throwable) hooks on ThreadPoolExecutor, and how do you use them for instrumentation and per-task setup/teardown?

## The problem these hooks solve You often want to do something **around every task** a pool runs, time it, log it, attach tracing/diagnostic context, or set up and tear down resources, *without* modifying each task's code (you may not own it). ThreadPoolExecutor provides two **protected** methods designed exactly for this, both default to doing nothing: - **`protected void beforeExecute(Thread t, Runnable r)`** is called by the **worker thread** that is about to run `r`, immediately **before** `r.run()`. - **`protected void afterExecute(Runnable r, Throwable t)`** is called by the **same worker thread**, immediately **after** `r.run()` returns or throws. You use them by **subclassing** ThreadPoolExecutor and overriding them. ## Same-thread guarantee Both hooks run **on the worker thread** that executes the task, not on a separate monitoring thread. That is what makes **thread-local state** work: a value you set in `beforeExecute` is visible to the task and to `afterExecute`. It also means whatever you do in the hooks adds latency to that worker, so keep them cheap. ## Typical uses 1. **Timing / metrics**: stash a start nanotime (often in a ThreadLocal) in `beforeExecute`, read it in `afterExecute`, emit the duration to your metrics system. 2. **Context propagation**: set MDC (logging context), a trace/span id, or a security context in `beforeExecute`; **clear it** in `afterExecute`. 3. **Per-task setup/teardown**: open/close a resource, bind/unbind a transaction, etc. ## The reuse hazard (must clean up) Worker threads are **pooled and reused** across thousands of tasks. Anything you put in a `ThreadLocal` in `beforeExecute` **survives** onto the next task on that same thread unless you remove it. So `afterExecute` **must clear** the thread-local (ideally in a `finally`), otherwise task B inherits task A's MDC/trace id/security principal, a classic, hard-to-debug context-leak bug. ## The Throwable parameter (the gotcha) `afterExecute`'s `Throwable t` is the **uncaught exception** thrown by the task, *but only for tasks submitted as a plain `Runnable` via `execute()`*. When you use **`submit()`** (returning a `Future`), the executor wraps the work in a `FutureTask` that **catches the exception and stores it in the Future**, so the task does **not** throw out, and `t` arrives as **null**. To observe failures of `submit()`ed tasks inside `afterExecute`, you must detect that `r` is a `Future` that is done and call `get()` inside a try/catch to extract the cause: ```java if (t == null && r instanceof Future<?> f && f.isDone()) { try { f.get(); } catch (CancellationException ce) { t = ce; } catch (ExecutionException ee) { t = ee.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } ``` This idiom is shown in the JDK's own `ThreadPoolExecutor` javadoc. ## Rules and pitfalls - **Don't throw from the hooks.** An exception from `beforeExecute` aborts the task (it won't run) and propagates; from `afterExecute` it can disrupt the worker. Wrap risky logic and ensure teardown via `finally`. - **Keep them fast** — they run inline on the worker and add to per-task latency. - **`terminated()`** is a related lifecycle hook (called once when the pool has fully shut down) for pool-level teardown, distinct from these per-task hooks. - These hooks are the per-task complement to the **polling** accessors (activeCount, queue size, completedTaskCount): polling samples the pool from outside, the hooks instrument each task from inside. ## When to prefer them Use the hooks when you need **per-task** signals (latency histograms, per-task context) and cannot or don't want to wrap every task. Use polling accessors when you need **pool-level** vitals over time. They compose well together.