title: facts about Concurrenthashmap
body: <p>I have read a couple of statements on <code>ConcurrentHashmap</code> from varied sources and wanted to verify if they are indeed so.</p>
  
  <ol>
  <li><p>After the iterator for a <code>ConcurrentHashmap</code> is created, ONLY the removal and update operations by threads are guaranteed to be reflected. 
  Does the iterator refresh its snapshot after an edit/remove? Why would the iterator treat an update/remove any differently than an ADD.</p></li>
  <li><p><code>ConcurrentHashmap</code> shards its data into segments to reduce writer lock contention. The <code>concurrencyLevel</code> parameter directly specifies the number of shards that are created by the class internally.
  If we simply use the parameterless constructor, and accept the default configuration, the map will be instantiating the objects needed for 16 shards before you even add your first value…
  What do we mean by a shard here? Is it a bucket of data within the map - or a copy of the entire map.
  I understood this to be similar to a page in the database, which can be independently locked fur update.
  Why would the <code>concurrencyLevel</code> impact memory then?</p></li>
  </ol>