17370845950

Java异常类必须实现Serializable，因为Throwable实现了该接口，确保异常可跨JVM传输；未显式声明serialVersionUID会导致结构变更时反序列化失败；含非transient不可序列化字段会抛NotSerializableException。

Java异常类为什么必须实现 Serializable

Java异常类默认需要序列化，根本原因在于：所有标准异常（如 Exception、RuntimeException）都继承自 Throwable，而 Throwable 类本身实现了 Serializable 接口。这意味着任何自定义异常若不显式声明，也会自动具备序列化能力——但前提是它没有包含不可序列化的字段。

自定义异常不加 serialVersionUID 会怎样

不显式定义 serialVersionUID 时，JVM 会根据类名、接口、成员方法和字段等自动生成一个。一旦类结构变动（比如新增字段、修改访问修饰符），生成的 UID 就会变化，导致反序列化失败，抛出 InvalidClassException。

• 常见错误现象：java.io.InvalidClassException: MyException; local class incompatible: stream classdesc serialVersionUID = 123..., local class serialVersionUID = 456...
• 使用场景：RMI 调用、分布式日志传输、Jetty/Tomcat 的异常页面缓存、某些监控 SDK 序列化异常上下文
• 建议始终显式声明：

  private static final long serialVersionUID = 1L;

  或用 IDE 自动生成带时间戳的值（如 8290739329384729384L）

哪些字段会导致异常无法正常序列化

只要异常类中添加了非 transient、非 static 且类型不可序列化的字段，就会在序列化时抛出 NotSerializableException。

• 典型踩坑点：private Connection dbConn;、private ThreadLocal context;、private Logger logger;
• 解决方案：用 transient 修饰这些字段，或确保其类型实现 Serializable
• 注意：cause（即 initCause() 设置的嵌套异常）会被自动序列化，无需额外处理

writeObject 和 readObject 在异常类中要不要重写

绝大多数情况下不需要重写。除非你有特殊需求，比如想过滤敏感字段（如密码、token）、统一填充诊断信息，或兼容旧版本序列化格式。

• 重写风险：容易破坏 Throwable 内部状态（如 stackTrace、suppressedExceptions），导致反序列化后 printStackTrace() 不完整或 getSuppressed() 返回空数组
• 如果真要定制，必须调用 defaultWriteObject() / defaultReadObject() 并严格保持字段顺序与父类一致
• 更安全的替代方案：通过构造函数参数传递上下文，而非靠序列化字段承载业务数据

异常序列化不是“可选项”，而是 Java 异常机制跨线程、跨 JVM 生存的前提；真正容易被忽略的是字段污染——一个没加 transient 的 ExecutorService 字段，就足以让整个异常对象在远程调用中静默失败。