说实话，看到有些 Java 代码中，开发者明明只是要对集合里每个对象的某个深层字段调用一个方法，却非要在中间搭建一座 Map 的桥梁——先构建一个 Map，然后再遍历这个 Map 去执行操作。每次遇到这种情况，都让人不禁思考：这步中间操作，真的有必要吗？
先给出结论：直接访问嵌套字段（比如 a.c.b.doSomething()），时间复杂度为 O(n)，且没有额外的内存开销；相比之下，先构建 Map 再遍历的方案，额外增加了哈希表初始化、键值插入以及二次迭代的消耗。简而言之，这是典型的“徒劳无功”操作。
如果你只是需要对每个 A 实例中那个嵌套的 B 对象执行一次操作，最简洁高效的写法就是“直达目标”：
for (A a : x) { a.c.b.dosomeoperation();}
这段代码逻辑清晰，执行路径最短。它不需要新建 HashMap 实例，无需计算哈希值，无需维护链表或红黑树，更不需要绕一圈二次遍历。JVM 看到这种直接调用的模式，还可能自动进行优化（例如循环展开或内联），然而如果使用 Map 版本，则不可避免地触发堆内存分配、扩容判断以及 hashCode() 和 equals() 的反复调用——这一系列操作下来，小数据量下或许不明显，但一旦数据量增加，性能差距会变得非常显著。
另一方面，如果你更看重代码的表达能力，也可以借助 Stream API 来编写，尤其是当需要组合多个操作时，它的可读性确实更胜一筹：
Arrays.stream(x) .forEach(a -> a.c.b.dosomeoperation());
不过需要注意的是，Stream 本身也会带来轻微的性能开销，因此它更适合注重代码可读性、而非极致性能的场景。取舍之道，就在于此。
再说几个细节：
- 避免为“关联”而创建 Map——
a.c.b这个链式调用本身就已经是天然且强类型的关联了。你硬要创建一个Map，它既没有帮你实现去重，也没有提供查找或缓存的价值，完全是多此一举。 - 警惕过早抽象——如果将来确实需要按 B 分组、统计或反查 A，那时再引入合适的数据结构（例如
Map或ConcurrentHashMap），而不是现在提前“埋下隐患”。 - 性能敏感的场合务必进行测试——推荐使用 JMH 进行微基准测试。一般情况下，在千级以下的数据规模里，Map 方案会比直接访问慢 2 至 5 倍；到了万级以上，差距更为显著——不仅执行时间拉长，垃圾回收（GC）压力也会随之上升。
综上所述：性能优化的第一原则，是消除不必要的工作。 在这个例子中，“构建 Map → 遍历 Map”这一套流程，就是典型的冗余操作。坚持“只做必要之事”，代码才能更高效、更易维护、也更不容易出错。
