title: Java HashMap.get(Object) infinite loop
body: <p>A few answers on SO mention that the get method in a HashMap can fall into an infinite loop (e.g. <a href="https://stackoverflow.com/a/12430092/3073460">this one</a> or <a href="https://stackoverflow.com/a/1003237/3073460">this one</a>) if not synchronized properly (and usually the bottom line is "don't use a HashMap in a multi-threaded environment, use a ConcurrentHashMap").</p>
  
  <p>While I can easily see why concurrent calls to the HashMap.put(Object) method can cause an infinite loop, I can't quite see why the get(Object) method can get stuck when it tries to read a HashMap that is being resized at that very moment. I had a look at the <a href="http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#HashMap.get%28java.lang.Object%29" rel="noreferrer">implementation in openjdk</a> and it contains a cycle, but the exit condition <code>e != null</code> should be fulfilled sooner or later. How can it loop forever?
  A piece of code that is mentioned explicitly to be vulnerable to this issue is:</p>
  
  <pre><code>public class MyCache {
      private Map&lt;String,Object&gt; map = new HashMap&lt;String,Object&gt;();
  
      public synchronized void put(String key, Object value){
          map.put(key,value);
      }
  
      public Object get(String key){
          // can cause in an infinite loop in some JDKs!!
          return map.get(key);
      }
  }
  </code></pre>
  
  <p>Can someone explain how a thread putting an object into the HashMap and another reading from it can interleave in such a way that an infinite loop is generated? Is it the case that it has to do with some cache coherency issue or CPU instruction reordering (so the problem can only happen on a multi-processor machine)?</p>