synchronized能防止count++出错，因其将非原子的读-改-写三步强制串行执行，并保证可见性；锁对象不同（this或class）决定阻塞范围；JVM锁升级机制优化低并发性能；同步代码块比同步方法更精准高效。
为什么 synchronized 能防止 count++ 出错
因为 count++ 不是原子操作，它实际拆成三步：读取当前值 → 加 1 → 写回内存。多个线程同时执行这三步，就可能互相覆盖，导致最终结果比预期少。而 synchronized 强制这些步骤在临界区内串行执行——同一时刻只有一个线程能进入，其他线程必须等锁释放后才能尝试获取。
- 锁的粒度决定并发能力：锁
this时，不同实例互不影响；锁Counter.class时，所有实例共用一把锁，吞吐量骤降 - 即使方法抛异常，JVM 也会自动执行
monitorexit指令释放锁，不会发生“死锁住不放”的情况 - 它不只是互斥，还附带内存语义：锁释放时强制刷写变量到主内存，锁获取时强制从主内存重读，解决了可见性问题
synchronized(this) 和 synchronized(Counter.class) 的区别在哪
关键看锁对象是谁——决定了哪些线程会互相阻塞。
-
synchronized(this)：锁的是当前实例（比如new Counter()），两个不同实例的同步方法可并行执行 -
synchronized(Counter.class)或public static synchronized void inc()：锁的是Counter.class对象，所有该类的实例共享这把锁，静态方法和 class 锁本质是同一回事 - 错误示范：
synchronized("lock")—— 字符串常量池会复用相同字面量的字符串，导致看似无关的代码意外串行，极易引发隐蔽竞争
锁升级机制如何影响实际性能
HotSpot JVM 并不是一上来就用重量级锁，而是按需升级：无锁 → 偏向锁 → 轻量级锁 → 重量级锁。这意味着低并发场景下几乎没有上下文切换开销。
- 偏向锁适合单线程反复进入同一同步块（如初始化阶段），首次加锁只记录线程 ID，后续无需 CAS
- 轻量级锁在中等竞争时启用自旋（spin），线程在用户态循环等待，避免进内核态阻塞
- 一旦自旋失败次数超阈值（默认 10 次），或有多个线程竞争，就会膨胀为重量级锁，此时线程真正挂起，触发 OS 调度，开销明显上升
- 可通过 JVM 参数
-XX:-UseBiasedLocking关闭偏向锁（JDK 15+ 默认禁用），适用于高竞争服务端场景
同步代码块比同步方法更值得优先使用
同步方法会锁住整个方法体，哪怕只有几行要保护，其余逻辑也得排队。而同步代码块可以精准包裹临界区，减少锁持有时间，提升并发度。
public void transfer(Account from, Account to, int amount) {
// 非临界操作：校验、日志等，无需锁
if (from.getBalance()
- 注意嵌套锁顺序：始终按固定顺序（如按对象 hashcode 排序）获取多把锁，否则容易死锁
- 不要用
String、Integer等常量池对象作锁，它们可能被其他模块无意复用 - 若需细粒度控制，推荐声明私有 final 锁对象：
private final Object lock = new Object();，避免锁被外部误用
锁不是越粗越好，也不是越细越安全——关键是识别出真正的共享状态变更点，并确保所有访问路径都走同一把锁。很多并发 bug 其实源于“以为自己锁住了，其实漏了一处”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
