Apache Fury项目中WeakHashMap并发访问导致的线程挂起问题深度解析

背景概述

在Apache Fury（一个高性能序列化框架）的开发过程中，开发团队发现了一个涉及Java集合框架的严重并发问题。当框架在生成序列化器代码时，特定场景下会出现线程永久挂起的现象。通过分析线程堆栈，发现问题根源在于WeakHashMap.get()方法的并发访问冲突。

问题本质

WeakHashMap作为Java集合框架中一个特殊的Map实现，其键使用弱引用（WeakReference）实现。与常规HashMap不同，JDK 8之后HashMap通过树化改造和新的扩容算法解决了经典的并发问题，但WeakHashMap的核心实现却保持了旧有的链表结构设计。

技术原理分析

WeakHashMap的底层实现机制

在JDK 11的实现中，WeakHashMap仍然采用数组+链表的经典结构。其扩容时的关键方法transfer()保持着与JDK 7时代HashMap相似的实现：

private void transfer(Entry<K,V>[] src, Entry<K,V>[] dest) {
    for (int j = 0; j < src.length; ++j) {
        Entry<K,V> e = src[j];
        src[j] = null;
        while (e != null) {
            Entry<K,V> next = e.next;  // 关键点1：暂存next引用
            int i = indexFor(e.hash, dest.length);
            e.next = dest[i];        // 关键点2：建立新链接
            dest[i] = e;             // 关键点3：更新桶头节点
            e = next;                // 关键点4：处理下一个节点
        }
    }
}

并发场景下的问题复现

当多个线程同时操作WeakHashMap时，典型的死锁场景如下：

1. 初始状态：某桶中存在链表 A→B→null
2. 线程1执行扩容：
   • 读取e=A，next=B后被挂起
3. 线程2完成完整扩容：
   • 将链表反转为 B→A→null
4. 线程1恢复执行：
   • 将A插入新桶（A.next=null）
   • 接着处理B时，由于线程2的修改，B.next实际指向A
   • 最终形成环形链表 B→A→B...

此时任何对该桶的查询操作都会陷入无限循环，导致线程永久挂起。

问题影响范围

该问题具有以下特征：

• 影响所有JDK版本（包括最新的JDK 11）
• 仅在并发修改时触发（读-写并发或写-写并发）
• 在Apache Fury中表现为序列化代码生成时的线程阻塞

解决方案建议

短期解决方案

1. 使用同步包装：

Map<K,V> safeMap = Collections.synchronizedMap(new WeakHashMap<>());

2. 改用并发容器：

Map<K,V> safeMap = new ConcurrentHashMap<>();

长期架构建议

1. 审查所有使用WeakHashMap的场景
2. 建立并发使用规范：
   • 明确集合的线程安全策略
   • 对共享集合强制使用线程安全实现
3. 考虑替代方案：
   • 对于缓存场景，可使用Guava Cache等专业实现
   • 对于弱引用管理，可考虑WeakReference与ConcurrentHashMap的组合

经验总结

这个案例给我们带来三点重要启示：

1. API契约的重要性：虽然WeakHashMap不是线程安全的，但它的行为文档中并未明确说明可能产生死循环这种极端情况

2. 集合选择的谨慎性：在性能敏感的基础组件中，集合类型的选择需要同时考虑功能需求和并发特性

3. 测试的全面性：并发问题往往在特定条件下才会显现，需要加强并发场景的专项测试

通过这个问题的分析，我们不仅解决了Apache Fury的具体缺陷，更重要的是建立了对Java集合框架更深层次的理解，为后续开发高质量的基础组件积累了宝贵经验。