Java中Collection.size()返回int，无法表示超2147483647的元素数，溢出时回绕为负值，属设计限制而非边界处理问题。
Java 中 Collection.size() 方法的返回类型是 int，因此它无法正确表示大于 Integer.MAX_VALUE（即 2,147,483,647）的元素数量。这不是“边界处理”的问题，而是设计限制——该方法根本不会也不支持超过 int 范围的大小。
size() 的语义和契约
Collection.size() 的 Javadoc 明确说明：返回集合中元素的个数，类型为 int。这意味着：
- 任何标准 JDK 集合实现（如
ArrayList、HashSet、LinkedList）在内部都用int计数，一旦添加元素导致计数溢出，行为未定义（实际通常表现为负数或回绕）； - 没有任何 Collection 实现会在 size 超过
Integer.MAX_VALUE时抛出异常或自动切换为 long —— 它们只是按 int 运算规则溢出； - 调用
size()永远返回一个int，哪怕底层已逻辑上“超限”，也不会改变返回类型或抛出运行时异常。
为什么没有 long 版本？
这是 Java 集合框架早期设计决策的结果：
- 历史原因：JDK 1.2 引入 Collection 时，
int被认为足够大（21 亿元素对绝大多数场景已是天文数字）； - 兼容性与一致性：更改返回类型会破坏全部已有实现和客户端代码；
- 内存与性能权衡：用
long存储计数对每个集合实例增加 4 字节开销，且多数场景无必要。
实际开发中如何应对“超大集合”？
如果你确实需要处理远超 Integer.MAX_VALUE 元素的场景（例如流式数据、分布式集合、磁盘映射集合等），不能依赖 size()：
立即学习“Java免费学习笔记（深入）”；
- 使用专门设计的类库，如
org.apache.commons.collections4.CollectionUtils.size()仍返回 int，不解决本质问题；真正可行的是LongStream.count()或自定义计数器（如原子 long）； - 避免调用
size()前提下进行判断：用isEmpty()、迭代器遍历 + 计数（用long累加）、或借助外部元数据（如数据库 COUNT 查询结果）； - 注意：
Stream.count()返回long，但它统计的是流中元素个数，不是底层 Collection 的size()；若源集合本身已溢出，流构造可能失败或产生错误计数。
溢出后会发生什么？
假设某集合内部计数器达到 Integer.MAX_VALUE 后再 add 一个元素：
- 计数器变量（int 类型）会变为
Integer.MIN_VALUE（即 -2147483648），size()返回负数； - 这可能导致
for (int i = 0; i 死循环，或 <code>coll.toArray(new Object[coll.size()])抛出NegativeArraySizeException； - 没有任何 Collection 实现在 add 时检查溢出并拒绝操作——这是使用者的责任。
