秒级高频计算中应避免抛出异常以保障逃逸分析有效——因fillinstacktrace、可能被catch持有及栈帧恢复逻辑均使其强制堆分配；须改用状态码短路、预校验、冷路径兜底转换，并通过jvm日志与jfr验证优化效果。
在秒级高频计算逻辑中，避免使用自定义异常（Throwable）不是为了“释放”逃逸分析，而是为了不让它失效——因为抛出任何异常（包括 new RuntimeException()）都会直接破坏逃逸分析的判定前提，导致本可栈分配的对象被迫堆分配。
异常抛出会强制对象逃逸
只要方法中存在 throw new XxxException(...)，JVM 的逃逸分析就会保守地将该异常对象（及其构造过程中涉及的字符串、堆栈帧、填充字段等）全部判为“可能逃逸”。原因有三：
- 异常对象必须携带完整堆栈轨迹（
fillInStackTrace()），而该操作需动态生成并填充数组、字符串等堆对象； - 异常一旦抛出，就可能被上层
catch块捕获并长期持有（如记录日志、封装返回），JVM 无法静态证明其生命周期仅限于当前栈帧； - 即使你没显式
catch，JIT 编译器仍要为异常出口预留栈帧恢复逻辑，这会抑制标量替换和栈上分配等优化。
用状态码 + 短路逻辑替代异常流
在纯计算密集型路径（如风控评分、价格重算、向量相似度匹配）中，应把“失败”视为正常业务分支，而非异常事件：
- 用
int或enum表示结果状态（如VALID/INVALID_SKU/OVER_QUOTA），配合if短路退出； - 关键字段提前校验：比如先检查
price > 0 && qty > 0，不满足则直接返回错误码，避免走到需要构造异常对象的分支； - 把“异常构造”移出热路径：若必须记录错误上下文，改用静态工具类预分配好日志模板，只填入基本类型参数（如
log.warn("Price invalid: {}", price)），不拼接对象引用。
保留异常语义但剥离逃逸风险
若业务协议要求抛出异常（如 Dubbo 接口定义），可在冷路径兜底，热路径保持无异常：
- 核心计算方法（
compute(...)）严格返回Result<t></t>或Optional<t></t>，内部零throw； - 外层薄胶水方法（
computeWithException(...)）才做转换：result.orElseThrow(() -> new InvalidInputException("price=" + price))； - 确保该胶水方法不被 JIT 内联（加
@HotSpotIntrinsicCandidate注解或用-XX:CompileCommand=dontinline控制），避免污染热路径的逃逸分析结果。
验证是否真正绕开了异常逃逸
光靠代码逻辑不够，得看 JVM 实际行为：
- 启动参数加
-Xlog:gc+allocation=debug -XX:+PrintEscapeAnalysis，观察高频计算方法中是否还有allocated on heap日志； - 对比开启
-XX:+DoEscapeAnalysis前后，Eden 区每秒新分配对象数（Allocation Outside TLAB）是否下降 30% 以上； - 用 JFR 抓取
jdk.ObjectAllocationInNewTLAB事件，筛选出热方法，确认分配对象类型不含任何*Exception类。
