Java 中 synchronized 怎么避免对 String 常量加锁的陷阱-java教程-PHP中文网

应避免用String常量或拼接字符串作synchronized锁，因其受常量池和对象创建机制影响易导致锁失效或过重；推荐用ConcurrentHashMap缓存唯一锁对象，必要时结合分布式锁兜底。

java 中 synchronized 怎么避免对 string 常量加锁的陷阱

Java 中用 synchronized 对 String 常量加锁，表面看能按业务维度（如用户 ID、订单号）做隔离，实际却极易踩坑：要么锁失效（不同线程拿不到同一把锁），要么锁过重（多个无关业务被意外串行）。核心问题不在 synchronized 本身，而在 String 的常量池机制和对象引用语义。避开陷阱的关键是——不依赖字符串内容自动复用，而主动、可控地管理锁对象生命周期。

别用字面量或运行时拼接的 String 当锁

像 synchronized("user_" + userId) 或 synchronized(userId + "") 这类写法，看似按用户隔离，实则危险：

编译期确定的拼接（如 "user_" + "123"）会被优化为字面量 "user_123"，进入常量池 → 多个模块可能无意共用同一锁
运行时拼接（如 "user_" + userId，其中 userId 是变量）大概率生成堆中新 String 对象 → 每次 new 出不同实例，synchronized 形同虚设
String.valueOf()、toString() 等方法返回的也多是新对象，不进常量池

慎用 intern() 强制入池

synchronized(userId + "".intern()) 能让等值字符串指向同一对象，但代价很高：

JDK 7+ 后 intern() 存入堆的老年代，高频调用会快速堆积，触发频繁 Full GC
intern() 方法本身是同步的，高并发下成为新的全局竞争点
不同 ClassLoader 加载的同名字符串，intern() 后仍不等价，跨模块时可能漏锁

推荐用 ConcurrentHashMap 缓存锁对象

这是最常用、平衡性最好的方案：按业务键（如 userId）动态生成唯一锁对象，并复用：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

使用 ConcurrentHashMap.computeIfAbsent(key, k -> new Object())，保证每个 key 对应唯一锁实例
锁对象是轻量级 new Object()，无内存泄漏风险；map 可配合定时清理或弱引用控制大小
示例：Object lock = locks.computeIfAbsent(userId, k -> new Object()); synchronized(lock) { ... }