writeunshared 是 java 序列化中用于阻断对象图共享的安全机制，强制每次写入均为独立快照，防止敏感状态因引用复用被篡改或泄露。
writeUnshared 是 Java 序列化中一个被低估但关键的安全控制点，它不解决“数据是否该序列化”，而是解决“同一个对象在流中是否被多次引用”这一底层行为。当处理含敏感状态变量（如临时令牌、会话密钥、未加密凭证）的对象时，它能有效阻断因对象图共享引发的意外泄露或篡改风险。
为什么对象共享本身就会带来安全风险
默认的 writeObject() 会维护一个内部引用表（handle table）。如果同一个对象实例被多次写入流中，后续出现时只写入一个轻量级引用（handle），而非完整数据。这虽节省空间、保持对象图一致性，但也意味着：
- 攻击者若截获并修改流中某处的共享对象数据，所有引用该 handle 的位置都会同步“还原”为被篡改后的值；
- 若敏感状态变量（如
transient byte[] sessionKey）被封装在某个被多次引用的容器对象中，其原始值可能在反序列化时被错误复用，绕过本应每次重新生成/校验的逻辑； - 调试器或中间件日志若记录了序列化流，共享引用会让敏感内容在多个位置“隐式暴露”，增加侧信道泄露面。
writeUnshared 如何打破共享链
writeUnshared(Object obj) 强制将 obj 视为全新实例写入——即使它已在流中出现过，也会再次完整序列化其状态，且分配新的 handle。它不改变类定义、不跳过 transient 字段，也不影响 serialVersionUID 校验，只干预引用管理层。
- 对含敏感状态的配置对象、上下文对象或短期凭证对象，调用
writeUnshared()可确保每次写入都是独立快照，杜绝“一处污染、全局生效”； - 配合自定义
writeObject()方法，可在敏感字段加密后，再以writeUnshared()输出密文对象，避免密文被其他同类型对象意外复用； - 注意：它不阻止反射或调试器读取内存中对象，仅约束序列化流层面的对象图结构。
实际使用中的关键限制与配合建议
该方法不是银弹，需结合其他机制才能形成有效防护：
- 必须由序列化发起方主动调用，接收方无需特殊处理，反序列化仍用
readObject()； - 不能替代
transient或加密——若字段本身不该持久化，仍需声明transient；若需保密，应在写入前加密，再对密文对象调用writeUnshared()； - 慎用于大型对象或高频调用场景，重复序列化会增加体积和 CPU 开销；
- 与
enableReplaceObject()配合时需格外注意：若替换逻辑返回相同实例，writeUnshared()仍会强制重写，可能绕过预期的替换策略。
一个典型防护组合示例
假设有一个 AuthContext 类，含 private byte[] csrfToken（需防重放）和 private String userId（可共享）：
- 将
csrfToken声明为transient，避免默认序列化； - 在自定义
writeObject()中，对csrfToken加密后构造EncryptedToken对象； - 对该
EncryptedToken实例调用out.writeUnshared(encrypted)，确保每次请求都生成独立密文块； -
userId等非敏感字段仍走默认writeObject()，维持正常引用语义。
