使用synchronized(map)控制同步是否有效？GC是否影响线程互斥？

一、GC发生时，synchronized(localMap)是否仍能保证同一时间仅一个线程执行？ #

是的，只要localMap对象还未被GC回收，synchronized锁就能正常工作，保证同一时间只有一个线程进入同步代码块。

• synchronized锁的是对象实例本身，而非对象的引用或哈希值。只要这个对象还存活（比如当前线程的localMap变量还持有引用、instanceMap中仍保留它的引用），GC就不会回收它，锁的有效性不受GC影响。
• 如果localMap已经被GC回收，说明没有任何线程持有它的引用了，自然也不会有线程再尝试对它加锁，不存在多线程竞争的场景。

二、GC完成后map的哈希值变化的原因 #

GC本身不会修改对象的哈希值。你观察到的哈希值变化和GC无关，大概率是因为map内部元素发生了变更：

• 像HashMap、ConcurrentHashMap这类Map实现类，都重写了hashCode()方法，哈希值是基于Map中所有键值对的哈希值计算得出的。当你在同步块中执行清理map的代码时，map内的元素被移除，哈希值自然会发生变化。
• 如果是未重写hashCode()的对象，哈希值默认基于对象内存地址生成，GC移动对象（比如分代回收时的对象复制）也不会改变哈希值——JVM保证对象的哈希值在整个生命周期内是固定的。

三、代码中“同一键多次进入同步代码块”的原因分析 #

从代码来看，主要问题出在锁对象的一致性上：

1. instanceMap的修改未被同步：虽然instanceMap是ConcurrentHashMap，get和put操作本身线程安全，但如果有线程在你调用instanceMap.get(key)之后，将该key对应的localMap替换成了新的Map对象，后续线程拿到的就是新的Map实例。不同的Map实例是不同的锁对象，多个线程可以同时进入各自的同步块，导致同一键的日志被多次打印。
2. 逻辑可能存在错误：代码中localMap.containsKey(key)的判断逻辑存疑——localMap是从instanceMap.get(key)获取的，这里的key是instanceMap的键，你却用它去判断localMap中是否包含该键，若判断条件不严谨，也可能导致多次进入同步块。

修复建议 #

• 确保锁对象的唯一性：如果要对某个key对应的操作加锁，建议以instanceMap中的key本身作为锁对象（注意使用字符串常量池中的对象，避免创建新的String实例），或者使用专门的锁集合管理每个key对应的锁。
• 同步instanceMap的读写操作：如果有线程会替换instanceMap中的localMap，需要在替换操作时也进行同步，避免出现“get到旧对象，同时其他线程替换成新对象”的情况。
• 增加空指针检查：在localMap上调用方法前，先判断localMap != null，避免空指针异常。

内容的提问来源于stack exchange，提问作者flower