synchronized实现线程安全自增详解

synchronized方法虽能通过对象锁将i++这类非原子操作“打包”成线程安全的临界区，从而解决基础自增竞争问题，但其粗粒度加锁带来显著性能开销，且仅在共享同一实例或正确使用静态锁的前提下才真正生效；面对复合业务逻辑、高并发计数或跨方法协作等复杂场景，它既无法保证事务完整性，也易成性能瓶颈，此时同步代码块、AtomicInteger、LongAdder乃至外部协调机制（如Redis INCR或数据库行锁）才是更高效、更可靠的替代方案。

直接说结论：用 synchronized 修饰方法能保证自增线程安全，但仅适用于简单场景；它本质是把整个方法变成临界区，靠对象锁互斥执行，性能开销明显，且无法应对跨方法的复合操作。

为什么synchronized修饰方法能解决i++问题

因为 i++ 实际包含三步：读内存值 → 寄存器加1 → 写回内存。多线程下这三步可能被交错执行，导致结果丢失。而 synchronized 方法强制同一时刻只有一个线程能进入该方法体，相当于把这三步“打包”成原子段。

关键点在于锁对象：非静态方法默认锁的是当前实例（this），静态方法锁的是类对象（ClassName.class）。若多个线程操作的是同一个对象实例，才能真正串行化。

• 错误示范：两个线程各自 new 一个新对象调用同步方法 → 锁不同，不生效
• 正确前提：共享同一个对象实例，或使用静态同步方法 + 共享类变量

synchronized方法 vs 同步代码块的区别

方法级同步写起来省事，但粒度太粗。比如一个方法里只有前两行要保护，后三行纯本地计算，也得等锁 —— 白白拖慢吞吐。

• synchronized void increment() { count++; }：整个方法体被锁，哪怕里面还有日志、条件判断等无关逻辑
• void increment() { synchronized(this) { count++; } }：只锁自增这一行，其余代码可并发执行
• 如果只是保护一个 int 字段，推荐用 AtomicInteger，比任何锁都轻量

常见踩坑点

看似加了 synchronized，运行结果还是不对？大概率掉进这几个坑：

• 锁对象不一致：比如用了两个不同实例，或混用静态/非静态方法但没统一锁目标
• 误以为 synchronized 能保证可见性就够了：其实它确实能，但若字段还被其他非同步方法读写，依然可能出错
• 在继承体系中忽略锁语义：子类重写同步方法，若未显式加 synchronized，就失去同步保障
• 和 volatile 混用误解：volatile 只保证可见性和禁止重排序，不保证原子性，volatile int count 配 count++ 依然线程不安全

什么时候不该用synchronized方法做自增

当你的自增不是孤立动作，而是嵌套在更复杂的业务逻辑里（比如“查库存→够则扣减→更新订单”），单纯同步方法无法覆盖整个事务边界。这时候要么升级为 ReentrantLock 配合 try-finally 精确控制，要么改用数据库行锁、Redis 的 INCR 命令等外部协调机制。

另外，高并发计数场景（如秒杀UV统计），synchronized 容易成为瓶颈，LongAdder 或分段计数才是更现实的选择 —— 它们牺牲一点强一致性，换来了数量级的吞吐提升。

到这里，我们也就讲完了《synchronized实现线程安全自增详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！