异常内部字段惰性分配指用时才初始化stackTrace等字段，避免未使用时的内存占用；90%以上未打印异常可节省2–5KB/个，10万并发省200MB+内存。
直接看核心：异常内部字段的惰性分配，本质是“用时才建、不用不占”，在超高并发场景下能显著压低物理内存峰值。它不靠压缩或回收，而是从源头减少实际分配量。
异常对象的内部字段通常不全在构造时初始化
Java 的 Throwable 类（所有异常的父类）里，stackTrace、suppressedExceptions、cause 等字段默认是延迟填充的。例如：
-
new RuntimeException("msg")构造后，stackTrace字段为null； - 直到第一次调用
printStackTrace()或getStackTrace()，才触发fillInStackTrace()，真正分配栈帧数组（可能数百个StackTraceElement对象）； -
suppressed列表仅在调用addSuppressed()时才新建ArrayList； -
cause若为null或指向自身，也不会额外创建新异常实例。
这意味着：90%以上被创建但未被打印/传播的异常，根本不占用栈跟踪内存。在高并发 RPC 场景中，大量“预期型异常”（如超时、重试失败）仅用于控制流判断，根本不会日志输出——此时每个异常节省 2–5 KB 内存，10 万并发线程就能省下 200 MB+ 物理内存。
最终块（final block）中的惰性分配需配合显式约束
所谓“最终块”，常指 try-catch-finally 或 lambda 尾部的异常处理逻辑。这里容易误写成“先构建再判断”，导致无谓分配：
// ❌ 错误：不管是否需要，都立即生成完整异常
if (timeout) {
throw new TimeoutException("req-" + reqId + " at " + System.nanoTime()); // stackTrace 已填充
}
// ✅ 正确：用 Supplier 延迟构造，仅在 throw 时触发
if (timeout) {
throw new TimeoutException() {{
initCause(null); // 避免 cause 复制开销
setStackTrace(new StackTraceElement[0]); // 手动设空栈，跳过 fillInStackTrace
}};
}更稳妥的做法是封装惰性异常工厂：
public class LazyException extends RuntimeException {
private final Supplier<String> messageSupplier;
private transient String cachedMessage;
public LazyException(Supplier<String> msg) {
this.messageSupplier = msg;
}
@Override
public String getMessage() {
if (cachedMessage == null) {
cachedMessage = messageSupplier.get();
}
return cachedMessage;
}
// 重写 fillInStackTrace 为空，彻底禁用栈收集（适用于已知无需诊断的场景）
@Override
public synchronized Throwable fillInStackTrace() {
return this; // 不调用 super，避免 native 方法分配
}
}三类关键优化点要同步落地
- 关闭非必要栈跟踪：JVM 启动参数加
-XX:-OmitStackTraceInFastThrow（默认已关闭，但某些旧版本需确认），并避免在循环中反复抛出同一异常类型触发 JVM 快速抛出优化（该优化会缓存栈，反而增内存）； - 日志框架配置过滤：Logback 或 Log4j2 中设置
throwableConverter为ShortenedThrowableConverter并限制深度，防止日志器强制触发getStackTrace()； - 监控异常构造频次：用字节码插桩（如 ByteBuddy）统计
new Throwable()调用，识别高频但零传播的异常点，针对性替换为状态码或 Optional。
物理内存降下来的不是数字，是真实可被其他线程复用的页帧。只要异常不真正“露面”，它的字段就只是代码里的一个引用占位符，连堆上对象头都不必落盘。
