多租户系统中synchronized必须按租户隔离锁对象，避免共用this或class锁导致跨租户阻塞；应使用ConcurrentHashMap以tenantId为key管理专属锁，同步块仅包裹租户级内存操作，禁用static synchronized方法。
synchronized 在多租户系统中对共享内存数据加锁，本质仍是“锁对象”，不是锁代码、也不是锁数据本身。关键在于：**必须确保不同租户的操作不会误用同一把锁，否则会引发租户间相互阻塞；同时又要防止同一租户内并发操作导致数据错乱**。这要求开发者主动设计锁粒度与锁对象归属，jvm 不会自动识别“租户上下文”。
锁对象必须按租户隔离
多租户场景下，若所有租户共用一个实例或同一个锁对象（如 synchronized(this) 或 synchronized(SomeUtil.class)），就会造成跨租户串行化——A 租户的慢操作会拖住 B 租户的请求，严重损害响应性与资源利用率。
- 推荐做法：为每个租户分配独立的锁对象，例如使用租户 ID 作为 key 构建 ConcurrentHashMap 存储租户专属锁
- 示例：private static final Map<String, Object> tenantLocks = new ConcurrentHashMap<>();
获取锁时：Object lock = tenantLocks.computeIfAbsent(tenantId, k -> new Object());
synchronized (lock) { /* 处理该租户的数据 */ } - 避免直接锁 this 或锁 class —— 它们天然不具备租户维度区分能力
同步范围应精准控制在租户数据边界内
即使锁对象已按租户隔离，若同步块包裹了非租户专属逻辑（如日志打印、HTTP 调用、跨租户缓存更新），仍会引入不必要等待和潜在死锁风险。
- 只将真正读写该租户内存数据（如租户级缓存 Map、本地计数器、状态标志位）的代码放入 synchronized 块
- 避免在同步块中执行 I/O、远程调用、长耗时计算；可先在锁外准备参数，锁内仅做原子更新
- 例如更新租户配额：int newQuota = currentQuota - usage;
synchronized (tenantLock) { tenantCache.put(tenantId, newQuota); }
注意静态方法与类锁的全局性陷阱
static synchronized 方法使用的锁是当前类的 Class 对象，对所有租户完全共享。在多租户系统中，除非明确需要全局互斥（如初始化配置、刷新全局限流规则），否则应禁用此类用法。
- 错误示例：public static synchronized void updateGlobalConfig() { ... } —— 所有租户请求都会排队
- 正确替代：改用租户粒度锁 + 显式对象（如上面的 tenantLock），或使用 ReentrantLock 配合 Condition 实现更灵活的等待通知
- 若确需全局控制，建议用专门的协调机制（如分布式锁、ZooKeeper 临时节点），而非依赖 JVM 级类锁
可重入性对租户内嵌套调用是安全的
同一租户线程在持有其专属锁期间，再次进入该锁保护的代码（如同步方法调用另一个同步方法），不会被阻塞。这是 synchronized 的可重入特性保障的，无需额外规避。
立即学习“Java免费学习笔记（深入）”；
- 前提是锁对象一致：两次 synchronized 都作用于同一个 tenantLock 实例
- 不可重入的典型误用：混用 synchronized(this) 和 synchronized(tenantLock)，导致锁对象不统一
- 调试时可通过 Thread.holdsLock(lock) 判断当前线程是否已持有指定锁
