这篇文章深入探讨了Java中HashMap的默认负载因子为什么设置为0.75。以下是文章的主要内容总结：
一句话答案：0.75是时间和空间成本之间的一个最佳平衡点。
核心价值：面试官问此问题不只是想听到一个数字，而是考察面试者对HashMap底层原理的理解、权衡取舍的工程思维、以及对背后数学知识的了解。
负载因子的本质：它是一个扩容触发器，计算公式是“已存元素数 / 桶数组长度”。当比值超过负载因子阈值时，就会触发
resize()扩容，这是一个O(n)的高成本操作。两种极端情况下的取舍：
过高（如1.0）：虽然空间利用率最高，但会等到桶满了才扩容，导致哈希冲突激增，链表变长，查询效率（
get/put）可能退化为O(n)。过低（如0.5）：虽然冲突少、查询快，但会导致过早、频繁地扩容，从而占用更多内存，空间利用率低。
0.75背后的数学原理：这个设定有其数学依据。根据JDK源码中的注释，在假设哈希函数足够理想、元素分布遵循泊松分布的前提下，当负载因子为0.75时，单个哈希桶中元素数量超过8（在Java 8中会触发链表转红黑树）的概率极低（小于千万分之一）。这意味着，在此设置下，哈希表既能保持较高的空间利用率，又能以极高的概率保证O(1)时间复杂度的查询效率。
实践指导：
默认值：绝大多数情况下，建议使用默认的0.75，这是JDK开发者经过权衡后的最优选择。
可调整的场景：
已知确切元素数量：可以在创建HashMap时，通过公式
(int)(expectedSize / 0.75) + 1来指定初始容量，避免中间扩容。内存极度紧张：可适当调高（如0.8-0.9），牺牲少量查询性能换取内存空间。
查询性能要求极致：可适当调低（如0.5-0.6），用空间换时间，但这种情况很少见。
注意避免的坑：不要将初始容量简单设置为预计元素数量，这很可能导致插入过程中仍会触发扩容。应使用上述公式计算。
最后总结：0.75是工程实践中，在“减少哈希冲突、保证查询速度”和“提高空间利用率、减少内存开销”之间达成的经验性平衡，并非绝对的最优解，但适合绝大多数通用场景。Java 8引入的红黑树转换机制也为高冲突场景提供了额外的性能保障。