应按场景选择整型：byte省内存、short适协议字段、int为默认首选、long仅用于超范围场景；注意对象字段对齐、避免包装类开销、利用JVM整型优化。
Java 整型（byte、short、int、long）本身是基本类型，不参与堆内存分配，也不受 GC 管理，但它们的使用方式会深刻影响对象布局、内存占用和运行时性能。真正需要关注的不是“整型能存多大”，而是“在什么场景下选哪种整型更省、更快、更安全”。
整型选择：按需匹配，避免隐式浪费
Java 各整型的位宽与取值范围是固定的，但 JVM 在实际存储中并不总按声明类型对齐：
-
byte（1 字节，-128～127）：适合状态码、标志位、小范围计数器；用在数组中可显著降低内存 footprint（如byte[]比int[]节省 75% 内存） -
short（2 字节，-32768～32767）：适用于枚举 ID、协议字段等有明确上限的短整数；注意：JVM 运算时仍会自动提升为int，无计算性能优势 -
int（4 字节，-2³¹～2³¹−1）：默认首选；CPU 对 32 位整数运算最友好，JIT 编译优化最充分 -
long（8 字节，-2⁶³～2⁶³−1）：仅用于时间戳、大序列号、精确计数等真实超 int 范围场景；避免在高频循环中滥用（可能触发额外寄存器压力或缓存未命中）
对象内存布局中的整型开销
当整型作为对象字段存在时，其内存占用受 JVM 对象头和字段对齐规则影响：
- 对象头固定占用 12 字节（64 位 JVM + 开启指针压缩，默认开启）
- 字段按宽度从大到小排列（
long/double→int/float→short/char→byte/boolean），以减少填充字节 - 例如：
class A { long a; byte b; int c; }实际占用约 24 字节（含 3 字节填充）；若改为class A { int c; byte b; long a; }，则可能膨胀至 32 字节
集合与缓存中的整型优化实践
高频使用整数时，原始类型集合比泛型包装类更高效：
立即学习“Java免费学习笔记（深入）”；
- 避免
ArrayList<Integer>存储大量整数——每个Integer是堆上独立对象（至少 16 字节），且有装箱/拆箱开销 - 改用
int[]、IntArrayList（如 Eclipse Collections）、或LongArray（如 HPPC）等原始类型容器 - 对于稀疏、超大范围整数映射（如用户 ID → 属性），优先考虑
LongObjectHashMap或布隆过滤器 + 分段数组，而非HashMap<Long, V>
JVM 层面对整型运算的隐式优化
现代 JVM（HotSpot）对整型有深度优化，开发者可借力但不必手动干预：
- JIT 会将循环中不变的整型计算（如
i * 2）提升为位移指令（i << 1） - 常量折叠（
int x = 100 + 200;→ 直接编译为300）和范围检查消除（如数组索引在已知边界内）均自动生效 - 慎用
final static int MAX = Integer.MAX_VALUE;替代魔法数字，有助于 JIT 推断边界并优化分支预测
