对象锁：锁的是 this 或任意具体实例
用 synchronized 修饰非静态方法，或者用 synchronized(this) 块，锁的就是当前对象实例。多个线程调用同一个对象的同步方法时会互斥；但调用不同对象的同一方法，彼此不干扰。
常见错误是以为“加了 synchronized 就全局串行”，其实只要 new 出多个对象，每个对象都有自己的锁。
- 场景：银行账户转账、计数器累加（单个账户实例）
- 注意：
synchronized方法等价于synchronized(this) { ... }，不是锁方法签名或类 - 性能影响小，但若对象生命周期长、竞争激烈，可能成为瓶颈
类锁：锁的是 Class 对象，本质是 MyClass.class
用 synchronized 修饰静态方法，或者 synchronized(MyClass.class) 块，锁的是该类的 Class 对象。所有线程无论操作哪个实例，只要进这个类锁区域，就排队。
容易踩的坑是混淆“类锁”和“对象锁”——比如在静态方法里去同步一个实例变量，编译能过，但根本锁不住，因为静态上下文没有 this。
立即学习“Java免费学习笔记（深入）”；
- 场景：初始化单例、加载配置、全局资源计数（如总请求量）
- 等价写法：
synchronized(YourClass.class)和synchronized(staticMethod)效果一致 - 兼容性没问题，但过度使用会严重拖慢并发吞吐，尤其在高 QPS 场景下
锁升级与 monitor：别把 synchronized 当万能锁
JVM 对 synchronized 做了优化，从无锁 → 偏向锁 → 轻量级锁 → 重量级锁。但这些对开发者透明，你控制不了，只能靠设计规避问题。
真正要注意的是：锁粒度太粗，比如整个方法都 synchronized，而实际只有一两行要保护；或者在锁内做 IO、远程调用、sleep，会让其他线程傻等。
- 建议：只包裹真正需要互斥的代码块，而不是整个方法体
- 避免在 synchronized 块中调用外部服务或等待用户输入
- 如果需要更灵活的控制（如超时、可中断），考虑
ReentrantLock，而不是硬撑synchronized
常见错误现象：看似加了锁，却没效果
最典型的是“锁错对象”：比如在多线程创建多个 Counter 实例，每个实例都有自己的 synchronized inc()，结果总数还是错的——因为你要的是全局计数，得用类锁或共享对象锁。
另一个高频问题是“锁住可变引用”：比如用 synchronized(list)，但 list 被重新赋值了，后续线程锁的其实是新对象，老锁失效。
- 错误示例：
List<string> data = new ArrayList(); synchronized(data) { data = new ArrayList(); }</string>—— 后续同步无效 - 正确做法：锁一个生命周期稳定的对象，比如私有 final 字段：
private final Object lock = new Object(); - 调试技巧：遇到数据不一致，先确认是不是多个线程操作的是不同锁目标，而不是逻辑 bug
锁的本质是内存可见性 + 互斥执行，不是语法糖。synchronized 的行为取决于你锁住的那个对象是否被所有相关线程共同看到和使用——这点最容易被忽略，也最难通过日志直接发现。
