避免浅拷贝异常对象，应提取类名、消息等关键字段零分配输出，禁用自动堆栈采集，使用异步日志+对象池，并在GC压力大时绕过堆内存直写文件或对齐ZGC日志分析。
异常对象浅拷贝本身不是标准日志技术，也不能直接“提升日志性能”——它甚至在多数场景下不适用。真正关键的是：在GC受限（如ZGC低暂停、堆内存紧张）的生产环境中，**避免日志操作触发额外对象分配与引用链膨胀**，从而防止干扰GC节奏或诱发OutOfMemoryException。
别拷贝异常对象，先冻结关键字段
异常对象（如Exception、RuntimeException）通常携带完整堆栈（getStackTrace()返回StackTraceElement[]），这个数组是新分配的对象，且元素本身也是对象。在ZGC或G1并发回收压力大时，频繁构造和记录完整堆栈会增加年轻代分配压力，还可能延长Final Mark阶段扫描时间。
- 只提取你真正需要的字段：异常类名、消息字符串、错误码（如有），用
e.getClass().getSimpleName()+e.getMessage()拼接，不调用toString()或printStackTrace() - 禁用自动堆栈采集：某些日志框架（如Log4j2异步Appender）支持配置
includeLocation=false和stackTraceEnabled=false，从源头减少开销 - 若必须保留上下文，可预先缓存精简后的堆栈快照（例如只取前3帧），用
Arrays.copyOf(e.getStackTrace(), 3)并复用数组缓冲区
日志输出本身要零分配或池化
高性能日志的核心不在“怎么记异常”，而在“怎么写出去时不造垃圾”。尤其在ZGC要求亚毫秒级暂停的系统中，每次logger.error("msg", e)都可能隐含StringBuilder扩容、格式化字符串拼接、包装器对象创建等行为。
- 使用无锁异步日志器（如Log4j2 AsyncLogger）+ 环形缓冲区（RingBuffer），日志事件入队即返回，序列化由独立线程完成
- 启用日志器的
object pooling特性（如Log4j2的log4j2.enableThreadContextMapInheritable=true配合对象池），避免每次记录都新建LogEvent - 对高频异常路径（如网络超时、限流拒绝），预定义结构化日志模板，用
logger.atError().addArgument(...).log("req_id={}, code={}")替代字符串拼接
绕过JVM GC干扰的落盘策略
当堆内存持续接近上限、GC频率升高时，常规日志框架的缓冲区可能因内存不足而阻塞或降级。此时应将异常日志导向更轻量、可控的通道：
- 用
FileChannel.write()配合DirectByteBuffer写入日志文件，绕过堆内存分配（注意权限与文件句柄管理） - 在ZGC日志已启用的前提下（
-Xlog:gc*:file=zgc.log），将关键业务异常与GC暂停时间对齐：在catch块中写入带时间戳的标记行（如[EXCEPTION] 2026-05-18T21:31:12.456 ERROR OrderService timeout），后续用grep "Pause\|EXCEPTION" zgc.log联合分析 - 极端情况下，通过
DiagnosticCommand动态开启临时GC日志（无需重启），把异常发生时段的GC行为快照导出，辅助判断是否为GC反压导致异常频发
警惕“浅拷贝异常”的误导陷阱
所谓“异常对象浅拷贝”，比如new RuntimeException(e.getMessage(), e.getCause())，看似省事，实则危险：
- 丢失原始堆栈——
e.getStackTrace()不会被复制，新异常的堆栈指向日志封装处，而非真实出错点 - 仍会触发新对象分配——至少新建一个Exception实例，其内部字段（如
detailMessage）仍需堆内存 - 若原异常是
OutOfMemoryException，再抛新异常可能直接失败，连最后的错误提示都丢失
真正可靠的方案是：捕获后立即提取最小必要信息，用无分配方式输出，不构造新异常、不深遍历、不依赖反射。日志不是为了好看，而是为了在GC喘不过气时，还能告诉你哪口气没喘上来。
