synchronized锁粒度直接影响并发度：粒度越粗并发越低，越细并发越高，但须保障线程安全；锁对象决定互斥范围——锁this限于同一实例，锁class实现类级别串行，锁自定义对象可精准控制互斥边界。
synchronized 锁的粒度直接决定有多少线程能同时执行临界区代码，粒度越粗，并发度越低；粒度越细，并发度越高，但需确保线程安全不被破坏。
锁对象决定并发边界
锁住什么，就限制什么范围内的并发：
- 锁 this（实例方法或
synchronized(this)）：同一对象的多个同步方法互斥，不同对象之间完全不干扰 - 锁 Class 对象（静态方法或
synchronized(MyClass.class)）：整个类所有实例共享一把锁，全局串行化 - 锁 自定义对象（如
private final Object lock = new Object()）：可精准控制哪些操作需要互斥，避免锁范围过大
方法级锁 vs 代码块级锁
方法加 synchronized 相当于把整个方法体包进同步块，容易过度锁定：
- 如果方法里只有几行是共享资源操作，其余是IO、计算或本地变量处理，全方法加锁会白白阻塞其他线程
- 改用
synchronized(lockObj) { /*仅关键逻辑*/ }，只锁真正需要保护的代码段，提升并发吞吐 - 例如：批量处理中，仅 JDBC 批量提交需同步，而数据预处理、日志记录等可并行执行
粒度不当的典型后果
不是“加了锁就安全”，也不是“越细越好”，关键在匹配业务语义：
- 锁太粗（如用 Class 锁保护单个订单状态）→ 多个订单处理被迫排队，吞吐暴跌
- 锁太细（如每个批次用独立锁对象，但聚合结果需全局一致性）→ 数据可能写乱，失去业务原子性
- 锁对象可变（如用
new Object()每次新建）→ 实际没锁住任何东西，形同虚设 - 混用多种锁（this 锁 + static 锁 + 自定义锁）却未理清保护目标 → 同步失效或死锁风险上升
高并发场景下的现实约束
synchronized 本质是互斥机制，无法设定“最多 N 个线程并发”：
- 它只能做到“同一时刻最多 1 个线程进入”，即并发度上限为 1
- 若业务需要可控并发（比如最多 5 个线程并行写库），必须换用
Semaphore或线程池限流 - 在争用激烈时，JVM 可能将锁升级为重量级锁，依赖操作系统 mutex，带来更高调度开销
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
