java数值转换本身开销极小，真正拖慢性能、吃掉内存的是对象创建、装箱拆箱、冗余校验、泛型容器及不匹配精度选择；优化关键在于“为什么转”和“能不能不转”，应优先使用原生类型、基本类型数组，规避biginteger/bigdecimal滥用与包装类集合。
Java数值转换本身开销极小，真正拖慢性能、吃掉内存的，是转换背后那些“看不见”的动作：对象创建、装箱拆箱、冗余校验、类型擦除后的泛型容器，以及不匹配的精度选择。优化关键不是“怎么转”，而是“为什么转”和“能不能不转”。
优先用原生类型，避开BigInteger/BigDecimal陷阱
非金融、非超高精度场景下，别一上来就用BigInteger或BigDecimal。它们是对象，每次运算都新建实例、分配堆内存、触发GC——比long慢几十倍不止。
- 整数运算在±9.2×10¹⁸范围内，直接用
long；超出再考虑BigInteger，且尽量批量处理、复用中间结果 - 金额计算必须用
BigDecimal，但构造时优先用BigDecimal.valueOf(double)而非new BigDecimal(String)，避免浮点误差；字符串构造更推荐new BigDecimal("123.45") - 别把
double转成BigDecimal再转回double——直接用Math.round(d * 100) / 100.0更轻更快
基本类型数组替代包装类集合
Integer[]比int[]内存高6倍以上，List<double></double>每次取值都要拆箱，还带GC压力。矩阵、统计、批处理等数据密集场景，必须回归原始数组。
- 用
int[]、float[]、double[]代替List<integer></integer>、ArrayList<double></double> - 避免
Arrays.asList(intArray)——它返回的是List<integer></integer>，底层全是装箱 - 需要泛型抽象？用模板接口+工厂模式生成具体类型实现（如
FloatMatrix、IntMatrix），而不是靠Number统一兜底
规避运行时类型判断与隐式转换
热代码里写if (type == FP32) {...} else {...}不仅分支预测失败，还让JVM无法内联、无法向量化。类型适配要提前到初始化阶段固化。
- 模型加载时就确定精度，静态工厂返回
MatMulF32或MatMulF64实例，后续全程无判断 - JDK 19+ Vector API支持零拷贝视图切换，例如
FloatVector.fromMemorySegment(...).castShape(IntVector.SPECIES_256)，无需复制数据 - 读ONNX、Protobuf等二进制格式时，直接解析为
float[]或int[]，跳过Object中转层
窄化转换慎用校验，宽化转换预判范围
long → int、double → long这类转换本身很快，但溢出检查（如Math.toIntExact()）有开销；而盲目跳过又可能崩溃。策略取决于输入是否可控。
- 业务明确值在范围内（如毫秒时间戳转秒）→ 直接
(int) value，省去检查 - 不确定来源或外部输入 → 用
Math.toIntExact()，它底层是JVM内建指令，比手动if (x Integer.MAX_VALUE)更快 - 字符串转数字时，
Integer.parseInt()比Integer.valueOf()略快（后者内部调用前者，再做缓存封装）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
