fillinstacktrace()遍历线程栈帧提取类名、方法名、文件名、行号构造stacktraceelement[]，开销大；禁用需继承并重写该方法，且父构造器传false,false。
Exception构造时的fillInStackTrace()到底干了啥
Java中每次new Exception()，默认会触发fillInStackTrace()——它不是简单记个行号，而是遍历当前线程栈帧，提取每个方法的类名、方法名、文件名、行号，再构造成StackTraceElement[]数组。这个过程要读取JVM内部栈结构、做符号解析、分配数组和对象，开销远超普通对象创建。
- 在高频路径（如循环内校验失败）里new
Exception()，可能让吞吐量掉30%以上 -
Throwable(String message)和Throwable()都会调用fillInStackTrace()；只有显式禁用才能跳过 - JIT编译后也无法优化掉这一步——它是JVM级操作，不归Java字节码优化管辖
如何禁用异常堆栈填充
继承Exception或RuntimeException，重写fillInStackTrace()并直接返回this，是最轻量、最可控的方式。
class LightException extends RuntimeException {
public LightException() {
super(null, null, false, false); // 关键：禁用stackTrace和cause
}
@Override
public Throwable fillInStackTrace() {
return this;
}
}
- 必须传
false, false给父类构造器，否则super()内部仍会尝试填充 - 不能只重写
fillInStackTrace()却不关掉父类初始化逻辑——很多同学漏掉这步，结果白忙活 - 这种异常不能用于调试定位，只适合做控制流信号（比如Parser里的
ParseCancellationException）
Throwable(String, Throwable)的开销陷阱
看起来只是包装异常，但new Exception("msg", cause)会先调用fillInStackTrace()，再把原cause的栈信息复制一份（如果cause本身有栈）。两倍填充+一次数组拷贝，比无参构造还贵。
- 想保留原始异常上下文？直接throw
cause，别包一层 - 真要加message又不想填栈？用
new Exception(message, cause)+ 重写fillInStackTrace()，和上面一样处理 - 日志框架（如SLF4J）的
logger.error(msg, throwable)不会触发新异常构造，安全
性能差异在哪儿能测出来
局部变量捕获、GC压力、CPU缓存行争用——这些才是真实瓶颈点。单纯看“创建耗时”，微基准测试（JMH）容易误判，因为JIT可能把空fillInStackTrace()内联甚至消除。
立即学习“Java免费学习笔记（深入）”；
- 压测时关注
Thread.getState()是否频繁进入RUNNABLE态，以及java.lang.Thread.getStackTrace()调用频次 - 用JFR开启
jdk.JavaExceptionThrow事件，看每秒抛出数和平均栈深度 - 真正伤性能的从来不是“一次异常”，而是“每毫秒都new一个Exception当返回值”
异常传播本身没成本，成本全在创建那一刻。而那个时刻你是否真的需要堆栈，往往被忽略得最彻底。
