beforeExecute 方法在哪定义、怎么生效
它不是配置项，而是 ThreadPoolExecutor 的一个受保护方法，必须通过继承或匿名内部类重写才能生效。直接在 Executors.newFixedThreadPool() 这类工厂方法返回的实例上调用或设置，完全无效——因为返回的是包装过的、不可扩展的实现。
- 必须自己 new 一个
ThreadPoolExecutor实例，或继承它写子类 - 重写
beforeExecute时，第一个参数是Thread，第二个是Runnable，注意别把参数顺序搞反 - 如果只是想记录日志或打点，不需要调用
super.beforeExecute()；但若父类有关键逻辑（比如某些定制化线程池），漏掉可能跳过必要初始化
监控场景下 beforeExecute 能做什么、不能做什么
它只在任务真正被线程取到、即将执行前触发，适合做轻量级上下文注入或瞬时状态快照。但它不是“任务入队时”触发，所以不能用来统计排队长度，也不能修改任务本身（Runnable 是只读引用）。
- ✅ 可以：记录当前线程名、任务提交时间戳、绑定 MDC 上下文、打点计数器（如
AtomicLong.incrementAndGet()） - ❌ 不可以：抛出异常中断执行（会直接导致线程终止）、阻塞等待（拖慢整个线程池吞吐）、修改
Runnable行为（它只是个接口引用） - ⚠️ 注意：如果在里面做耗时操作（比如远程 HTTP 请求、DB 查询），会严重拖慢线程复用效率，甚至引发拒绝——这不是监控该干的事
和 afterExecute、rejectedExecution 的配合边界
这三个钩子覆盖不同生命周期阶段，但容易误以为能“闭环”监控。实际上，beforeExecute 和 afterExecute 并不严格成对：如果任务抛异常且未被捕获，afterExecute 仍会执行，但传入的 Throwable 参数非 null；而被拒绝的任务根本不会进 beforeExecute。
- 任务是否进过
beforeExecute，是判断“是否真正开始执行”的唯一可靠依据 - 想统计“实际执行数”，只靠
beforeExecute就够；想统计“成功完成数”，得看afterExecute的Throwable是否为 null -
rejectedExecution是独立入口，需单独注册RejectedExecutionHandler，和前两个钩子无继承关系
动态更新监控指标时的线程安全陷阱
多个工作线程并发调用 beforeExecute，所有共享变量（比如计数器、Map 缓存）必须线程安全。用 ConcurrentHashMap 或 AtomicInteger 是基础，但更隐蔽的问题是“采集频率过高导致 GC 压力”。
立即学习“Java免费学习笔记（深入）”；
- 避免在钩子里 new 对象（如
new Date()、字符串拼接）——高频任务下会快速堆积短生命周期对象 - 如果要做耗时聚合（比如每秒汇总一次），应该把采样逻辑抽到独立调度线程，钩子只负责原子写入（如
counter.increment()） - 监控数据结构如果带锁（比如
synchronized方法），要确认锁粒度——全局锁会让所有工作线程在钩子里排队，等于给线程池加了隐形瓶颈
