tpm模式误用于“每个变量”会引发资源崩溃：线程创建耗1mb栈空间、毫秒级开销且受系统限制；变量请求属轻量任务，应同步直调或用completablefuture等低开销机制替代。
为每个变量请求创建线程，本质上是 Thread-Per-Message（TPM）模式的误用场景——TPM 本意是为“每个消息/任务”分配线程，而非为“每个变量”；若真按字面理解对每个变量（如一个 String、int 或 DTO 实例）都 new Thread()，不仅逻辑错位，更会瞬间触发资源崩溃。下面从成本本质和可行改进两方面直接说明。
线程创建的真实开销远超直觉
Java 中每个线程默认占用约 1MB 栈空间（可通过 -Xss 调整，但下调有风险），且需内核分配调度实体、TLS（线程局部存储）、GC 线程注册等。这意味着：
- 启动 1000 个线程 ≈ 占用 1GB 堆外内存，不计堆内对象，已逼近常见容器内存上限；
- 线程创建/销毁耗时在毫秒级（尤其在 Linux 下涉及 clone() 系统调用），远高于对象实例化（纳秒级）；
- JVM 对线程总数有限制（受 ulimit -u 和系统资源制约），超出后 new Thread() 会直接抛 OutOfMemoryError: unable to create native thread。
“变量请求”应归类为轻量任务，而非线程边界
所谓“变量请求”，比如读取配置项、计算某个字段值、组装返回 DTO、校验入参等，本质是 CPU 短时操作或纯内存行为，完全不需要独立线程。错误地将它当作 TPM 的“Message”，暴露的是任务粒度识别偏差。正确做法是：
- 把真正耗时、可并行、有明确边界的行为定义为任务（例如：一次 HTTP 远程调用、一次文件写入、一次数据库批量更新）；
- 变量读写、简单转换、条件判断等应保留在当前调用线程中，避免无谓上下文切换；
- 若多个变量请求存在依赖或需统一超时控制，更适合封装为单个 Runnable/Callable 提交执行，而非拆成多个线程。
替代方案：按场景选合适抽象层
不是所有并发都需要线程。根据变量请求的实际性质，优先考虑更低开销的协作机制：
- 同步直调：90% 以上的变量访问（如 getUserName()、getConfigValue("timeout")）应直接调用，零成本；
- CompletableFuture 异步编排：当多个变量需异步加载（如从不同缓存/配置中心拉取），用 supplyAsync + thenCombine，复用公共线程池，避免线程爆炸；
- ThreadLocal + 预填充：对线程内高频访问的变量（如用户上下文、租户 ID），用 ThreadLocal 缓存，初始化由入口线程完成；
- Fiber（Loom 项目）：若确需极细粒度并发（如万级协程模拟变量级任务），可试用 JDK 21+ 的 VirtualThread，schedule(() -> {...}) 替代 new Thread()，内存开销降至 KB 级。
如果必须保留 TPM 思路，至少加三层防护
即便业务强要求“每个请求单位对应一个执行流”，也绝不能裸用 new Thread()。务必叠加资源约束：
- 用 ThreadPoolExecutor 代替无界线程创建，显式设置 corePoolSize、maxPoolSize 和 BlockingQueue（推荐 SynchronousQueue 或有界 LinkedBlockingQueue）；
- 配置 RejectedExecutionHandler，如 CallerRunsPolicy（让提交线程自己执行）或自定义日志告警，防止队列堆积雪崩；
- 配合 Micrometer 或 Prometheus 暴露 activeThreads、queueSize、rejectedTasks 等指标，实时监控线程池水位。
