hashmap最大容量为2³⁰，因int类型32位中最高位为符号位，左移31位会导致溢出为负数，故上限取1

Java HashMap 的最大容量被硬编码为 2³⁰（即 1 ，这个限制不是靠运行时校验实现的，而是通过源码中一个 static final int 常量直接定义，并在关键路径（如扩容、初始化）中强制截断超出值来保证的。

核心限制机制：常量定义 + 扩容逻辑兜底

HashMap 源码中明确声明：

static final int MAXIMUM_CAPACITY = 1

这个值有两层作用：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 它是所有容量计算的“天花板”，任何用户传入的初始容量或扩容目标，只要超过它，都会被主动替换成该值；
• 它的数值本身由 int 类型的位表示特性决定——不能触碰符号位，所以 32 位 int 最大可用正整数幂只能是 2³⁰。

为什么不是 2³¹ 或 2³¹−1？

因为 int 是带符号 32 位整数，最高位（第 31 位，从 0 开始计）是符号位：

• 1 得到的是 <code>0100...000（共 31 位，首位 0 表示正数），值为 1,073,741,824；
• 1 会把 1 移到符号位上，变成 <code>1000...000，解释为十进制就是 −2,147,483,648（负数），完全不符合容量语义；
• 而 Integer.MAX_VALUE（2³¹−1 = 2,147,483,647）虽是最大正整数，但它不是 2 的幂，HashMap 要求容量必须是 2 的幂（用于位运算取模：hash & (capacity - 1)），所以不可用。

实际如何“限制”？看扩容时的处理

当调用 resize() 尝试扩大容量时，源码会显式检查：

• 若当前容量已达 MAXIMUM_CAPACITY，直接终止扩容，同时将阈值（threshold）设为 Integer.MAX_VALUE，防止后续再触发扩容；
• 若用户构造时传入过大初始容量（比如 new HashMap(2_000_000_000)），内部 tableSizeFor() 方法会在计算“不小于该值的最小 2 的幂”后，再与 MAXIMUM_CAPACITY 取较小值，确保结果 ≤ 2³⁰。

容量必须是 2 的幂，这是前提

限制在 2³⁰ 的前提是：HashMap 依赖 capacity 是 2 的幂，才能用高效位运算替代取模运算（index = hash & (capacity - 1)）。如果不是 2 的幂，该公式失效，哈希分布和性能将严重退化。因此，所有容量调整逻辑都围绕“找最近的、不超过 2³⁰ 的 2 的幂”展开，而不是追求绝对数值上限。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南