同步块虽比同步方法粒度更细，但未必更快；锁开销、临界区长度、锁对象选择、锁升级及并发设计缺陷均影响性能，需综合权衡而非盲目缩小同步范围。
同步块比同步方法更细粒度，但不等于一定更快
Java中用synchronized修饰方法会锁住整个方法体，而同步块可以只锁关键临界区。但这不是“越小越好”——锁的获取/释放本身有开销，如果临界区极短（比如只读一个volatile字段），加同步块反而拖慢性能。
- 优先识别真正需要互斥的操作：比如
counter++、list.add()这类非原子操作 - 避免把对象构造、日志打印、IO调用等非共享资源操作包进同步块
- 若同步块内频繁调用其他可能阻塞的方法（如
Thread.sleep()或数据库查询），实际线程会持锁等待，放大争用
锁对象选择直接影响竞争程度
用this或ClassName.class作锁对象最常见，但也最容易引发意外争用。比如两个无关业务逻辑共用同一个实例或类锁，表面无关联，实则互相阻塞。
- 对独立状态变量，优先使用私有final对象锁：
private final Object lock = new Object(); - 不要用字符串字面量（如
"LOCK"）或可变对象（如ArrayList实例）作锁，前者可能被JVM字符串常量池复用，后者可能被外部修改 - 静态资源用
MyClass.class合理，但若类被多个类加载器加载，MyClass.class就不是全局唯一锁了
注意锁升级和偏向锁失效带来的隐性开销
JVM在运行时会对synchronized做锁优化：偏向锁 → 轻量级锁 → 重量级锁。但一旦发生锁竞争（如多个线程反复抢同一把锁），偏向锁会批量撤销，触发STW暂停，反而比一开始就用轻量级锁更慢。
- 高并发写场景（如高频计数器）建议在JVM启动时关闭偏向锁：
-XX:-UseBiasedLocking - 可通过
-XX:+PrintSynchronizationStatistics观察锁膨胀次数，确认是否频繁升级 - 同步块内不要混用
wait()/notify()与显式ReentrantLock，否则JVM无法安全优化
同步块无法解决所有并发问题，别误当万能解药
同步块只保证原子性和可见性，不解决指令重排、死锁、活锁或复合操作的线性一致性。比如“检查后执行”（check-then-act）模式，即使用同步块包裹if (list.isEmpty()) list.add(x);，仍可能因条件判断与添加之间被其他线程插入而失效。
立即学习“Java免费学习笔记（深入）”；
- 这类场景应改用线程安全容器：
ConcurrentHashMap、CopyOnWriteArrayList，或用AtomicInteger.compareAndSet()等CAS操作 - 多步关联操作（如转账：扣A账户+加B账户）需确保所有步骤在同一个锁下完成，且锁对象必须全局一致，不能每个账户用自己的锁
- 同步块嵌套容易引发死锁，尤其当锁顺序不统一时——这点比性能问题更隐蔽、更难排查
synchronized写在哪一行，而是为什么非要多个线程同时修改同一块内存。 
