用int[]替代Integer[]是系统性优化起点，涉及内存连续分配、减少GC压力、提升缓存命中率及分块访问适配CPU缓存，需配套升级集合、序列化与传输链路。
直接用 int[] 替代 Integer[] 是最有效起点——这不是简单换类型，而是从内存布局、访问模式到GC行为的系统性优化。
连续分配 + 零碎片内存布局
10 万个 int 在 int[100000] 中是一块连续的 400KB 内存（含对象头），JVM 一次性分配；而 Integer[100000] 虽只建一个引用数组，但每个 Integer 实例需单独堆分配约 24 字节，位置随机，极易造成几十页内存碎片。结果：分配慢、GC 扫描重、易触发 Full GC。
建议：
• 尽量避免在循环中 new Integer(i) 或 list.add(i)，防止隐式装箱
• 大批量数据场景下，DTO 字段统一用 int 而非 Integer，消除空值歧义前先确认业务能否接受默认值语义
对齐地址提升缓存行命中率
CPU 每次按 64 字节缓存行加载数据。若 int[] 起始地址未对齐，单次读取可能跨行，浪费带宽且多线程下易伪共享。
Java 层虽无原生 alignas，但可通过以下方式逼近效果：
• 使用 Unsafe.allocateMemory 配合手动偏移，申请时指定对齐边界
• 或借助 ByteBuffer.allocateDirect(alignSize) 分配对齐内存，再用 asIntBuffer()
• 确保后续遍历严格按自然顺序（i++），保障空间局部性
分块访问适配 CPU 缓存层级
即使内存连续，超大数组（如千万级）若一次遍历到底，热点数据无法驻留 L1 缓存（通常 32–64 KB），会频繁淘汰、反复加载。
立即学习“Java免费学习笔记（深入）”；
推荐按 L1d 容量反推块大小：
• int 占 4 字节 → 32KB / 4 = 8192 元素/块
• 代码结构示例：
for (int i = 0; i < arr.length; i += 8192) {
int end = Math.min(i + 8192, arr.length);
for (int j = i; j < end; j++) { /* 处理 arr[j] */ }
}
配套链路同步升级
单改数组类型收益有限，上下游必须协同：
• 集合层：用 FastUtil 的 IntArrayList 或 Eclipse Collections 的 MutableIntList，底层仍是 int[]，无泛型擦除与装箱开销
• 序列化：Jackson 中字段声明为 int age，配合 @JsonInclude(NON_DEFAULT) 可剔除值为 0 的字段，减小 JSON 体积
• 网络传输：协议允许时切到 Protobuf，用 sint32 替代 int32，进一步压缩
