[ java 锁 - 04 - Integer o = 1 作为 锁的问题]

关于 Integer 作为锁对象的风险总结

核心结论

Integer（如 Integer lock = 1;）不适合作为 synchronized 的锁对象，因缓存复用和不可变性导致同步逻辑失效。

关键风险点

1. 缓存复用导致锁冲突
   Java 对 [-128, 127] 范围内的 Integer 实现缓存池复用，不同变量（如 lockA = 1 和 lockB = 1）会指向同一对象。
   → 后果：无关线程竞争同一把锁，破坏同步隔离性，降低并发效率。

2. 不可变性引发锁替换
   Integer 是不可变类，若对锁对象重新赋值（如 lock = 2），会导致锁引用指向新对象。
   → 后果：同步块实际锁定的对象变化，多个线程可同时进入临界区，破坏线程安全。

final 修饰的局限性

• 加 final（final Integer lock = 1）可避免锁被替换，但无法解决缓存复用问题（仍可能与其他 Integer(1) 锁冲突）。

正确替代方案

使用 final Object 作为锁对象：

private final Object lock = new Object(); // 最优解

• 唯一性：new Object() 每次创建独立实例，无缓存复用，确保锁隔离。
• 稳定性：final 修饰保证引用不可修改，避免锁替换。

总结

Integer 因缓存机制和不可变性，存在锁冲突和替换风险，不适合作为锁对象。优先使用 final Object，从根源上避免同步问题。