别再用 for 循环傻傻查找了！Map 这把瑞士军刀，你真的会用吗？-CSDN博客

本文链接：https://blog.csdn.net/dongxiaod1/article/details/149009177

😎 别再用 for 循环傻傻查找了！Map 这把瑞士军刀，你真的会用吗？

嘿，各位码农兄弟姐妹们，你们的老朋友我，今天又来分享“压箱底”的干货了！咱们每天都在和代码打交道，但有些基础工具，比如 java.util.Map，你真的发挥出它100%的功力了吗？

今天不讲什么高深莫测的架构，就从一个我亲身经历的“性能灾难”讲起，看看小小的 Map 是如何拯救一个项目，顺便拯救我那快要掉光的头发的。😅

我遇到了什么问题：一个让页面卡到崩溃的用户列表

那是一个阳光明媚的下午，我接手了一个社交功能的开发。需求很简单：在一个信息流页面，展示帖子的内容、评论、点赞。而每一个发帖人、评论人、点赞人的旁边，都需要显示他们的昵称和头像。

我当时还是个愣头青，心想这不简单嘛！于是，我大笔一挥，写下了自以为“天衣无缝”的逻辑：

从数据库里一次性加载出所有可能用到的用户信息，存到一个 List<User> 里。
写一个 findUserById(long userId) 的方法，里面就是一个 for 循环，遍历这个 List，找到匹配的 User 对象并返回。
在渲染页面每一个需要展示用户信息的地方，都调用一下这个方法。

在我的开发环境里，用户就10来个，页面“嗖”一下就打开了，我甚至还有点小得意。😎

然而，灾难在我把代码提交到测试环境后爆发了。测试环境有10000个用户，一个页面上可能有50个帖子、几百个评论和点赞。结果就是… 页面加载时间超过了10秒，浏览器直接卡死，风火轮转个不停！

我的导师拍了拍我的肩膀，指着性能分析器上一片红色的 findUserById 方法，平静地说：“你知道你这个循环，在页面渲染完之前，执行了多少次吗？”

我瞬间脸红到了脖子根。我正在用一种 O(N) 的复杂度，去解决一个本该是 O(1) 的问题。每次查找，都要把上万个用户从头到尾扫一遍，这不崩谁崩？

我是如何用[Map]解决的：从“大海捞针”到“按号取件”

就在我对着那片红色的性能火焰山发呆时，我突然“恍然大悟”了。

我的核心需求是什么？是“根据一个唯一的用户ID，找到对应的用户信息”。这不就是生活中的“按手机号找联系人”、“按身份证号查户籍”吗？谁会去翻遍全国人口花名册来找一个人呢？大家都是直接用唯一的编号去定位！

在Java的世界里，这个“按号取件”的超级柜子，就是 Map！

Map 的本质就是一个查找表（或叫字典、关联数组）。它把你要查找的条件作为 key（比如用户ID），把你要找的结果作为 value（比如用户对象 User）。

第一刀：`put()` & `get()`，性能起飞！

我立刻动手改造。

第一步：建柜子 (put)
我不再把用户信息傻傻地塞进 List。而是在程序启动时，一次性加载完数据后，遍历这个列表，把它们全都“存”进一个 HashMap 里。HashMap 是 Map 最常用的实现，以查询速度快而著称。

// 从 List<User> 迁移到 Map<Long, User>
Map<Long, User> userCache = new HashMap<>();

// 遍历一次从数据库拿到的用户列表
for (User user : userListFromDB) {
    // 使用 user.getId() 作为 Key, user 对象作为 Value
    userCache.put(user.getId(), user); 
}

put(K key, V value) 方法就像是快递员把包裹放进储物柜，key 是取件码，value 就是你的包裹。

第二步：取快递 (get)
然后，我把我那个罪恶的 findUserById 方法，替换成了一行代码：

// 之前：几行代码的 for 循环...
// 现在：一行搞定！
User user = userCache.get(userId);

get(Object key) 方法就像你输入取件码，柜门“啪”地一下就开了，快得不可思议！

改完之后，我重新部署。奇迹发生了！页面加载时间从 10秒 变成了 100毫秒！那种流畅感，简直让人热泪盈眶。😭

踩坑经验分享：小心那个叫 `NullPointerException` 的刺客！

正当我得意洋洋时，测试又提了个Bug：偶尔页面会白屏，后台日志里充满了 NullPointerException！

我马上定位到问题。如果因为某些原因（比如用户被删了），传入了一个无效的 userId，那么 userCache.get(invalidId) 会返回什么？null！

而我的代码拿到 null 之后，还傻乎乎地去调用 user.getNickname()，不抛异常才怪！

💡恍然大悟的瞬间：
Map 只承诺了高效，没承诺过你要找的东西一定在！作为开发者，我们必须自己处理“查无此人”的情况。

正确姿势：

// 姿势一：先判断再取，绝对安全
if (userCache.containsKey(userId)) {
    User user = userCache.get(userId);
    // ...安全地使用 user 对象
} else {
    // ...处理用户不存在的情况，比如显示默认头像和昵称
}

// 姿势二：取出来之后判断
User user = userCache.get(userId);
if (user != null) {
    // ...安全地使用 user 对象
} else {
    // ...处理用户不存在的情况
}

containsKey(Object key) 就是在开柜门前先看看这个号码的柜子到底存不存在，非常有用！

第二刀：遍历 `Map`，`keySet` vs `entrySet`

没过多久，产品经理又提了个新需求：“加个后台管理页面，要列出所有当前在线（在缓存里）的用户列表。”

小菜一碟！我需要遍历整个 Map。

我的第一反应是使用 keySet()，它能返回一个包含所有 key 的 Set 集合。

// 最初的写法 (有点傻)
Set<Long> userIds = userCache.keySet();
for (Long id : userIds) {
    User user = userCache.get(id); // 咦，这里好像又 get 了一下？
    System.out.println("用户ID: " + id + ", 昵称: " + user.getNickname());
}

代码跑起来没问题，但我的导师又一次出现在我身后，幽幽地说：“你先通过 keySet 拿到了所有储物柜的号码，然后又拿着每个号码，一个个重新去打开柜子…不累吗？”

💡恍然大悟的瞬间#2：
我犯了一个典型的“二次查找”错误！keySet() 遍历方式虽然直观，但在需要同时访问 key 和 value 的场景下，效率并不高。

专业选手的选择：entrySet()
entrySet() 会返回一个包含 Map.Entry 对象的 Set，每个 Entry 对象都同时封装了 key 和 value。

// 推荐的写法
Set<Map.Entry<Long, User>> entries = userCache.entrySet();
for (Map.Entry<Long, User> entry : entries) {
    Long id = entry.getKey();
    User user = entry.getValue();
    System.out.println("用户ID: " + id + ", 昵称: " + user.getNickname());
}

这就好比管理员直接推着一车打开的柜子过来了，你一次性就能拿到号码和包裹，效率高得多！

当然，在Java 8之后，我们有了更优雅的 forEach + Lambda表达式：

// 最现代、最简洁的写法
userCache.forEach((id, user) -> {
    System.out.println("用户ID: " + id + ", 昵称: " + user.getNickname());
});

举一反三，Map 的舞台无处不在

掌握了 Map 的精髓后，你会发现它能解决生活中的无数问题：

购物车管理：Map<String, Integer>，key 是商品ID，value 是数量。添加商品就是 put，修改数量还是 put（会覆盖），删除就是 remove。完美！
统计词频：给你一篇文章，统计每个单词出现的次数。Map<String, Integer>，key 是单词，value 是出现次数。遍历文章，遇到一个单词，就去 map 里把它对应的 value 加一。
配置中心：系统配置项 Map<String, String>，key 是配置名如 “database.url”，value 就是配置值。查找配置一步到位。