为什么 HashMap 用 Long 当 key 会变慢？
如果你的项目中有一个高频使用的缓存，键是长整型 ID。你觉得用 HashMap<Long, Object> 还是专门为 long 优化的 Map？对于此问题大家先不要看我下面的内容，想想如果是你的话会怎么回答，这也是一个面试题，面试官常问的问题。
今天我就来深入探讨这个问题，并给出让面试官眼前一亮的答案。
为什么 Long 比 long 慢？
1. 内存开销
我们先看一个直观的例子：
// 测试内存占用
Map<Long, String> map = new HashMap<>();
for (long i = 0; i < 1_000_000; i++) {
map.put(i, "value_" + i);
}
你以为每个键值对只占 8 字节？太天真了！实际上：
- Long 对象头：16 字节（64 位 JVM，开启压缩指针）；
- long 值：8 字节；
- 对齐填充：可能 0-7 字节；
- HashMap.Node 对象：28 字节左右。
这样算下来，每个 Long 键实际占用约 40-50 字节！而如果用原生 long 数组，每个键就 8 字节，相差 5-6 倍！
2. GC 压力
想象一下：一个 1000 万条记录的缓存，使用 Long 作为键会产生 1000 万个 Long 对象，加上 1000 万个 Node 对象。
每次 Young GC 都要扫描这些对象，Full GC 时更是灾难。
// 制造内存压力的代码
public void processBatch(List<Long> ids) {
Map<Long, Result> cache = new HashMap<>();
// 每次调用都创建大量临时 Long 对象
for (Long id : ids) { // 这里已经装箱了一次
Result result = compute(id); // compute 方法可能又装箱
cache.put(id, result); // 可能再装箱
}
}
3. CPU 缓存不友好
现代 CPU 有三级缓存，访问连续内存的速度比随机访问快几十倍。
long[] 数组在内存中是连续的，而 Long[] 或 HashMap 的桶是分散的。
// 连续访问 vs 随机访问
long[] primitiveArray = newlong[1000000];
Long[] objectArray = new Long[1000000];
// 连续访问 - CPU 缓存友好
for (int i = 0; i < primitiveArray.length; i++) {
sum += primitiveArray[i]; // 缓存命中率高
}
// 随机对象访问 - 缓存不友好
for (int i = 0; i < objectArray.length; i++) {
if (objectArray[i] != null) {
sum += objectArray[i]; // 可能频繁缓存未命中
}
}
性能对比
我们用 JMH 做个基准测试：
@BenchmarkMode(Mode.Throughput)
@State(Scope.Thread)
publicclass LongMapBenchmark {
private Map<Long, String> hashMap;
private Long2ObjectOpenHashMap<String> fastUtilMap;
@Setup
public void setup() {
hashMap = new HashMap<>();
fastUtilMap = new Long2ObjectOpenHashMap<>();
for (long i = 0; i < 100000; i++) {
hashMap.put(i, "value");
fastUtilMap.put(i, "value");
}
}
@Benchmark
public String testHashMap() {
return hashMap.get(50000L);
}
@Benchmark
public String testFastUtil() {
return fastUtilMap.get(50000L);
}
}
测试结果：
HashMap<Long, String>：150 万 ops/秒Long2ObjectOpenHashMap<String>：420 万 ops/秒- 性能提升：2.8 倍！
最佳实践
方案一：fastutil – 生产环境首选
// Maven 依赖
// <dependency>
// <groupId>it.unimi.dsi</groupId>
// <artifactId>fastutil</artifactId>
// <version>8.5.12</version>
// </dependency>
import it.unimi.dsi.fastutil.longs.*;
publicclass UserCache {
// 原生 long 作为键，无装箱开销
privatefinal Long2ObjectOpenHashMap<User> cache;
// 线程安全的版本
privatefinal Long2ObjectMap<User> concurrentCache;
public UserCache() {
cache = new Long2ObjectOpenHashMap<>();
// 预分配大小，避免扩容
cache.defaultReturnValue(null);
}
// 批量操作特别高效
public void batchPut(List<User> users) {
for (User user : users) {
cache.put(user.getId(), user); // 没有装箱！
}
}
}
方案二：Eclipse Collections – 功能丰富
import org.eclipse.collections.impl.map.mutable.primitive.*;
public class ProductRepository {
private final LongObjectHashMap<Product> products;
// 丰富的高级 API
public List<Product> findProducts(long[] ids) {
return products.select((id, product) ->
Arrays.binarySearch(ids, id) >= 0
).toList();
}
}
方案三：特定场景优化
场景 1：ID 范围有限
// 如果 ID 在 0-1000 万之间，直接用数组！
publicclass DirectArrayCache {
privatefinal Object[] cache;
privatefinalint offset; // 处理 ID 不从 0 开始的情况
public DirectArrayCache(long minId, long maxId) {
int size = (int)(maxId - minId + 1);
cache = new Object[size];
offset = (int)minId;
}
public void put(long id, Object value) {
cache[(int)id - offset] = value;
}
public Object get(long id) {
return cache[(int)id - offset];
}
}
场景 2：需要并发访问
import com.koloboke.collect.map.LongObjMap;
import com.koloboke.collect.map.hash.HashLongObjMaps;
publicclass ConcurrentLongCache {
// Koloboke 的并发版本性能极佳
privatefinal LongObjMap<String> cache;
public ConcurrentLongCache() {
cache = HashLongObjMaps.newUpdatableMap();
}
// 使用 compute 方法避免竞态条件
public String computeIfAbsent(long key, Function<Long, String> mapper) {
return cache.computeIfAbsent(key, k -> mapper.apply(k));
}
}
面试回答模板：让面试官对你刮目相看
标准回答结构
第一层：基础知识
“用
Long作为HashMap的键主要问题是自动拆装箱带来的性能损耗和内存开销。每次put/get操作都会创建Long对象，对于高频操作会有明显性能影响。”
第二层：深入分析
“但问题其实更复杂。首先，
Long对象本身有 16 字节对象头，加上 8 字节存储 long 值，内存开销很大。其次，大量Long对象会增加 GC 压力，影响应用整体性能。最后，对象在堆上分散存储，破坏了 CPU 缓存局部性原理。”
第三层：解决方案
“在项目中，我一般会根据场景选择方案：如果键范围有限，直接用数组；如果需要高并发，用
ConcurrentHashMap<Long, V>但配合对象池重用Long实例；如果追求极致性能，用 fastutil 的Long2ObjectHashMap。我们之前优化过一个缓存系统，从HashMap<Long, Object>切换到Long2ObjectOpenHashMap，QPS 提升了 180%。”
第四层：实战经验
“实际上，我们还会考虑其他因素：比如键的分布是否连续、是否需要持久化、并发访问模式等。最近我们处理过一个 5000 万条记录的索引，通过使用
long[]数组和二分查找，比HashMap内存减少了 70%，查询速度反而提升了。”
代码示例展示
// 在面试中可以现场写的示例
publicclass OptimizedLongMapExample {
// 方案比较
public void showComparison() {
// 1. 传统方式 - 不推荐
Map<Long, User> traditionalMap = new HashMap<>();
// 2. fastutil 方式 - 推荐
Long2ObjectMap<User> optimizedMap = new Long2ObjectOpenHashMap<>();
// 3. 特殊情况 - 连续 ID 用数组
User[] arrayCache = new User[1000000];
System.out.println("根据场景选择：");
System.out.println("- 小数据量、简单场景：用 HashMap");
System.out.println("- 大数据量、性能敏感：用 fastutil");
System.out.println("- ID 连续、范围已知：用数组");
System.out.println("- 需要丰富 API：用 Eclipse Collections");
}
// 展示对性能优化的理解
public void optimizationTips() {
// 技巧 1：预分配大小
Long2ObjectOpenHashMap<String> map =
new Long2ObjectOpenHashMap<>(1000000, 0.75f);
// 技巧 2：批量操作避免反复装箱
long[] ids = getBatchIds();
Map<Long, String> result = new HashMap<>(ids.length);
for (long id : ids) { // 注意这里用 long，不是 Long
result.put(id, computeValue(id));
}
// 技巧 3：重用 Long 对象（限值范围小的情况）
Long[] cachedLongs = new Long[256];
for (int i = 0; i < cachedLongs.length; i++) {
cachedLongs[i] = (long) i;
}
}
}
面试官可能会追问的问题
问题 1：”那为什么 Java 不直接支持原始类型的泛型？”
高质量回答：
“这是一个历史遗留和设计权衡问题。Java 泛型是通过类型擦除实现的，为了保持向后兼容。不过 Java 8 引入的
StreamAPI 和Optional对原始类型的支持，以及 Valhalla 项目正在研究的 value types，都是在解决这个问题。目前我们可以用第三方库来弥补这个缺陷。”
问题 2：”除了 Long，其他原始类型也有类似问题吗？”
高质量回答：
“是的，所有原始类型都有对应的包装类，都有类似问题。但影响程度不同：
Integer因为有缓存池（-128 到 127），小范围内会好些；Double和Float由于浮点数比较的特殊性，用作 Map 键本身就不常见。实际项目中，我们遇到最多的是Long和Integer的性能问题。”
问题 3：”那我们应该避免使用包装类吗？”
高质量回答：
“不是的，这要看场景。包装类在集合框架、泛型、序列化等方面是必需的。关键是选择合适的工具：高频访问的核心数据结构用专门优化的集合，业务逻辑层可以继续用包装类。就像我们的架构：底层存储用
long[]，服务层用Long2ObjectMap，API 层用Map<Long, Object>。”
回到开头的面试问题，现在你可以自信地回答：“根据我们的压测，用专门优化的 Map 比 HashMap<Long, V> 性能提升 2-3 倍，内存减少 50-70%。具体选择哪种方案，需要根据数据规模、访问模式和硬件环境来决定。”
个人博客
以上关于为什么 HashMap 用 Long 当 key 会变慢？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。
微信
支付宝如若内容造成侵权/违法违规/事实不符，请将相关资料发送至 admin@mybj123.com 进行投诉反馈，一经查实，立即处理！
重要：如软件存在付费、会员、充值等，均属软件开发者或所属公司行为，与本站无关，网友需自行判断
码云笔记 » 为什么 HashMap 用 Long 当 key 会变慢？
