fillInStackTrace()是关键入口，因异常堆栈不在实例化时生成，而由该protected native方法在构造末尾或首次调用printStackTrace前主动填充；重写为空实现可跳过栈帧遍历，创建无堆栈异常以降CPU和内存开销。
在高性能场景中，标准异常对象因自动捕获完整堆栈跟踪而带来显著开销（尤其是频繁抛出时）。fillInStackTrace() 可被重写为空实现，从而跳过堆栈收集，生成“无堆栈异常”，大幅降低 CPU 和内存压力。
为什么 fillInStackTrace() 是关键入口
Java 异常的堆栈信息并非在 new Exception() 时立即生成，而是在构造器末尾或首次调用 printStackTrace() 等方法前，由 Throwable.fillInStackTrace() 主动填充。该方法是 protected native 方法，默认由 JVM 实现。覆盖它即可切断堆栈采集链。
自定义轻量级异常类（推荐方式）
继承 RuntimeException 或 Exception，重写 fillInStackTrace() 为直接返回 this：
- 不调用
super.fillInStackTrace()，避免 JVM 执行昂贵的栈帧遍历 - 保持异常类型语义清晰（如
ValidationSkipException、FastTimeoutException） - 可选择性保留消息和 cause，但不记录堆栈（
getStackTrace()将返回空数组）
示例：
立即学习“Java免费学习笔记（深入）”；
public class FastRejectException extends RuntimeException {public FastRejectException(String message) {
super(message);
}
@Override
public synchronized Throwable fillInStackTrace() {
return this;
}
}
使用注意事项与边界条件
该优化仅适用于明确不需要诊断堆栈的场景（如高频业务拒绝、状态校验失败、缓存穿透熔断等）：
- 日志中
e.printStackTrace()或log.error("", e)不会输出堆栈，需手动补上下文（如当前 method、key、timestamp） - 不能用于需要排查根因的错误（如 NPE、IO 异常），否则会丢失关键定位信息
- 若异常被包装（如
new RuntimeException(e)），外层异常仍会触发自己的fillInStackTrace()，需确保所有中间层也做同样处理或避免包装 - JDK 9+ 中
Throwable新增setStackTrace(StackTraceElement[])，但主动设为空数组仍无法阻止原始填充逻辑；重写fillInStackTrace()是唯一可靠方式
性能对比与实测建议
在吞吐量敏感服务中（如网关、实时风控），相同逻辑下使用无堆栈异常可使异常创建耗时从 1–3 μs 降至 50–100 ns，GC 压力显著下降：
- 压测时关注
Throwable.<init></init>的 CPU 火焰图占比，若偏高即为优化点 - 禁用
-XX:+PrintGCDetails下观察 young GC 频率是否因异常对象减少而下降 - 建议配合异常计数埋点（如 Micrometer Counter），区分“可忽略异常”与“需告警异常”，避免误杀问题
