Anzahl der Einträge ist die Anzahl der Schlüssel-Wert-Zuordnungen in der Karte, wie sie durch https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#size-- oder alternativ zurückgeführt, indem die Anzahl der Elemente in der Set zurück https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--
Dies entspricht Unsere Intuition darüber, was eine Karte ist, eine Sammlung von Schlüssel-Wert-Paaren, so dass jedes Paar ein Eintrag ist.
Pro https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html wird die Anzahl der Einträge mit dem Produkt des Ladefaktors fac, einem beliebigen Parameter, und der Kapazität cap, der aktuellen Anzahl der Buckets, verglichen.
Sie denken an "wenn der Lastfaktor erreicht", aber das ist nicht korrekt. Der Ladefaktor ändert sich nach dem Bau nicht. Standardmäßig ist es 0.75, ausreichend für fast alle Anwendungen.
Denken statt threshold das Produkt threshold = fac * cap;. Der Schwellenwert ändert sich nur, wenn sich cap ändert, weil fac dies nicht tut.
Was ändert sich die ganze Zeit ist nentries, die Anzahl der Einträge derzeit in der Karte.
(Ich mache nur Variablennamen bis zu dieser Antwort zu vereinfachen. Sie hat nichts mit tatsächlichem Java API Quellcode zu tun hat.)
Ihr Diagramm zeigt fünf Eimer, so threshold = (int)(0.75 * 5) oder 3.
Die Entscheidung für eine erneute Messung lautet if (nentries >= threshold). Sie haben zehn Einträge in Ihrem Bild, also ja, diese Karte benötigt eine Neuaufbereitung. Tatsächlich hätte es sich bei dem dritten Eintrag aufgefrischt und die Zahl cap je nach Implementierung auf ungefähr zehn Einträge erhöht. Beim achten Eintrag würde die Kapazität auf zwanzig steigen, also wären zehn Einträge kleiner als der neue Schwellenwert threshold = 0.75 * 20 oder 16.
Die Anzahl der Einträge ist die Anzahl der Schlüssel, ja, da jeder Schlüssel nur einen zugeordneten Wert hat und ein Eintrag ein Schlüssel/Wert-Paar ist. Der Punkt, der eine solche Karte wiederherstellt, besteht gerade darin, diese lange verkettete Liste zu vermeiden, die die Leistung der Karte beeinträchtigt, und die Einträge besser unter Buckets verteilt. Eine ideale Verteilung ist, wenn jeder Bucket nur 0 oder 1 Eintrag hat. –
Aber wenn solche Kollisionen auftreten, würde das Wiederhashen nicht helfen, oder? Nur das Ändern der hashFunction würde funktionieren? – Nicky
Nein. Nehmen wir ein einfaches Beispiel, in dem die Map 3 Buckets hat und ein einfacher Modulo des Hash-Codes verwendet wird, um den Bucket auszuwählen.Nehmen wir an, Sie haben 0, 3 und 6 in der Karte. Sie alle würden im Bucket 0 sein, denn 0% 3 == 0, 3% 3 == 0 und 6% 3 == 0. Jetzt wollen wir noch einmal räumen und stattdessen 7 Buckets verwenden. Jetzt 0% 7 == 0, so dass der erste Schlüssel zum Eimer 0 geht. 3% 7 == 3, so dass 3 im Eimer 3 endet. 6% 7 == 6, also geht der Schlüssel 6 zum Eimer 6 Und die Schlüssel sind nun ideal auf die Buckets verteilt. –