最有效解法是缩小同步范围。synchronized本身不慢，慢在锁住非共享操作；应只锁真正需保护的代码，移出日志、网络调用等；用细粒度锁对象、读写锁、volatile、无锁原子类及分片结构优化高并发场景。
直接缩小同步范围是最有效、最易落地的解法。synchronized 本身不慢，慢在锁住太多不该锁的东西——比如把日志、网络调用、对象构造这些非共享操作也裹进同步块里，人为拉长临界区，让线程排队时间远超实际工作时间。
只锁真正需要保护的代码
把耗时、无关共享资源的操作移出 synchronized 块：
- 反例：在同步块里做数据库查询、HTTP 调用、格式化字符串等
- 正例：先完成所有非共享逻辑，再用最小代码段更新共享变量
- 例如计数器更新，只需
synchronized(this) { count++; }，不要包裹校验或返回前的日志
换更细粒度的锁对象
避免锁整个 this 或类对象，改用专用锁实例：
- 声明
private final Object lock = new Object();，只用于保护特定字段 - 对集合类操作，不锁整个 List，而锁其内部某个分段或桶（如模拟 ConcurrentHashMap 分段）
- 不同业务维度用不同锁：用户 ID 分桶锁、数据类型隔离锁、租户级锁
读多写少场景优先用读写分离
若同步块中大量是读操作，synchronized 的独占性会严重拖累并发度：
立即学习“Java免费学习笔记（深入）”；
- 用
ReentrantReadWriteLock：读锁可重入且共享，写锁仍独占 - 简单值或不可变对象（如
final String、ImmutableList）直接用volatile，零锁开销 - 超高频读+低频写，考虑
StampedLock的乐观读模式
高频写场景转向无锁或分片结构
当多个线程反复修改同一字段（如全局计数器），单把锁必然成为瓶颈：
- 用
AtomicInteger、AtomicLong替代int+synchronized - 累加类操作优先选
LongAdder，内部 cell 分片，写操作并行化 - Map 类操作用
ConcurrentHashMap，读完全无锁，写按 segment 分片
