java - What if a HashMap is full? -


i know java hashmap has capacity , load factor parameter.so , if number of items in hashmap more capacity* load factor, new hashmap reconstructed.i have questions re-constructions of it:

  1. the previous hashmap reclaimed or still in use if reconstruction happened?
  2. since need larger size hashmap , , hash function changed ?
  3. for concurrenthashmap , if 1 thread inserting(of cource, insert operation has lead re-construction) , thread reading?for example, read old hashmap or new hashmap?

the previous hashmap reclaimed or still in use if reconstruction happened?

it's still same hashmap, internal storage reconstructed. after reconstruction old bucket array not needed anymore , gc'ed.

update: internally hashmap has node<k,v>[] table. during resize new array constructed, elements moved , table replaced new array. after operation map not reference old array anymore unless there no other references (which unlikely due table being package private) elligible gc.

since need larger size hashmap , , hash function changed ?

no, hash function won't change. doesn't depend on number of buckets generated hash adjusted correct bucket (e.g. applying modulo)

update: hashmap calculates bucket index this: (size - 1) & hash, hash return value of key's hashcode() method, doesn't depend on map itself.

for concurrenthashmap , if 1 thread inserting(of cource, insert operation has lead re-construction) , thread reading?for example, read old hashmap or new hashmap?

i'd have guess here (i'll code later) assume long threads reading old buckets they'll still in use , freed later.

update: had quick @ concurrenthashmap sources , there reference current table used get() , possible nexttable target resize operations. during resize elements transferred nexttable , @ end table set nexttable, switching tables.

this means during resizing old table still read , @ point gets replaced. during insert operations there might blocking, e.g. using synchronized blocks, if resize needed or being performed.

the documentation hints @ this:

a hash table supporting full concurrency of retrievals , high expected concurrency updates.

this means get won't block put, remove etc. might block @ point.


Comments

Popular posts from this blog

c++ - QTextObjectInterface with Qml TextEdit (QQuickTextEdit) -

javascript - angular ng-required radio button not toggling required off in firefox 33, OK in chrome -

xcode - Swift Playground - Files are not readable -