Java原始类型转换开销极小，拓宽转换（如byte→int）几乎零成本，缩小转换（如long→int）需显式强制且有精度丢失风险，字符转换易出错，真正性能瓶颈常源于隐式装箱/拆箱或冗余计算。
Java 原始类型转换本身开销极小，但是否影响性能，关键看转换类型、上下文和频率。多数情况下可忽略不计，但在高频路径或特定组合中可能引入可观测的损耗。
拓宽转换（Widening）基本无开销
从窄范围类型转为宽范围类型（如 byte → int、int → long、float → double）属于编译期隐式转换，JVM 不生成额外指令，也不做运行时检查。这类转换由硬件直接支持，几乎零成本。
- 例如：
int i = 100; long l = i;—— 编译后就是寄存器扩展操作，无函数调用、无异常检查 - 注意：
char → int虽是拓宽，但因char是无符号 16 位，而int是有符号 32 位，实际执行的是零扩展（zero-extend），仍属高效操作
缩小转换（Narrowing）需强制且有潜在风险
反向转换（如 long → int、double → float、int → byte）必须显式书写 (type)，JVM 在字节码中插入 i2b、l2i、d2f 等指令。这些指令本身很快，但存在两个隐性成本：
-
精度丢失不可逆：如
int i = 257; byte b = (byte)i;结果为1，后续无法还原 -
某些场景触发额外校验：在 JIT 编译优化不充分时（如冷路径），或与分支预测冲突，可能轻微拖慢流水线；浮点→整数转换（如
d2i）在部分 CPU 架构上延迟略高
字符与数值互转容易踩坑
char 作为唯一无符号整型，与其他类型转换逻辑特殊，易引发非预期行为：
立即学习“Java免费学习笔记（深入）”；
-
byte → char：先符号扩展成int，再截断为char，负值会变大（如(byte)-1 → (char)65535） -
char → int：默认零扩展，结果恒为正值；若需符号语义，应先转short再转int - 这些转换虽快，但错误逻辑导致的 bug 比性能问题更常见，调试成本远高于执行开销
避免“伪转换”带来的真实开销
真正拖慢程序的往往不是原始类型转换本身，而是伴随它的隐式装箱/拆箱或冗余计算：
- 写
Integer i = (int)someLong;看似只是 narrowing，实则触发int → Integer装箱，涉及对象分配和 GC 压力 - 在循环内重复转换同一值（如
for (...) { double x = (double)count * factor; }），应提至循环外缓存 - 混合运算中的隐式提升（如
int / double）会将整个表达式升为double，若本意是整除，反而增加浮点运算开销
