该用 int 而非 Integer 的场景是变量只参与计算、循环或作为数组元素时，因其无装箱拆箱开销、内存占用小、访问快且更安全；Integer 仅在集合操作、空值表达、工具调用、反射与注解四类场景中不可替代。
什么时候该用 int，而不是 Integer
当变量只参与计算、循环或作为数组元素时，int 是更优选择。它直接存于栈或对象内部，没有对象头开销，也不涉及装箱拆箱。比如计数器、索引、数学运算中间结果——这些场景下用 int 更快也更安全。
- 高频循环中避免用 Integer 做计数器，否则每次迭代都可能触发自动装箱，带来额外 GC 压力
- 定义数组优先选 int[]，而非 Integer[]；后者每个元素都是堆上独立对象，内存占用高且访问慢
- switch 表达式只接受基本类型，必须用 int；若传入 Integer 会隐式拆箱，null 时直接抛 NPE
Integer 的不可替代场景
Integer 不是 int 的“升级版”，而是语义和结构上的必要补充。它在以下四类场景中无法被替代：
-
集合操作：List、Map、Set 等泛型容器要求引用类型，List
编译不通过，必须用 List - 空值表达：数据库字段允许 NULL、前端参数可缺省、业务需区分“0”和“未填写”，此时 Integer age = null 比 int age = 0 更准确
- 工具调用：如 Integer.parseInt()、Integer.toHexString()、Integer.compare() 这些静态方法只能由 Integer 提供
- 反射与注解：Spring 的 @Value、MyBatis 的 resultMap 映射、Lombok 的 @Data 字段推导，都依赖包装类的类型信息和 null 容忍能力
long 和大整数的选用逻辑
int 范围是 -2³¹ 到 2³¹−1（约 ±21 亿），超出即溢出。long 范围达 ±9.2×10¹⁸，适合时间戳、ID、统计累加等易超限场景。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 数据库主键（尤其 Snowflake 或分布式 ID）建议用 long，避免未来扩容风险
- 毫秒级时间戳（如 System.currentTimeMillis()）必须用 long，int 在 2038 年后将溢出
- 当数值可能超过 long 范围（比如金融精确计算、密码学大数），改用 BigInteger，它支持任意精度，但牺牲性能和简洁性
缓存机制与常见陷阱
Integer 内部有 -128 到 127 的缓存池，调用 Integer.valueOf(100) 返回的是同一个对象，而 new Integer(100) 总是新建实例。这个机制影响相等判断和内存使用。
立即学习“Java免费学习笔记（深入）”；
- 永远用 Integer.valueOf() 或自动装箱（Integer i = 100），别用 new Integer() —— 后者绕过缓存且已标记为废弃
- 比较两个 Integer 时，用 equals()，不用 ==；后者对缓存外数值（如 200）一定返回 false，即使值相同
- 警惕自动拆箱：Integer i = null; int j = i; 直接触发 NullPointerException，尤其在从 Map.get() 或 JSON 解析后未判空时极易发生
