java中无“异常快照”标准技术，实为在异常抛出时主动捕获线程堆栈、锁状态、关键变量等现场信息的组合手段；需手动在catch中调用jstack等工具获取pid并生成快照，避免高频调用与序列化陷阱，按异常类型分级采集。
Java 中没有叫“异常快照”的标准技术——它是个容易误导的俗称，实际指在异常发生时主动捕获线程状态和关键对象状态的组合手段。 你真正需要的，是能在 Exception 或 Error 被抛出的瞬间，留下可回溯的现场证据：线程堆栈、锁持有关系、关键变量值、甚至堆内存片段。这不是 JVM 自动做的，得靠人设计触发时机和保存逻辑。
怎么用 jstack 抓住异常发生时的线程快照
异常本身不自动触发线程快照，但你可以把它变成一个信号：在 catch 块里调用系统命令生成快照文件。注意，jstack 是外部工具，必须确保它在 PATH 中，且目标进程有权限被访问。
- Windows/Linux 下直接执行
jstack <pid> > thread-snapshot.log</pid>最简单，但前提是你要先拿到当前 JVM 的 PID - 获取 PID 推荐用
ManagementFactory.getRuntimeMXBean().getName()，返回形如"12345@hostname"，取split("@")[0]即可 - 别在多线程高频异常场景里频繁调用
jstack：它会短暂挂起目标 JVM，可能加剧卡顿或掩盖真实问题 - 如果应用跑在容器里（如 Docker），
jstack需要进入容器命名空间执行，宿主机直接调用会失败
为什么不能只靠 printStackTrace() —— 它缺了什么
printStackTrace() 只告诉你「哪行代码炸了」，但不说「当时线程在等谁」「哪个对象正被修改」「堆里还有多少大对象没回收」。比如死锁时，异常可能根本没抛出，但 jstack 能直接标出 java.lang.Thread.State: BLOCKED (on object monitor) 和等待链。
- 堆栈信息缺失上下文：比如
NullPointerException出现在user.getName()，但你不知道user是 null 还是getName()内部又抛了异常 - 无法反映并发状态：两个线程同时修改同一
ArrayList导致ConcurrentModificationException，但堆栈只显示报错位置，看不出谁先加了锁、谁在迭代 - GC 压力看不见：OOM 前可能已频繁 Full GC，但异常堆栈里不会带
-XX:+PrintGCDetails日志
如何安全地记录「变量快照」——避开序列化陷阱
想保存异常时刻的关键对象（比如请求参数、业务上下文），别直接 new ObjectOutputStream 序列化整个对象图：一来可能含不可序列化字段（如 ThreadLocal、数据库连接），二来深克隆开销大，三来反序列化后对象身份已变，无法用于调试原始引用关系。
立即学习“Java免费学习笔记（深入）”；
- 优先用轻量方式：把你想看的字段手动拼成
Map<string object></string>，再转 JSON（如 Jackson 的ObjectMapper.writeValueAsString()） - 避免序列化含循环引用的对象（如父子级联的 JPA 实体），否则会抛
StackOverflowError - 不要在
catch里做耗时操作（如写磁盘、网络调用），否则可能掩盖异常真实耗时，甚至导致二次异常（如IOException） - 敏感字段（密码、token）务必过滤，日志/快照文件可能被非授权访问
最常被忽略的一点：快照不是越全越好。一次 OOM 后生成的堆转储（hprof）可能几个 GB，而你真正需要的只是其中某个 char[] 占用 90% 堆内存的线索。与其无差别保存，不如在异常类型上做分级——NullPointerException 记线程+局部变量，OutOfMemoryError 再触发 jmap -dump。
