参数之间的联动关系
核心线程数、最大线程数、队列容量三者共同决定任务在什么条件下被拒绝。队列用无界实现时，最大线程数这个参数实际上不会生效。
任务提交后的顺序是：核心线程未满直接创建，满了进队列，队列满了再创建到最大线程数，都满了才走拒绝策略。理解这个顺序是配参的前提。
处理器密集型任务按核心数配置，等待密集型可以适当放大，但具体倍数要看实际等待比例，不要照搬某个固定公式。
队列类型的影响
有界队列能形成背压，队列满时会触发拒绝或扩容到最大线程数，问题暴露得早。无界队列会把压力转化为内存增长和响应变慢，往往到内存溢出才发现。
队列长度要和可接受的等待时间匹配。平均处理耗时乘队列长度大致是尾部的等待时长，超过业务能容忍的范围就该拒绝而不是排队。
用延迟队列或优先级队列时注意，它们对容量和排序有额外要求，且不一定兼容所有线程池的扩容逻辑，需要单独验证。
拒绝策略的取舍
直接抛异常适合调用方有能力感知并降级的场景，能让上游立刻知道系统过载。
调用方线程执行会把压力回传给上游，起到限流作用，但要注意如果上游本身持有锁或关键资源，可能引发更严重的阻塞甚至死锁。
丢弃策略适合可容忍丢失的非关键任务，比如埋点、刷新类操作，但至少要记录被丢弃的数量，否则问题会被完全掩盖。
线程工厂与上下文
自定义线程工厂给线程起有意义的名字，排查线程转储时能直接区分是哪类业务。默认名字看不出用途。
需要传递用户上下文、链路标识时，放在线程局部变量里的值不会自动带到池线程。用装饰器在提交时捕获、执行时设置、结束后清理。
清理必须放在最终执行块里。池线程会被复用，残留的上下文会污染下一个任务，引发难以复现的串数据问题。
监控、动态调整与关闭
活跃线程数、队列长度、已完成任务数、拒绝次数是最应该采集的指标。队列长度持续增长就是容量不足的早期信号。
线程池的核心参数支持运行时调整时，可以在不改配置、不重启的前提下应对突发流量。调整要有记录，避免运行状态与配置文件长期不一致。设置合理的线程存活时间让空闲线程回收，核心线程默认不回收，低频任务的线程池长期挂着一批空闲线程也是浪费。
应用下线时要先停止接收新任务，再等待已提交任务完成，超时后强制中断。直接关闭会让正在执行的任务被中断，留下不一致的数据。
任务抛出的异常要显式捕获处理。通过执行接口提交时未捕获异常会交给默认处理器，通过提交接口时异常被包在返回值里，不取就看不到。
