synchronized修饰方法能保证自增线程安全，但仅适用于简单场景；它本质是把整个方法变成临界区，靠对象锁互斥执行，性能开销明显，且无法应对跨方法的复合操作。
直接说结论：用 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 或分段计数才是更现实的选择 —— 它们牺牲一点强一致性，换来了数量级的吞吐提升。
