基本类型在现代jvm中仍具硬优势：局部变量常被提升至寄存器（1–3纳秒访问），原始数组连续布局利于缓存预取，纯int运算可向量化，而装箱/拆箱仍带来显著gc压力与性能损耗。
明显，而且比以往更关键。
栈上分配 + 寄存器优化仍是硬优势
现代 JVM（如 HotSpot 17/21）并未取消基本类型的底层特权，反而强化了它们的优化路径：
- 局部基本类型变量几乎总被 JIT 编译器提升至 CPU 寄存器，访问延迟稳定在 1–3 纳秒；引用类型哪怕逃逸分析成功，也需维护对象头、字段偏移、内存屏障等开销
- int[]、double[] 等原始数组仍以连续内存块布局，CPU 预取器可高效加载整行缓存（64 字节），而 ArrayList
的每个元素是堆中离散地址，实测缓存命中率下降 40% 以上 - 循环中的纯 int 运算（如 sum += arr[i]）大概率被向量化（SIMD），JIT 可自动展开为单条 CPU 指令；Integer 对象无法参与此类优化
装箱/拆箱成本没变小，反而更易暴露
自动装箱（Autoboxing）机制本身没优化，只是 JIT 更擅长识别“-128~127 缓存区间”，但超出后代价依旧沉重：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- Integer.valueOf(1000) 每次都 new 对象（24 字节堆空间 + GC 压力），高频场景下 Minor GC 频次直接翻倍
- Stream API 中用 mapToInt() 替代 map(Integer::intValue)，可避免中间 Integer 对象生成——这不是语法糖差异，是字节码层面少掉 invokestatic + astore 指令
- 日志埋点写 log.info("count={}", count) 安全，但写 log.info("data={}", Collections.singleton(count)) 就隐式触发装箱+集合创建，毫秒级响应服务里这种写法会拖慢 P99 延迟
GC 压力差异在云原生环境下被放大
容器化部署普遍限制堆内存（如 -Xmx512m），而基本类型不进堆：
- 百万级计数器用 long sum = 0; 循环累加：零对象、零 GC
- 同逻辑写成 Long sum = 0L;：生成百万个 Long 实例，Eden 区迅速占满，每秒触发多次 Minor GC，STW 时间累积不可忽视
- Kubernetes 中 Pod 内存超限被 OOMKilled，往往就源于这类“小对象雪崩”——不是代码有 bug，而是基本类型误用
不是 JVM 变弱了，而是应用对确定性要求更高了
金融风控、实时推荐、IoT 设备端等场景，已不满足于“平均延迟低”，而要求 P999 延迟稳定：
- boolean flag 比 Boolean flag 少 null 检查、无 equals 重载风险，分支预测更准
- 用 int status 存状态码，可直接做数组索引（handlers[status]）、位运算（status & FLAG_RETRY），而 StatusEnum 是对象查找+虚方法调用
- Unsafe 或 VarHandle 直接操作内存时，只接受基本类型或其数组——这是 JVM 底层 API 的硬性约定，绕不开
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
