变量请求超时主因是核心线程数过小导致排队饥饿，而非下游慢或网络问题；其本质是轻量变量操作（租户ID、TraceId等）因线程池调度不足被迫入队，遇有界队列即触发拒绝或超时。
核心线程数设得太小，不是“线程不够用”，而是“变量请求在队列里饿到超时”。这类问题常被误判为下游慢或网络抖动，实际是线程池连变量初始化、ThreadLocal赋值、上下文传递这些轻量操作都排不上队。
为什么变量请求会卡在队列里？
变量相关操作（如获取当前租户ID、构造TraceId、加载配置快照）看似不耗CPU，但它们依赖线程池调度执行——尤其在异步链路中由CompletableFuture.supplyAsync或Spring的@Async触发时。若核心线程数远低于并发变量请求峰值，任务只能进队列等待。一旦队列有界（如LinkedBlockingQueue默认无界但生产环境常配100～500），新请求就会直接触发拒绝策略或超时。
- 典型表现：日志里反复出现“VariableContext.get() timeout=200ms”“TenantHolder.resolve() took 380ms”，但单测跑得飞快
- 关键线索：ThreadPool.getActiveCount()长期等于corePoolSize，而getQueue().size()持续攀升，且拒绝计数（rejectedExecutionCount）缓慢增长
- 容易被忽略的一点：变量读取本身不阻塞，但它的初始化逻辑（如首次调用时加载远程配置）可能同步阻塞，把一个线程“钉死”在初始化上
怎么确认是核心线程数不足，而不是其他瓶颈？
别只看线程数，要盯住“变量请求生命周期”。用两个简单命令交叉验证：
- 在应用启动后、流量进来前，执行jstack <pid> | grep -A5 "pool-.*-thread"，观察真实活跃线程名是否全被占满，且无空闲命名（如“pool-1-thread-1”到“pool-1-thread-5”全在RUNNABLE状态）
- 在超时发生时，用jstat -gc <pid>检查GC是否频繁——如果GC正常，但变量超时集中爆发，基本可排除内存问题，聚焦线程池
- 临时加一行监控代码：log.info("VarQ: {}, Active: {}, Idle: {}", pool.getQueue().size(), pool.getActiveCount(), pool.getPoolSize() - pool.getActiveCount()); 每秒打点，超时前10秒若Idle恒为0、Queue从0跳到200+，就是铁证
调大核心线程数不是万能解药
盲目调高corePoolSize可能掩盖设计缺陷，甚至引发新问题：
- 线程太多 → 上下文切换开销上升 → 反而拖慢变量获取速度
- ThreadLocal变量未清理 → 每个新增线程都携带旧请求的上下文残留，导致租户ID错乱或内存泄漏
- 真正该优化的是变量访问模式：高频读取的变量（如traceId、userId）应提前缓存在InheritableThreadLocal中，避免每次get()都走调度
更稳妥的修复路径
变量请求排队超时，本质是“轻任务被重任务挤占”。优先做减法，再考虑加法：
- 把变量初始化逻辑从“按需加载”改为“预热加载”：应用启动时主动调用一次TenantHolder.init()、TraceIdGenerator.warmUp()
- 区分变量类型：上下文类（tenant、user）走InheritableThreadLocal + 显式reset；配置类（feature flags）改用Caffeine本地缓存 + 异步刷新，彻底脱离线程池调度
- 给变量获取加熔断：超时后返回默认值或空上下文，而不是让整个请求失败；同时告警“变量服务降级”，比单纯调大线程数更能暴露真实瓶颈
