高频热点代码中频繁抛出拒绝异常会显著放大JVM堆栈开销：每次触发fillInStackTrace()导致大量对象分配与CPU遍历，JIT无法优化该路径，且引发GC压力、栈局部性破坏及监控噪声。
高频热点代码中频繁触发拒绝异常，会显著放大 jvm 堆栈生成开销，这不是错觉，而是由 jvm 异常机制和运行时行为共同决定的。
拒绝异常本身就会强制生成完整堆栈跟踪
Java 中的异常（尤其是 受检异常和运行时异常）在构造时默认调用 fillInStackTrace() 方法。该方法会遍历当前线程的整个调用栈，逐帧采集类名、方法名、行号等信息，并构建一个完整的 StackTraceElement[] 数组。这个过程涉及大量对象分配（如数组、String、StackTraceElement 实例）和 CPU 遍历，开销远高于普通方法调用。
在热点路径上——比如每秒被调用数万次的限流校验点——若每次限流都抛出 RejectedExecutionException 或自定义拒绝异常，等于每秒主动触发数万次栈遍历与对象创建，直接冲击年轻代内存与 GC 压力。
异常堆栈无法被 JIT 有效优化
JIT 编译器对常规代码路径有深度优化能力（如内联、逃逸分析、栈上分配），但对异常路径基本不优化。JVM 规范要求异常必须保留精确的、可调试的堆栈信息，因此 fillInStackTrace() 被视为“不可省略的副作用”，JIT 不会跳过它，也不会将其标量替换或消除。
这意味着：即使你写的只是 throw new RejectedExc(); 这样一行代码，在高频场景下它始终是解释执行或低效编译的“重操作”，无法享受热点方法的性能红利。
拒绝逻辑不该依赖异常控制流
把“是否被拒绝”当作业务分支来处理，而不是错误条件，是更合理的做法：
- 用布尔返回值或枚举状态代替抛异常（例如
if (!canExecute()) return REJECTED;） - 将限流、熔断、降级等策略封装为无异常的快速判断逻辑
- 仅在真正需要告警、审计或调试时，才在日志中记录拒绝事件，而非每次抛异常
真实影响不止于 CPU 和内存
高频拒绝异常还会带来间接负担：
- GC 频率上升：大量短命的 StackTraceElement 对象涌入 Eden 区
- 线程栈局部性破坏：频繁异常打断正常调用链，影响 JIT 的热点识别与内联决策
- 监控噪声放大：异常指标失真，掩盖真正需要关注的故障类异常
