blocks|key|3183473|text|第二个代码片段会稍微快一些，因为它不需要重新查找键。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3183474|所有HashMap迭代器都调用nextEntry+method，后者返回一个Entry<K,V>。|offset|length|style|CODE|3183475|第一个代码片段丢弃条目中的值(在KeyIterator中)，然后再次在字典中查找它。|3183476|您的第二个代码片段直接使用键和值(来自EntryIterator)|3183477|(+keySet()和entrySet()都是廉价的调用)|3183478|entityMap|0|LINK|mutability|MUTABLE|url|http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.HashIterator.nextEntry%2528%2529|1|http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.KeyIterator|2|http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.EntryIterator|3|http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.keySet%2528%2529|4|http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.entrySet%2528%2529^0|0|2|7|F|9|12|A|F|G|0|0|G|B|G|B|1|0|J|D|J|D|2|0|2|8|B|A|2|8|3|B|A|4|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@$D|15|E|16|F|G]|$D|17|E|18|F|G]|$D|19|E|1A|F|G]]|9|@$D|1B|E|1C|1|1D]]|A|$]]|$1|H|3|I|5|6|7|1E|8|@$D|1F|E|1G|F|G]]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|J|3|K|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@$D|1N|E|1O|1|1P]]|A|$]]|$1|L|3|M|5|6|7|1Q|8|@$D|1R|E|1S|F|G]|$D|1T|E|1U|F|G]]|9|@$D|1V|E|1W|1|1X]|$D|1Y|E|1Z|1|20]]|A|$]]|$1|N|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]|X|$5|Q|R|S|A|$T|Y]]|Z|$5|Q|R|S|A|$T|10]]|11|$5|Q|R|S|A|$T|12]]]]

The second snippet will be slightly faster, since it doesn't need to re-look-up the keys.

All <code>HashMap</code> iterators call the <a href="http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.HashIterator.nextEntry%28%29" rel="noreferrer"><code>nextEntry</code> method</a>, which returns an <code>Entry&lt;K,V&gt;</code>. 

Your first snippet discards the value from the entry (in <a href="http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.KeyIterator" rel="noreferrer"><code>KeyIterator</code></a>), then looks it up again in the dictionary.

Your second snippet uses the key and value directly (from <a href="http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.EntryIterator" rel="noreferrer"><code>EntryIterator</code></a>)

(Both <a href="http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.keySet%28%29" rel="noreferrer"><code>keySet()</code></a> and <a href="http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.entrySet%28%29" rel="noreferrer"><code>entrySet()</code></a> are cheap calls)

blocks|key|270321|text|后者比前者更有效率。像FindBugs这样的工具实际上会标记前者，并建议您执行后者。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|270322|entityMap|0|LINK|mutability|MUTABLE|url|http://findbugs.sourceforge.net/^0|B|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

The latter is more efficient than the former. A tool like <a href="http://findbugs.sourceforge.net/" rel="noreferrer">FindBugs</a> will actually flag the former and suggest you to do the latter.

blocks|key|3183519|text|布吉兹，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3183520|我认为(我不知道)迭代EntrySet+(备选方案2)稍微更有效率，因为它不会为了得到它的值而散列每个键……话虽如此，计算散列是每个条目的O(1)操作，因此我们只讨论整个HashMap的O(n)操作……但请注意，所有这些都只适用于HashMap+...Map的其他实现可能具有非常不同的性能特征。|offset|length|style|CODE|3183521|我确实认为你是在“推动它”才能真正注意到性能上的差异。如果你关心，为什么不设置一个测试用例来对两种迭代技术进行计时呢？|3183522|如果你没有真正的，报告的性能问题，那么你真的很担心不是很……这里和那里的时钟滴答不会影响你的程序的整体可用性。|3183523|我相信代码的许多其他方面通常比直接的性能更重要。当然，有些块是“性能关键”的，甚至在编写之前就已经知道了，更不用说性能测试了……但这样的情况相当罕见。一般来说，最好是专注于编写完整、正确、灵活、可测试、可重用、可读、可维护的代码……性能可以在以后需要时构建。|3183524|版本0应该尽可能简单，没有任何“优化”。|3183525|entityMap^0|0|2D|7|37|7|3I|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]|$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|Q|$]]

bguiz,

I think (I don't know) that iterating the EntrySet (alternative 2) is marginally more efficient, simply because it doesn't hash each key in order to get it's value... Having said that, calculating the hash is an O(1) operation per entry, and therefore we're ONLY talking O(n) over the whole <code>HashMap</code>... but note that all this applies to <code>HashMap</code> only... other implementations of <code>Map</code> may have VERY different performance characteristics.

I do think you'd be "pushing it" to actually NOTICE the difference in performance. If you are concerned then why not setup a test-case to time both iteration techniques?

If you don't have a REAL, reported performance issue, then you're really worrying about not very much... A few clock ticks here and there won't affect the overall usability of your program. 

I believe that many, many other aspects of the code are typically more important than outright performance. Of course some blocks are "performance critical", and this is known BEFORE it's even written, let-alone performance tested... but such cases are fairly rare. As a general approach it's better to focus on writing complete, correct, flexible, testable, reusable, readable, maintainable code... performance CAN be built in later, as need arises. 

Version 0 should be AS SIMPLE AS POSSIBLE, without any "optimizations".

blocks|key|270344|text|第二个选项肯定更有效率，因为与第一个选项中的n次相比，您只需要查找一次。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|270345|但是，没有什么比在你可以的时候尝试更好的了。所以是这样的-|270346|(不是很完美，但足以在我的机器上验证假设)|270347|public+static+void+main(String+args[])+{

++++Map<String,+Integer>+map+=+new+HashMap<String,+Integer>();
++++//+populate+map

++++int+mapSize+=+500000;
++++int+strLength+=+5;
++++for(int+i=0;i<mapSize;i%2B%2B)
++++++++map.put(RandomStringUtils.random(strLength),+RandomUtils.nextInt());

++++long+start+=+System.currentTimeMillis();
++++//+alt.+#1
++++for+(String+key+:+map.keySet())+{
++++++++Integer+value+=+map.get(key);
++++++++//+use+key+and+value
++++}
++++System.out.println("Alt+#1+took+"%2B(System.currentTimeMillis()-start)%2B"+ms");

++++start+=+System.currentTimeMillis();
++++//+alt.+#2
++++for+(Map.Entry<String,+Integer>+entry+:+map.entrySet())+{
++++++++String+key+=+entry.getKey();
++++++++Integer+value+=+entry.getValue();
++++++++//+use+key+and+value
++++}
++++System.out.println("Alt+#2+took+"%2B(System.currentTimeMillis()-start)%2B"+ms");
}|code-block|syntax|javascript|270348|RESULTS+(一些有趣的)|offset|length|style|BOLD|270349|使用int+mapSize+=+5000;+int+strLength+=+5;|CODE|270350|Alt+#1耗时26毫秒|270351|Alt+#2耗时20毫秒|270352|使用int+mapSize+=+50000;+int+strLength+=+5;|270353|Alt+#1耗时32毫秒|270354|Alt+#2耗时20毫秒|270355|使用int+mapSize+=+50000;+int+strLength+=+50;|270356|Alt+#1耗时22毫秒|270357|Alt+#2耗时21毫秒|270358|使用int+mapSize+=+50000;+int+strLength+=+500;|270359|Alt+#1耗时28毫秒|270360|Alt+#2耗时23毫秒|270361|使用int+mapSize+=+500000;+int+strLength+=+5;|270362|Alt+#1耗时92毫秒|270363|Alt+#2耗时57毫秒|270364|...and等|270365|entityMap^0|0|0|0|0|0|7|0|2|12|0|0|0|2|13|0|0|0|2|14|0|0|0|2|15|0|0|0|2|14|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1R|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1S|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1T|8|@$M|1U|N|1V|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1W|8|@$M|1X|N|1Y|O|S]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|20|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|21|8|@$M|22|N|23|O|S]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|24|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|25|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|26|8|@$M|27|N|28|O|S]]|9|@]|A|$]]|$1|15|3|16|5|6|7|29|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|2A|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2B|8|@$M|2C|N|2D|O|S]]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2G|8|@$M|2H|N|2I|O|S]]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]]|1O|$]]

Your second options is definitely more efficient since you are doing a lookup only once compared to n number of times in the first option.

But, nothing sticks better than trying it out when you can. So here goes -

(Not perfect but good enough to verify assumptions and on my machine anyway)

<pre><code>public static void main(String args[]) {

 Map&lt;String, Integer&gt; map = new HashMap&lt;String, Integer&gt;();
 // populate map

 int mapSize = 500000;
 int strLength = 5;
 for(int i=0;i&lt;mapSize;i++)
 map.put(RandomStringUtils.random(strLength), RandomUtils.nextInt());

 long start = System.currentTimeMillis();
 // alt. #1
 for (String key : map.keySet()) {
 Integer value = map.get(key);
 // use key and value
 }
 System.out.println("Alt #1 took "+(System.currentTimeMillis()-start)+" ms");

 start = System.currentTimeMillis();
 // alt. #2
 for (Map.Entry&lt;String, Integer&gt; entry : map.entrySet()) {
 String key = entry.getKey();
 Integer value = entry.getValue();
 // use key and value
 }
 System.out.println("Alt #2 took "+(System.currentTimeMillis()-start)+" ms");
}
</code></pre>

RESULTS (Some interesting ones)

With <code>int mapSize = 5000; int strLength = 5;</code> 
Alt #1 took 26 ms 
Alt #2 took 20 ms

With <code>int mapSize = 50000; int strLength = 5;</code> 
Alt #1 took 32 ms 
Alt #2 took 20 ms

With <code>int mapSize = 50000; int strLength = 50;</code> 
Alt #1 took 22 ms 
Alt #2 took 21 ms

With <code>int mapSize = 50000; int strLength = 500;</code> 
Alt #1 took 28 ms 
Alt #2 took 23 ms

With <code>int mapSize = 500000; int strLength = 5;</code> 
Alt #1 took 92 ms 
Alt #2 took 57 ms

...and so on

blocks|key|268352|text|一般来说，对于HashMap来说，第二个会更快一些。只有当你有很多哈希冲突时，这才是真正重要的，因为那时get(key)调用比O(1)慢-它得到O(k)，k是同一存储桶中条目的数量(即，具有相同哈希码或不同哈希码的键的数量仍然映射到相同的存储桶-这也取决于映射的容量、大小和加载因子)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|268353|条目迭代变量不需要执行查找，因此它在这里会更快一些。|268354|另一个注意事项:如果您的地图的容量比实际大小大得多，并且您经常使用迭代，那么您可以考虑使用LinkedHashMap。它为一个完整的迭代提供了O(size)而不是O(size%2Bcapacity)复杂度(以及一个可预测的迭代顺序)。(您仍然应该衡量这是否真的带来了改进，因为因素可能会有所不同。LinkedHashMap在创建地图方面有更大的开销。)|268355|entityMap^0|1G|8|1R|4|20|4|25|1|0|0|1Z|7|29|G|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|K|$]]

In general, the second one would be a bit faster for a HashMap. It will only really matter if you have lots of hash collisions, since then the <code>get(key)</code> call gets slower than <code>O(1)</code> - it gets <code>O(k)</code> with <code>k</code> being the number of entries in the same bucket (i.e. the number of keys with same hash code or a different hash code which gets still mapped to the same bucket - this depends on the capacity, size and load factor of the map as well).

The Entry-iterating variant does not have to do the lookup, thus it gets a bit faster here.

Another note: If the capacity of your map is a lot bigger than the actual size and you use iterations a lot, you might consider using LinkedHashMap instead. It provides <code>O(size)</code> instead <code>O(size+capacity)</code> complexity for a complete iteration (as well as a predictable iteration order). (You should still measure if this really gives an improvement, since the factors might vary. LinkedHashMap has a bigger overhead for creating the map.)

blocks|key|3183643|text|映射：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3183644|Map<String,+Integer>+map+=+new+HashMap<String,+Integer>();|offset|length|style|CODE|3183645|除了两个选项之外，还有一个选项。|3183646|1)+keySet()+-如果您只需要使用+keys，请使用它|BOLD|3183647|for+(+String+k+:+map.keySet()+)+{
++++...
}|code-block|syntax|javascript|3183648|2)+entrySet()+-如果您需要同时使用它：keys+&+values|3183649|for+(+Map.Entry<String,+Integer>+entry+:+map.entrySet()+)+{
++++String+k+=+entry.getKey();
++++Integer+v+=+entry.getValue();
++++...
}|3183650|3)+values()+-如果您只需要+values，则可以使用它|3183651|for+(+Integer+v+:+map.values()+)+{
++++...
}|3183652|entityMap^0|0|0|1M|0|0|3|8|M|4|0|0|3|A|Q|D|0|0|3|8|K|6|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@$D|17|E|18|F|L]|$D|19|E|1A|F|L]]|9|@]|A|$]]|$1|M|3|N|5|O|7|1B|8|@]|9|@]|A|$P|Q]]|$1|R|3|S|5|6|7|1C|8|@$D|1D|E|1E|F|L]|$D|1F|E|1G|F|L]]|9|@]|A|$]]|$1|T|3|U|5|O|7|1H|8|@]|9|@]|A|$P|Q]]|$1|V|3|W|5|6|7|1I|8|@$D|1J|E|1K|F|L]|$D|1L|E|1M|F|L]]|9|@]|A|$]]|$1|X|3|Y|5|O|7|1N|8|@]|9|@]|A|$P|Q]]|$1|Z|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|10|$]]

Map:

<code>Map&lt;String, Integer&gt; map = new HashMap&lt;String, Integer&gt;();</code>

Beside the 2 options, there is one more.

1) keySet() - use it if you need to use only the keys

<pre><code>for ( String k : map.keySet() ) {
 ...
}
</code></pre>

2) entrySet() - use it if you need both: keys &amp; values

<pre><code>for ( Map.Entry&lt;String, Integer&gt; entry : map.entrySet() ) {
 String k = entry.getKey();
 Integer v = entry.getValue();
 ...
}
</code></pre>

3) values() - use it if you need only the values

<pre><code>for ( Integer v : map.values() ) {
 ...
}
</code></pre>

blocks|key|270434|text|最有效的方法(根据我的基准测试)是使用Java8或HashMap.entrySet().forEach()中添加的新HashMap.forEach()方法。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|270435|JMH基准：|270436|@Param({"50",+"500",+"5000",+"50000",+"500000"})
int+limit;
HashMap<String,+Integer>+m+=+new+HashMap<>();
public+Test()+{
}
@Setup(Level.Trial)
public+void+setup(){
++++m+=+new+HashMap<>(m);
++++for(int+i+=+0;+i+<+limit;+i%2B%2B){
++++++++m.put(i+%2B+"",+i);
++++}
}
int+i;
@Benchmark
public+int+forEach(Blackhole+b){
++++i+=+0;
++++m.forEach((k,+v)+->+{+i+%2B=+k.length()+%2B+v;+});
++++return+i;
}
@Benchmark
public+int+keys(Blackhole+b){
++++i+=+0;
++++for(String+key+:+m.keySet()){+i+%2B=+key.length()+%2B+m.get(key);+}
++++return+i;
}
@Benchmark
public+int+entries(Blackhole+b){
++++i+=+0;
++++for+(Map.Entry<String,+Integer>+entry+:+m.entrySet()){+i+%2B=+entry.getKey().length()+%2B+entry.getValue();+}
++++return+i;
}
@Benchmark
public+int+keysForEach(Blackhole+b){
++++i+=+0;
++++m.keySet().forEach(key+->+{+i+%2B=+key.length()+%2B+m.get(key);+});
++++return+i;
}
@Benchmark
public+int+entriesForEach(Blackhole+b){
++++i+=+0;
++++m.entrySet().forEach(entry+->+{+i+%2B=+entry.getKey().length()+%2B+entry.getValue();+});
++++return+i;
}
public+static+void+main(String[]+args)+throws+RunnerException+{
++++Options+opt+=+new+OptionsBuilder()
++++++++++++.include(Test.class.getSimpleName())
++++++++++++.forks(1)
++++++++++++.warmupIterations(25)
++++++++++++.measurementIterations(25)
++++++++++++.measurementTime(TimeValue.milliseconds(1000))
++++++++++++.warmupTime(TimeValue.milliseconds(1000))
++++++++++++.timeUnit(TimeUnit.MICROSECONDS)
++++++++++++.mode(Mode.AverageTime)
++++++++++++.build();
++++new+Runner(opt).run();
}|code-block|syntax|javascript|270437|结果：|270438|Benchmark++++++++++++(limit)++Mode++Cnt++++++Score++++Error++Units
Test.entries++++++++++++++50++avgt+++25++++++0.282+±++0.037++us/op
Test.entries+++++++++++++500++avgt+++25++++++2.792+±++0.080++us/op
Test.entries++++++++++++5000++avgt+++25+++++29.986+±++0.256++us/op
Test.entries+++++++++++50000++avgt+++25+++1070.218+±++5.230++us/op
Test.entries++++++++++500000++avgt+++25+++8625.096+±+24.621++us/op
Test.entriesForEach+++++++50++avgt+++25++++++0.261+±++0.008++us/op
Test.entriesForEach++++++500++avgt+++25++++++2.891+±++0.007++us/op
Test.entriesForEach+++++5000++avgt+++25+++++31.667+±++1.404++us/op
Test.entriesForEach++++50000++avgt+++25++++664.416+±++6.149++us/op
Test.entriesForEach+++500000++avgt+++25+++5337.642+±+91.186++us/op
Test.forEach++++++++++++++50++avgt+++25++++++0.286+±++0.001++us/op
Test.forEach+++++++++++++500++avgt+++25++++++2.847+±++0.009++us/op
Test.forEach++++++++++++5000++avgt+++25+++++30.923+±++0.140++us/op
Test.forEach+++++++++++50000++avgt+++25++++670.322+±++7.532++us/op
Test.forEach++++++++++500000++avgt+++25+++5450.093+±+62.384++us/op
Test.keys+++++++++++++++++50++avgt+++25++++++0.453+±++0.003++us/op
Test.keys++++++++++++++++500++avgt+++25++++++5.045+±++0.060++us/op
Test.keys+++++++++++++++5000++avgt+++25+++++58.485+±++3.687++us/op
Test.keys++++++++++++++50000++avgt+++25+++1504.207+±+87.955++us/op
Test.keys+++++++++++++500000++avgt+++25++10452.425+±+28.641++us/op
Test.keysForEach++++++++++50++avgt+++25++++++0.567+±++0.025++us/op
Test.keysForEach+++++++++500++avgt+++25++++++5.743+±++0.054++us/op
Test.keysForEach++++++++5000++avgt+++25+++++61.234+±++0.171++us/op
Test.keysForEach+++++++50000++avgt+++25+++1142.416+±++3.494++us/op
Test.keysForEach++++++500000++avgt+++25+++8622.734+±+40.842++us/op|270439|正如您所看到的，HashMap.forEach和HashMap.entrySet().forEach()在大型地图上的性能最好，并且在entrySet()上加入了for循环，以便在小型地图上获得最佳性能。|270440|keys方法速度较慢的原因可能是它们必须为每个条目再次查找该值，而其他方法只需读取对象中的一个字段即可获得该值。我认为迭代器方法速度较慢的原因是它们正在进行外部迭代，这需要对每个元素进行两次方法调用(hasNext和next)，并将迭代状态存储在迭代器对象中，而forEach完成的内部迭代只需要一次对accept的方法调用。|270441|您应该在目标硬件上配置目标数据，并在循环中执行目标操作，以获得更准确的结果。|270442|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/10/docs/api/java/util/Map.html#forEach(java.util.function.BiConsumer)^0|P|S|1M|H|1M|H|0|0|0|0|0|0|8|F|O|S|1V|A|0|2S|7|30|4|3N|7|47|6|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|F|3|G|5|6|7|1C|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|1D|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1E|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|1F|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|1N|8|@$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|1W|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]]|X|$Y|$5|Z|10|11|E|$12|13]]]]

The most efficient ways (according to my benchmark) are to use the new <a href="https://docs.oracle.com/javase/10/docs/api/java/util/Map.html#forEach(java.util.function.BiConsumer)" rel="noreferrer"><code>HashMap.forEach()</code></a> method added in Java 8 or <code>HashMap.entrySet().forEach()</code>.

JMH Benchmark:

<pre><code>@Param({"50", "500", "5000", "50000", "500000"})
int limit;
HashMap&lt;String, Integer&gt; m = new HashMap&lt;&gt;();
public Test() {
}
@Setup(Level.Trial)
public void setup(){
 m = new HashMap&lt;&gt;(m);
 for(int i = 0; i &lt; limit; i++){
 m.put(i + "", i);
 }
}
int i;
@Benchmark
public int forEach(Blackhole b){
 i = 0;
 m.forEach((k, v) -&gt; { i += k.length() + v; });
 return i;
}
@Benchmark
public int keys(Blackhole b){
 i = 0;
 for(String key : m.keySet()){ i += key.length() + m.get(key); }
 return i;
}
@Benchmark
public int entries(Blackhole b){
 i = 0;
 for (Map.Entry&lt;String, Integer&gt; entry : m.entrySet()){ i += entry.getKey().length() + entry.getValue(); }
 return i;
}
@Benchmark
public int keysForEach(Blackhole b){
 i = 0;
 m.keySet().forEach(key -&gt; { i += key.length() + m.get(key); });
 return i;
}
@Benchmark
public int entriesForEach(Blackhole b){
 i = 0;
 m.entrySet().forEach(entry -&gt; { i += entry.getKey().length() + entry.getValue(); });
 return i;
}
public static void main(String[] args) throws RunnerException {
 Options opt = new OptionsBuilder()
 .include(Test.class.getSimpleName())
 .forks(1)
 .warmupIterations(25)
 .measurementIterations(25)
 .measurementTime(TimeValue.milliseconds(1000))
 .warmupTime(TimeValue.milliseconds(1000))
 .timeUnit(TimeUnit.MICROSECONDS)
 .mode(Mode.AverageTime)
 .build();
 new Runner(opt).run();
}
</code></pre>

Results:

<pre><code>Benchmark (limit) Mode Cnt Score Error Units
Test.entries 50 avgt 25 0.282 ± 0.037 us/op
Test.entries 500 avgt 25 2.792 ± 0.080 us/op
Test.entries 5000 avgt 25 29.986 ± 0.256 us/op
Test.entries 50000 avgt 25 1070.218 ± 5.230 us/op
Test.entries 500000 avgt 25 8625.096 ± 24.621 us/op
Test.entriesForEach 50 avgt 25 0.261 ± 0.008 us/op
Test.entriesForEach 500 avgt 25 2.891 ± 0.007 us/op
Test.entriesForEach 5000 avgt 25 31.667 ± 1.404 us/op
Test.entriesForEach 50000 avgt 25 664.416 ± 6.149 us/op
Test.entriesForEach 500000 avgt 25 5337.642 ± 91.186 us/op
Test.forEach 50 avgt 25 0.286 ± 0.001 us/op
Test.forEach 500 avgt 25 2.847 ± 0.009 us/op
Test.forEach 5000 avgt 25 30.923 ± 0.140 us/op
Test.forEach 50000 avgt 25 670.322 ± 7.532 us/op
Test.forEach 500000 avgt 25 5450.093 ± 62.384 us/op
Test.keys 50 avgt 25 0.453 ± 0.003 us/op
Test.keys 500 avgt 25 5.045 ± 0.060 us/op
Test.keys 5000 avgt 25 58.485 ± 3.687 us/op
Test.keys 50000 avgt 25 1504.207 ± 87.955 us/op
Test.keys 500000 avgt 25 10452.425 ± 28.641 us/op
Test.keysForEach 50 avgt 25 0.567 ± 0.025 us/op
Test.keysForEach 500 avgt 25 5.743 ± 0.054 us/op
Test.keysForEach 5000 avgt 25 61.234 ± 0.171 us/op
Test.keysForEach 50000 avgt 25 1142.416 ± 3.494 us/op
Test.keysForEach 500000 avgt 25 8622.734 ± 40.842 us/op
</code></pre>

As you can see, <code>HashMap.forEach</code> and <code>HashMap.entrySet().forEach()</code> perform best for large maps and are joined by the for loop on the <code>entrySet()</code> for best performance on small maps. 

The reason the keys methods are slower is probably because they have to lookup the value again for each entry, while the other methods just need to read a field in an object they already have to get the value. The reason that I would expect the iterator methods to be slower is that they are doing external iteration, which requires two method calls (<code>hasNext</code> and <code>next</code>) for each element as well as storing the iteration state in the iterator object, while the internal iteration done by <code>forEach</code> requires just one method call to <code>accept</code>.

You should profile on your target hardware with your target data and doing your target action in the loops to get a more accurate result.

Given the following code, with two alternative ways to iterate through it, 
is there any performance difference between these two methods?

<pre><code> Map&lt;String, Integer&gt; map = new HashMap&lt;String, Integer&gt;();
 //populate map

 //alt. #1
 for (String key : map.keySet())
 {
 Integer value = map.get(key);
 //use key and value
 }

 //alt. #2
 for (Map.Entry&lt;String, Integer&gt; entry : map.entrySet())
 {
 String key = entry.getKey();
 Integer value = entry.getValue();
 //use key and value
 }
</code></pre>

I am inclined to think that <code>alt. #2</code> is the more efficient means of iterating through the entire <code>map</code> (but I could be wrong)

Java : Iteration through a HashMap, which is more efficient?

性能测试

给定以下代码，并使用两种可选的方法对其进行迭代，这两种方法在性能上有什么区别吗？ Map<String, Integer> map = new HashMap<String, Integer>(); //populate map //alt. #1 for (St...

问Java :通过HashMap迭代，哪个更高效？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java :通过HashMap迭代，哪个更高效？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java :通过HashMap迭代，哪个更高效？
EN