synchronized块禁用String或Integer作锁对象，因其常量池复用导致意外锁竞争；volatile不能替代synchronized实现i++原子性；ConcurrentHashMap的size()不精确；ReentrantLock tryLock超时以系统实时时间为准。
为什么 synchronized 块里不能用 String 或 Integer 作锁对象
因为 String、Integer 等包装类和字符串字面量存在常量池复用，不同线程看似用了“同一个”锁变量，实际可能指向 JVM 中同一块内存地址，导致意外的锁竞争或死锁。更糟的是，这种问题在线上低概率复现，排查成本极高。
- 永远避免用
new String("lock")以外的字符串字面量（如"lock"）或自动装箱值（如Integer.valueOf(1)）作锁 - 推荐显式创建私有 final 对象：
private final Object lock = new Object();
- 若必须用业务字段作锁，确保该字段是
final且不参与任何外部赋值或反射修改
volatile 能否替代 synchronized 实现计数器自增
不能。 volatile 只保证可见性和禁止指令重排序，但 i++ 是读-改-写三步非原子操作。即使 
volatile int，多线程下仍会丢失更新。
- 正确做法：用
AtomicInteger.incrementAndGet()，它底层基于 CAS + volatile 实现原子性 - 注意
AtomicInteger的getAndIncrement()和incrementAndGet()返回值顺序不同，别混淆语义 - 如果逻辑复杂（比如需在自增前后加校验），
synchronized或ReentrantLock仍是更可控的选择
ConcurrentHashMap 的 size() 方法为什么不准
ConcurrentHashMap 为避免全局锁，在并发扩容和写入时不做精确计数；size() 是对每个分段桶调用 sumCount() 的近似快照，可能漏掉正在迁移的节点或未 flush 的计数器增量。
- 需要精确大小？改用
mappingCount()—— 它返回long类型，语义更明确，且 JDK 8+ 内部实现已比size()更稳定，但仍不承诺强一致性 - 若业务逻辑依赖“绝对数量”，说明设计本身有问题：应转向事件驱动（如监听
put操作）或用单独的原子计数器维护 - 不要在循环条件里用
map.size() > 0判断是否为空，改用map.isEmpty()，它有专门的无锁优化路径
ReentrantLock tryLock(long, TimeUnit) 的超时判断到底以谁为准
以操作系统级的实时时间（wall-clock time）为准，不是 CPU 时间，也不是当前线程被调度的时间。这意味着如果系统时间被手动调整（如 NTP 同步或管理员修改），可能导致 tryLock 提前返回 false 或阻塞远超预期。
- JDK 9+ 引入了
new StampedLock()，其tryOptimisticRead()不依赖系统时钟，适合对时间敏感的乐观读场景 - 生产环境务必关闭系统时间自动跳变（如配置
ntpd -x或使用chrony的 slew 模式） - 测试中模拟超时，不要用
Thread.sleep()配合tryLock(1, TimeUnit.SECONDS)，而应直接用System.nanoTime()控制精度
synchronized 块里修改了某个 volatile 字段，以为能加强同步效果，其实只是多余操作。
