Question

我试图理解在超过所占用的桶数或所有桶中的条目总数时，会发生重新散列的散列图。意思是，我们知道如果16个桶中的12个（每个桶中有一个条目）已满（考虑到默认的loadfactor和初始容量），那么我们就知道在下一个条目中将重新散列hashmap。但是假设只有3个桶被占用，每个4个条目（总共12个条目，但在使用16个中只有3个桶）呢？

所以我尝试通过制作最差的哈希函数来复制它，这将把所有条目放在一个桶中。

这是我的代码。

class X {

    public Integer value;

    public X(Integer value) {
        super();
        this.value = value;
    }

    @Override
    public int hashCode() {
        return 1;
    }

    @Override
    public boolean equals(Object obj) {
        X a = (X) obj;
        if(this.value.equals(a.value)) {
            return true;
        }
        return false;
    }

}

现在我开始将值放在hashmap中。

HashMap<X, Integer> map = new HashMap<>();
    map.put(new X(1), 1);
    map.put(new X(2), 2);
    map.put(new X(3), 3);
    map.put(new X(4), 4);
    map.put(new X(5), 5);
    map.put(new X(6), 6);
    map.put(new X(7), 7);
    map.put(new X(8), 8);
    map.put(new X(9), 9);
    map.put(new X(10), 10);
    map.put(new X(11), 11);
    map.put(new X(12), 12);
    map.put(new X(13), 13);
    System.out.println(map.size());

所有节点都按预期进入了单个存储桶，但我注意到在第9个条目中，hashmap重新进行了加倍并将其容量加倍。现在在第10次进入，它的容量再次增加了一倍。

任何人都可以解释这是怎么回事吗？

提前致谢。

Answer 1

回答评论的不仅仅是问题本身，因为您的评论与您想要了解的内容更相关。

public class NotifyService extends Service { /** * Class for clients to access */ public class ServiceBinder extends Binder { NotifyService getService() { return NotifyService.this; } } // Unique id to identify the notification. public static final String INTENT_NOTIFY = "com.blundell.tut.service.INTENT_NOTIFY"; private NotificationManager mNM; private Notification notif; @Override public void onCreate() { Log.i("NotifyService", "onCreate()"); mNM = (NotificationManager) getSystemService(NOTIFICATION_SERVICE); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.i("LocalService", "Received start id " + startId + ": " + intent); if(intent.getBooleanExtra(INTENT_NOTIFY, false)) showNotification(); return START_NOT_STICKY; } @Override public IBinder onBind(Intent intent) { return mBinder; } // This is the object that receives interactions from clients private final IBinder mBinder = new ServiceBinder(); /** * Creates a notification and shows it in the OS drag-down status bar */ private void showNotification() { CharSequence title = "Alarm!!"; int icon = R.drawable.ic_dialog_alert; CharSequence text = "Your notification time is upon us."; Notification.Builder notification = new Notification.Builder(NotifyService.this); PendingIntent contentIntent = PendingIntent.getActivity(this, 0, new Intent(this, SecondActivity.class), 0); int Notif = MyApp.preferences.getInt("notif", 1); notification.setContentTitle(title) .setContentText(text) .setSmallIcon(icon) .setContentIntent(contentIntent); notif = notification.getNotification(); notif.flags |= Notification.FLAG_AUTO_CANCEL; mNM.notify(Notif, notif); stopSelf(); }}的最佳和最相关的答案是源代码本身。您在where this rehashing on bucket size is explained further条目上观察到的内容是预期的，并且会在代码的这一部分中发生：

9-th

其中for (int binCount = 0; ; ++binCount) { // some irrelevant lines skipped if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st treeifyBin(tab, hash); break; }和TREEIFY_THRESHOLD = 8是分档数。

binCount方法名称有点误导，因为可能重新调整大小，而不是树形容器，这是该方法代码的相关部分：

treeifyBin

请注意，实际上if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY) resize();（读取它的大小加倍）并且在达到resize之前不会生成Tree（64）。

Answer 2

在HashMap中，如果条目的哈希码相同，则条目将出现在同一个桶中。如果将唯一的Integer对象放在hashMap中，则它们的hashcode肯定会发生变化，因为它们是不同的对象。

但在您的情况下，所有对象都具有相同的哈希码。这意味着您指定的所有条目都将在一个存储桶中。这些桶中的每一个都遵循特定的数据结构（linkedList / tree）。这里的容量根据特定的数据结构和hashmap而变化。

我在评论中提到了JB Nizet的代码（https://gist.github.com/jnizet/34ca08ba0314c8e857ea9a161c175f13/revisions），循环限制为64和128（添加了64和128个元素）：

添加64个元素：在向HashMap添加第49个元素时，容量加倍（128）（因为加载因子为0.75）
添加128个元素：在向HashMap添加第97个元素时，容量增加了一倍（256）（也因为加载因子为0.75）。

将容量增加到64后，HashMap正常工作。

总之，bucket使用链表到一定长度（8个元素）。之后，它使用树数据结构（容量有波动）。原因是访问树结构（O（log（n）））比链表（O（n））快。

此图显示了JAVA 8 HashMap的内部数组，其中包含两个树（在存储桶0处）和链接列表（在存储桶1,2和3处）。 Bucket 0是一棵树，因为它有超过8个节点（readmore）。

Hashmap上的文档以及bucket in hashmap的讨论在这方面会有所帮助。

Answer 3

阅读hashmap的源代码

/**
 * The smallest table capacity for which bins may be treeified.
 * (Otherwise the table is resized if too many nodes in a bin.)
 * Should be at least 4 * TREEIFY_THRESHOLD to avoid conflicts
 * between resizing and treeification thresholds.
 */
static final int MIN_TREEIFY_CAPACITY = 64;

您将看到

如果容量未达到MIN_TREEIFY_CAPACITY（64），并且单个存储桶上的节点达到TREEIFY_THRESHOLD，则现在地图将调整大小。
如果容量超过MIN_TREEIFY_CAPACITY（64），并且单个存储桶上的节点达到 TREEIFY_THRESHOLD，现在地图将树化存储桶上的节点（源代码中也称为bin）。

调整大小和树化是两个可以使地图重新组织的操作，上述基于不同场景的决策也是一个权衡。

Hashmap loadfactor - 基于占用的桶数或所有桶中的条目数？

3 个答案: