在Java中synchronized关键字如何保证线程安全_Java内置锁机制原理解析_技术教程

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() < amount) throw new InsufficientException();
    
    // 只锁真正需要互斥的部分
    synchronized (from) {
        synchronized (to) {
            from.debit(amount);
            to.credit(amount);
        }
    }
}