重写fillinstacktrace()可显著提升高频异常创建性能，因其跳过占耗时90%以上的栈帧遍历；通过返回this或设writablestacktrace=false实现，适用于无需诊断的业务异常，但禁用于需定位根因的系统异常。
Java中通过重写fillInStackTrace()能显著提升高频异常的创建性能，核心在于跳过昂贵的栈帧遍历操作——该操作默认占异常构造耗时的90%以上。关键不是避免抛出异常，而是让“不需诊断”的业务异常轻量化。
为什么重写fillInStackTrace有效
Throwable对象的堆栈信息并非在new时立即生成，而是在构造末尾或首次调用printStackTrace()前，由JVM调用fillInStackTrace()这个native方法主动采集。它会逐帧解析类名、方法名、行号并组装数组，时间随调用栈深度近似平方增长。重写为直接返回this，就彻底切断了这一链条。
两种主流实现方式
方式一：重写方法，返回this
- 继承
RuntimeException或Exception，覆盖fillInStackTrace()为return this; - 不调用
super.fillInStackTrace()，避免触发JVM原生逻辑 - 语义清晰，兼容所有JDK版本，推荐用于明确无需堆栈的场景
方式二：构造器参数控制，设writableStackTrace = false
- 调用父类四参数构造器：
super(message, null, false, false) - 第四个参数
writableStackTrace为false时，fillInStackTrace()内部直接跳过采集 - 更底层、更轻量，且无需重写方法，适合追求代码简洁的团队
适用与不适用的边界
适合用的场景
- 参数校验失败（如手机号格式错误）
- 限流/熔断拒绝（如QPS超限FastRejectException）
- 缓存穿透兜底（如空值强制返回SkipCacheException）
不能用的场景
- 系统级异常（
IOException、SQLException、NullPointerException） - 任何需要定位根因的错误，堆栈是唯一线索
- 被包装的异常链（如
new RuntimeException(e)），外层仍会触发自身栈采集
配套注意事项
启用后需同步调整日志和监控习惯：
-
e.printStackTrace()或log.error("", e)将输出空堆栈，必须手动补上下文字段（如当前method、key、timestamp） - 避免在
toString()或自定义日志处理器中意外调用getStackTrace()触发填充（虽不常见，但需验证） - IDE调试或某些APM工具（如SkyWalking）可能强制填充栈迹，需关闭相关增强配置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
