WeakHashMap线程安全吗：深入解析与并发场景下的替代方案
WeakHashMap本身不是线程安全的。这意味着如果多个线程同时访问一个WeakHashMap实例，并且至少有一个线程在结构上修改了该映射（即添加或删除一个或多个键值对），那么必须在外部进行同步。否则，可能导致数据不一致、状态损坏或程序异常。
要理解其线程不安全的根源，需要先了解WeakHashMap的核心机制。WeakHashMap的键是“弱键”（WeakReference）。其特殊之处在于，当某个键对象除了被WeakHashMap的弱引用持有外，不再被任何其他强引用指向时，垃圾回收器会在下一次回收时自动清除该弱引用，并使得对应的条目成为可被回收的状态。随后，WeakHashMap内部会通过定期或不定期的清理过程（例如在对map进行操作时），自动移除这些无效的条目。
这个自动清理机制在单线程环境下非常优雅，但在多线程环境下则引入了复杂性。WeakHashMap的内部实现（如条目链表的管理、哈希表的重组、以及弱引用队列的轮询）并未使用同步控制来保证原子性和可见性。如果多个线程同时进行put、remove或遍历等操作，可能会遇到以下典型问题：
1. 在扩容或重组哈希表时，一个线程可能读取到处于中间不一致状态的内部结构。
2. 两个线程同时尝试插入键哈希值相同的元素，可能导致链表结构损坏。
3. 一个线程在遍历，另一个线程进行结构性修改，可能抛出ConcurrentModificationException。
4. 弱引用被GC回收和后台清理的时机不确定，线程可能读取到本应被清除的过期数据，或者看到不一致的size()结果。
如果需要在多线程环境中使用类似WeakHashMap的功能，有几种常见的解决方案：
第一种是使用外部同步。可以使用Collections.synchronizedMap方法包装WeakHashMap，得到一个线程安全的包装器对象。对该包装器的所有访问都必须通过其内置的锁进行同步，这确保了线程安全，但会带来较高的性能开销，并且在复杂的复合操作（如“若没有则添加”）中，仍需客户端进行额外的加锁。
第二种是考虑使用ConcurrentHashMap。虽然ConcurrentHashMap的键不是弱引用，但其提供了卓越的并发性能。如果弱引用的特性不是必须的，那么ConcurrentHashMap是处理并发映射的首选。它通过分段锁或CAS操作实现高并发，避免了全局锁的开销。
第三种是针对特定场景的并发弱键映射。在Java并发包中，并没有直接提供线程安全的WeakHashMap实现。但可以通过组合现有的并发容器和引用队列来构建。例如，可以使用ConcurrentHashMap与WeakReference及ReferenceQueue结合，自行实现一个线程安全的、具有弱键行为的映射结构。这需要处理弱引用入队后的清理逻辑，并确保清理操作是线程安全的。此外，一些第三方库（如Google Guava）提供了类似ConcurrentWeakKeyHashMap的实现，可以作为参考或直接使用。
总结来说，WeakHashMap设计用于需要由垃圾回收器自动清理键值对的特定场景，但其本身并非为并发设计。在多线程编程中，直接使用它而不加同步是危险的。开发者应根据实际需求，权衡是否需要弱引用特性，从而选择外部同步、转向完全并发的ConcurrentHashMap，或寻找、构建更复杂的并发弱引用容器方案。理解其线程不安全性的原理，是做出正确技术选型的基础。