面试官：为什么阿里巴巴要重写HashMap？ConcurrentHashMap哪里不够用？
面试官：为什么阿里巴巴要重写HashMap？ConcurrentHashMap哪里不够用？
面试现场的灵魂拷问
上个月面试阿里云，技术三面时面试官突然抛出了这个问题："你知道为什么我们要重写HashMap吗？JDK的ConcurrentHashMap哪里不够用？"
我当时一脸懵："啊？阿里重写了HashMap？"
面试官笑了："看来你对我们内部的一些技术实践还不够了解。那我换个问题，你在高并发场景下用ConcurrentHashMap遇到过什么问题吗？"
这一问，让我陷入了沉思...
回到现实：生产环境的性能瓶颈
面试回来后，我开始仔细审视项目中ConcurrentHashMap的使用。果然发现了几个让人头疼的问题：
场景1：热点数据访问 我们有个用户画像缓存，存储千万级用户数据：
java
复制代码
// 看似正常的缓存实现
private final ConcurrentHashMap
new ConcurrentHashMap<>(10_000_000);
public UserProfile getUserProfile(String userId) {
return userCache.computeIfAbsent(userId, this::loadFromDB);
}
问题来了：热点用户的访问会导致hash冲突严重，某些bucket的链表长度能达到上百个节点！
踩坑瞬间：内存碎片化的噩梦
更要命的是内存问题。我们用JProfiler分析发现：
java
复制代码
// 看似无害的配置更新
private final ConcurrentHashMap
new ConcurrentHashMap<>();
public void updateConfig(String key, String value) {
configMap.put(key, value); // 看起来很正常
}
问题爆发：
初始容量16，负载因子0.75
随着配置增多，频繁扩容
每次扩容都要重新hash所有元素
老年代碎片化严重，Full GC频繁
监控数据显示：配置热更新时，GC停顿时间从50ms飙升到2秒！
探索之路：阿里的解决方案
带着疑问，我开始研究阿里的开源项目，发现了几个有趣的优化：
1. 分段锁的进化版
java
复制代码
// 类似阿里内部的分段策略
public class SegmentedHashMap
private final Segment
private final int segmentMask;
public V put(K key, V value) {
int hash = hash(key);
int segIndex = (hash >>> 28) & segmentMask;
return segments[segIndex].put(key, value, hash);
}
// 每个segment独立扩容，避免全局锁
static class Segment
private volatile HashEntry
// ...
}
}
2. 内存预分配策略
java
复制代码
// 根据业务特点预估容量
public class PreSizedConcurrentMap
public PreSizedConcurrentMap(int expectedSize, float loadFactor) {
// 计算合适的初始容量，避免扩容
super(calculateInitialCapacity(expectedSize, loadFactor), loadFactor);
}
private static int calculateInitialCapacity(int expected, float lf) {
return (int) Math.ceil(expected / lf);
}
}
转折点：发现真正的痛点
深入研究后，我发现阿里重写HashMap主要解决这些问题：
核心痛点对比：
问题
JDK ConcurrentHashMap
阿里优化方案
扩容成本
全量rehash
渐进式扩容
内存开销
固定Node结构
紧凑型存储
热点访问
hash冲突严重
一致性hash
GC压力
频繁对象创建
对象池复用
最关键的优化 - 渐进式扩容：
java
复制代码
public class ProgressiveHashMap
private volatile Table
private volatile Table
private final AtomicInteger migrationIndex = new AtomicInteger(0);
public V get(K key) {
// 先查新表，再查旧表
V value = newTable.get(key);
if (value == null && oldTable != null) {
value = oldTable.get(key);
// 顺便迁移一个bucket
migrateBucket();
}
return value;
}
private void migrateBucket() {
// 每次操作迁移少量数据，分摊扩容成本
// ...
}
}
经验启示：业务驱动的技术选型
这次研究让我明白，技术选型必须结合具体业务场景：
阿里的业务特点：
超大规模：单机存储亿级数据
高并发：双11期间QPS百万级
低延迟：99.9%请求要求<10ms
高可用：不能因为扩容影响服务
JDK ConcurrentHashMap的局限：
扩容时全量rehash，影响响应时间
内存布局不够紧凑，浪费空间
分段锁粒度不够细，高并发下仍有瓶颈
实战应用：渐进式优化策略
受到启发，我们也对项目进行了渐进式优化：
java
复制代码
// 优化前：简单粗暴的缓存
private final Map
// 优化后：分层缓存 + 预分配
public class OptimizedCache
private final Map
private final Map
public OptimizedCache(int hotSize, int coldSize) {
// 根据访问模式预分配容量
this.hotData = new ConcurrentHashMap<>(hotSize, 0.9f);
this.coldData = new ConcurrentHashMap<>(coldSize, 0.75f);
}
public V get(K key) {
V value = hotData.get(key);
if (value != null) return value;
value = coldData.get(key);
if (value != null) {
// 热点数据提升策略
promoteToHot(key, value);
}
return value;
}
}
优化效果：
P99延迟从120ms降到15ms
内存使用减少30%
GC停顿时间减少80%
总结：技术演进的必然性
现在我明白了面试官那个问题的深意：没有完美的数据结构，只有适合业务场景的最优解。
阿里重写HashMap不是为了炫技，而是因为：
业务规模超出了通用组件的设计预期
性能要求需要极致优化
成本控制要求更高的资源利用率
关键启示：
通用组件往往是80%场景的最优解
20%的极端场景需要定制化方案
技术选型要考虑业务发展阶段
那次面试虽然没过，但让我学会了从业务视角思考技术问题。现在再有人问我类似问题，我会先反问："你们的业务场景和性能要求是什么？"然后基于具体需求来讨论技术方案。
毕竟，脱离业务谈技术，就是耍流氓。 本文转自渣哥zha-ge.cn