java 中对象的序列化与字段修改若在多线程下无同步保障，将导致不可预测的行为——既无隐式锁、无内存可见性保证，也无执行顺序约束；其结果取决于 jvm 内存模型中的“恶币”（evil coin）随机性，而非代码书写顺序。
java 中对象的序列化与字段修改若在多线程下无同步保障，将导致不可预测的行为——既无隐式锁、无内存可见性保证，也无执行顺序约束；其结果取决于 jvm 内存模型中的“恶币”（evil coin）随机性，而非代码书写顺序。
在 Java 并发编程中，对象序列化（如 ObjectOutputStream）与业务逻辑中的字段修改（如调用 setter）本质上是完全独立且无协调机制的两个操作。二者若未经显式同步并发执行，将直接落入 Java 内存模型（JMM）未定义行为的灰色地带——这不是“可能出错”，而是“必然不可靠”，且无法通过测试穷举验证。
? 核心事实：不存在隐式同步，也没有对象级锁
Java 语言规范中不存在“对对象加锁”的概念。synchronized(obj) 并非锁定 obj 本身，而只是建立一个以 obj 为监视器（monitor）的临界区协议：仅当多个线程都使用同一监视器进入 synchronized 块时，才构成互斥。序列化过程（writeObject()）内部不执行任何 synchronized(this) 或等效同步操作，也不会声明 volatile 字段、不发布 HB（Happens-Before）关系。因此：
- ✅ 序列化不会阻塞 setter 调用，setter 也不会等待序列化完成；
- ❌ 二者可完全并行执行，但无任何内存可见性或执行顺序保证；
- ⚠️ 这不是“性能问题”，而是语义层面的根本缺陷：程序行为已脱离开发者控制。
? 示例：危险的并发读写
考虑如下典型场景：
public class Counter implements Serializable {
private int value = 0;
public void increment() { value++; }
public int getValue() { return value; }
}
// 线程 A：持续修改
new Thread(() -> {
while (running) {
counter.increment(); // 非原子、无同步
Thread.sleep(1);
}
}).start();
// 线程 B：并发序列化
new Thread(() -> {
try (ObjectOutputStream oos = new ObjectOutputStream(
new FileOutputStream("counter.ser"))) {
oos.writeObject(counter); // 无同步，无 HB 关系
}
}).start();此时，序列化结果可能是：
立即学习“Java免费学习笔记（深入）”；
-
value = 42（修改前旧值）， -
value = 105（修改后新值）， - 甚至出现 “撕裂”（torn）状态（如
value是long或引用类型时，高位/低位、部分字段被更新而另一些未更新）。
这些结果均符合 JVM 规范——因为 JMM 明确允许：在缺乏 HB 关系时，一个线程对字段的写入，对另一线程是否可见、何时可见、是否部分可见，均由底层硬件与 JVM 实现“自由裁量”。
⚙️ 性能影响的本质：HB 的代价即正确性的成本
有人误以为“序列化慢所以会影响 setter”，实则因果倒置：
真正影响 setter 性能的，是为确保线程安全而引入的同步机制（如 synchronized、ReentrantLock、volatile），而非序列化本身。
例如，若强制要求序列化与修改互斥：
public class SafeCounter implements Serializable {
private volatile int value = 0;
public synchronized void increment() {
value++;
}
public synchronized void serializeTo(OutputStream out) throws IOException {
try (ObjectOutputStream oos = new ObjectOutputStream(out)) {
oos.writeObject(this);
}
}
}此时性能下降源于 synchronized 块的锁竞争与内存屏障开销（跨 CPU 核同步需数千周期），这是为换取确定性行为所必须支付的代价。若省略同步，则看似“快”，实则产出的数据毫无业务意义。
✅ 正确实践：隔离 + 显式同步 + 替代方案
| 原则 | 具体做法 |
|---|---|
| 避免共享可变状态 | 将待序列化的数据建模为不可变对象（record 或 final 字段类），修改时创建新实例，序列化只作用于快照。 |
| 显式同步临界区 | 若必须复用可变对象，所有访问（含序列化）统一通过同一锁保护：synchronized(counter) { oos.writeObject(counter); }
|
| 选用更健壮的序列化协议 |
强烈建议弃用 java.io.Serializable。改用 Protobuf、Jackson JSON、Avro 等明确版本兼容、跨语言、无隐藏状态依赖的格式。它们天然规避了 Java 序列化与 JVM 内存模型的耦合风险。 |
| 用消息传递替代共享内存 | 通过 BlockingQueue、ConcurrentLinkedQueue 或 Actor 模型传递数据副本，彻底消除多线程直接读写同一对象的场景。 |
? 总结
- 序列化 ≠ 锁，也不提供任何并发安全保证；
- 并发修改 + 并发序列化 = 未定义行为（evil coin），测试无法覆盖所有硬件/JVM 组合下的随机性；
- 性能瓶颈不在序列化本身，而在构建 HB 关系所需的同步开销——这是正确性的必要投资；
- 根本解法是架构层面规避共享可变状态，辅以现代序列化工具和明确的线程通信契约。
记住：在并发世界里，“它在我机器上跑通了”不是正确性的证据，而是灾难的倒计时。真正的鲁棒性，始于对 Java 内存模型的敬畏，成于对 Happens-Before 关系的精确掌控。
