异常对象因携带超长message和完整堆栈导致内存暴涨，应裁剪message、清空堆栈、复用静态异常，并用结构化日志替代异常传上下文，配合监控与jvm参数兜底。
这个问题本质是“异常对象本身成了内存负担”——不是异常逻辑出错，而是异常实例携带了过量字符串数据，在高频创建时迅速吃光堆内存。
异常描述信息为何会撑爆堆？
Java中每个 Exception 实例（尤其是 RuntimeException 及其子类）默认持有完整堆栈跟踪（StackTraceElement[]）和一个 detailMessage 字符串。当这个 message 是超长文本（如 dump 了整个 HTTP 响应体、日志上下文、原始 JSON 或 Base64 编码内容），单个异常对象就可能占用几 MB 内存。若每秒抛出数百次，几秒内就能填满几百 MB 堆空间，且因频繁创建+未及时回收，GC 压力剧增，甚至触发 GC overhead limit exceeded。
从源头控制异常内容大小
不依赖“事后清理”，而是在构造异常时就做裁剪：
- 禁用冗余堆栈：用
new RuntimeException(message).setStackTrace(new StackTraceElement[0])清空堆栈（适用于已知调用链、仅需语义提示的场景）； - 截断 message：对原始描述做长度限制（如
message.substring(0, Math.min(512, message.length()))），并加标记（"...[truncated]"）； - 避免直接拼接大对象：不要写
new RuntimeException("Failed to process: " + hugeString)，改用占位符 + 日志系统异步记录详情； - 复用轻量异常：对固定错误类型，定义静态 final 异常实例（如
public static final RuntimeException TIMEOUT_EX = new RuntimeException("timeout")），避免每次 new。
用日志替代异常携带上下文
异常不是日志载体。高频业务异常（如参数校验失败、重试超时）应：
- 只抛出语义明确、无载荷的异常（如
IllegalArgumentException），message 控制在 100 字以内； - 将完整上下文通过 SLF4J MDC 或结构化日志（如
log.warn("request_failed", kv("uri", uri), kv("body_size", body.length))）输出到磁盘/日志服务； - 确保日志框架（Logback/Log4j2）配置了异步 Appender 和大小限流，避免日志本身反成瓶颈。
监控与兜底防护
即使代码规范，上线后仍需防御性保障：
- JVM 启动加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps，配合 MAT 快速确认是否为java.lang.Exception或子类实例堆积； - 用
jstat -gc <pid></pid>观察EU（Eden 使用率）和OU（Old 区使用率）突增是否与异常频次曲线吻合； - 在关键异常捕获点加计数器（如 Micrometer Counter），告警单位时间异常量 > 阈值（如 100/s）；
- 对非关键路径的 catch 块，避免
ex.printStackTrace()—— 它会把堆栈打到 stderr，且不释放引用，易引发间接泄漏。
异常该轻量、可预测、易归因。把“描述信息”交给日志，把“控制流语义”留给异常本身，堆就不会被自己人悄悄撑爆。
