java.util.Map values()方法性能疑问：百万级HashMap调用是否每次创建新集合？

嘿，这个问题问到点子上了——当你处理百万级元素的Map时，这类底层性能细节确实值得抠一抠！

直接给结论：每次调用HashMap.values()时，并不会创建包含所有元素的新集合，而是返回一个轻量的「视图（View）」对象，这个对象本身不存储任何元素，只是对原Map内部数据的一个引用。

具体来说： #

• HashMap的values()方法返回的是它的内部类Values的实例，这个类是Collection的实现，但它并没有自己的元素存储结构。
• 当你遍历这个values集合时，它会直接迭代原HashMap的底层数组（table），相当于实时从原Map中取数据，没有任何元素拷贝的过程。
• 每次调用values()的开销仅仅是创建一个极小的Values对象，内存占用可以忽略不计，完全不用担心百万级元素带来的额外负担。

注意区分两种场景： #

1. 直接使用视图：如果你只是需要遍历values，或者不需要一个和原Map独立的集合，直接用map.values()返回的对象就好，每次调用的成本极低。
2. 需要独立静态集合：如果你需要一个不受原Map修改影响的固定列表，那才需要手动拷贝，比如new ArrayList<>(map.values())——这时候才会真正创建新集合并复制所有元素，这一步才是耗时的，但这是你主动选择的操作，不是values()本身的行为。

举个简单的源码视角佐证（基于OpenJDK的HashMap实现）：

public Collection<V> values() {
    Collection<V> vs = values;
    if (vs == null) {
        vs = new Values();
        values = vs;
    }
    return vs;
}

这里的Values内部类的迭代器直接操作原Map的table数组，没有元素复制逻辑，所以完全不用担心性能问题。

内容的提问来源于stack exchange，提问作者Aliaksei Stadnik