关于 Integer 作为锁对象的风险总结
核心结论
Integer（如 Integer lock = 1;）不适合作为 synchronized 的锁对象，因缓存复用和不可变性导致同步逻辑失效。
关键风险点
-
缓存复用导致锁冲突
Java 对[-128, 127]范围内的Integer实现缓存池复用，不同变量（如lockA = 1和lockB = 1）会指向同一对象。
→ 后果：无关线程竞争同一把锁，破坏同步隔离性，降低并发效率。 -
不可变性引发锁替换
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，从根源上避免同步问题。