在Java中如何使用synchronized关键字保证方法安全_Java方法同步实践解析

synchronized修饰实例方法会锁住当前对象，因为JVM隐式以this为锁对象，同一对象的多线程互斥执行，不同对象则互不影响；静态方法锁Class对象，所有线程竞争同一把锁。

为什么synchronized修饰实例方法会锁住当前对象

因为 synchronized 修饰非静态方法时，JVM 会隐式使用 this 作为锁对象。同一对象的多个线程调用该方法时，只能有一个进入，其余阻塞；但不同对象的调用互不影响。

常见错误是以为“加了 synchronized 就全局安全”，结果多实例场景下仍出现竞态——比如每个请求创建新 Counter 实例，synchronized increment() 完全无效。

• 适用场景：共享同一对象状态的多线程访问，如单例工具类、缓存容器实例
• 等价写法：

  public void increment() {
      synchronized(this) {
          count++;
      }
  }

• 注意：若方法内抛出异常且未捕获，锁仍会自动释放，这点比手动 ReentrantLock 更省心

synchronized静态方法锁的

是Class对象

静态方法属于类而非实例，所以锁的是 MyClass.class。这意味着所有线程调用该静态方法时，无论通过哪个实例或直接通过类名，都竞争同一把锁。

典型误用：把本该保护全局计数器的逻辑放在实例方法里，却期望跨实例生效；正确做法是改用静态同步方法或显式锁 MyClass.class。

• 等价写法：

  public static synchronized void addGlobalCount() {
      globalCount++;
  }

  ⇔

  public static void addGlobalCount() {
      synchronized(MyClass.class) {
          globalCount++;
      }
  }

• 兼容性提示：Java 8+ 中 static synchronized 与显式 Class 锁行为完全一致，无版本差异
• 性能影响：高并发下调用频繁的静态同步方法可能成为瓶颈，应优先考虑 AtomicInteger 或分段锁

同步代码块比同步方法更灵活也更易出错

同步方法锁粒度固定（整个方法体），而同步代码块可精确控制锁范围和锁对象，但必须确保所有访问共享变量的路径都走同一把锁——漏掉一个就前功尽弃。

常见坑：用局部变量、new 出的对象或不同引用作为锁，导致实际没锁住；或者在同步块内调用外部可重入方法，引发死锁风险。

• 正确示例：保护共享 map 的读写

  private final Map cache = new HashMap<>();
  private final Object lock = new Object();
  
  public Object get(String key) {
      synchronized(lock) {
          return cache.get(key);
      }
  }
  
  public void put(String key, Object value) {
      synchronized(lock) {
          cache.put(key, value);
      }
  }

• 危险写法：synchronized(new Object()) —— 每次新建对象，根本没锁住任何东西
• 锁对象建议：优先用 final 字段，避免被意外修改或置为 null

不要在synchronized中调用外部可变对象的方法

如果在同步块内调用第三方对象的 toString()、hashCode() 或回调接口，而这些方法内部又尝试获取其他锁，极易触发死锁。JVM 不会帮你检测这种跨锁依赖。

最隐蔽的问题是日志：看似无害的 log.debug("value={}", obj)，若 obj.toString() 耗时或加锁，就会拖慢整个临界区，甚至卡死其他线程。

• 安全做法：在同步块外准备好日志所需字符串，再进块操作数据

  String logMsg = "before update: " + obj.getState(); // 先计算
  synchronized(lock) {
      log.debug(logMsg); // 进块后只做轻量记录
      obj.update();
  }

• 尤其警惕：集合类的 toString() 可能遍历全部元素，若集合本身也被其他同步逻辑保护，就构成锁嵌套
• 调试技巧：线程 dump 中看到 WAITING on java.lang.Object@xxx 且堆栈含 toString 或 format，基本可定位到这类问题

同步不是银弹。真正难的不是加 synchronized，而是判断“到底该锁什么”“锁多久”“谁和谁必须串行”。很多并发 bug 表现在业务逻辑层，根源却在锁对象的选择和临界区边界划定上。