Java中不存在fillInStackTrace(boolean)方法，因为Throwable.fillInStackTrace()是无参、final、native的方法，不可重写或重载；动态控制堆栈需通过构造时跳过、覆写该方法为空、复用异常实例或避免抛异常等标准方式实现。
Java 中无法通过重写 fillInStackTrace(boolean) 来动态控制堆栈记录，因为该方法并不存在于 Throwable 类中 —— Throwable.fillInStackTrace() 是一个无参、final 的 native 方法，不可重写，也没有带 boolean 参数的重载版本。
为什么没有 fillInStackTrace(boolean)？
Throwable 类只定义了一个 public final Throwable fillInStackTrace() 方法，它由 JVM 本地实现，用于捕获当前线程的执行堆栈，并返回 this。该方法是 final 的，子类无法覆盖；也不存在布尔参数的变体。
Java 规范和 JDK 源码（如 OpenJDK）中均未提供任何可配置堆栈填充开关的公开 API。所谓 “动态控制是否记录堆栈” 并非通过重写该方法实现，而是有其他更实际、标准的方式。
真正可控的堆栈处理方式
若目标是减少异常创建开销（例如高频抛出的业务异常），或避免堆栈信息泄露，可通过以下合法手段实现“动态控制”：
立即学习“Java免费学习笔记（深入）”；
-
构造时跳过堆栈填充：调用
super(null)并在自定义异常构造器中不调用父类含参构造（即避开fillInStackTrace()的自动触发）。注意：这会丢失全部堆栈，需手动维护必要上下文（如日志 ID、错误码）。 -
覆写 fillInStackTrace() 返回 this（但不填充）：虽然不能改变签名，但可重写
fillInStackTrace()方法体为空操作并返回this。JVM 允许这样做（从 Java 7 起），但需确保调用链中不依赖堆栈（如printStackTrace()将输出空堆栈）。 - 使用 static factory + 预设异常实例：对无状态、可复用的异常（如 `EmptyListException`），预先创建单例对象，避免每次 new 时触发堆栈采集。适用于明确不需堆栈的场景。
- 运行时决定是否 new 异常：在 throw 前判断条件（如 debug 模式才 new 异常），或改用返回错误码/Optional/Result 类型，从根本上规避异常创建。
示例：空堆栈异常的正确写法
以下是一个跳过堆栈填充的自定义异常（兼容 JDK 8+）：
public class SkipStackTraceException extends RuntimeException {
public SkipStackTraceException(String message) {
super(message, null, false, false); // cause=null, enableSuppression=false, writableStackTrace=false
}
<pre class='brush:java;toolbar:false;'>@Override
public Throwable fillInStackTrace() {
return this; // 不调用 super，跳过 native 堆栈采集
}}
关键点：
- 构造时传入 false, false 禁用抑制异常和可写堆栈；
- fillInStackTrace() 重写后直接返回 this，不调用 super.fillInStackTrace()；
- 此异常的 getStackTrace() 将返回空数组，printStackTrace() 不输出调用路径。
注意事项与风险
跳过堆栈会显著削弱问题定位能力，仅建议用于：
• 高频、预期性失败（如协议解析失败）；
• 安全敏感场景（防止堆栈泄露内部路径）；
• 性能极端敏感且已确认堆栈无调试价值的模块。
切勿在开发/测试环境默认禁用；生产灰度期应配套监控指标（如异常类型分布、无堆栈异常占比），避免隐蔽故障。
