Java类型转换本身无运行时开销，但不当使用会引发性能损耗与逻辑风险：基本类型强转易致溢出或精度丢失，引用类型未校验instanceof易抛ClassCastException，泛型因类型擦除无法安全转换参数化类型。
Java 类型转换本身不产生运行时开销，但不当使用会引入隐性性能损耗和逻辑风险。关键不在“转不转”，而在于“为什么转”和“怎么转更稳”。
避免无谓的强制转换
很多强制转换源于设计缺陷，而非技术必需。例如把 int 存进 byte 变量，往往只是为省几个字节——但 JVM 对基本类型操作始终按 int 或更宽类型执行，底层并无空间优势；反而增加溢出检查负担和可读性成本。
- 优先用语义匹配的类型：ID 用
int或long，不用byte；状态码若固定在 0–127 内，也建议用int并加注释说明范围，而非强转 - 循环中避免重复强转：如
(int) Math.random() * 100每次都触发浮点运算+截断，改用ThreadLocalRandom.current().nextInt(100)更高效且语义清晰 - 数组索引、集合 size 等场景，直接用
int接收，不要从long强转——除非你明确处理超 21 亿条数据，否则属于过早优化
警惕自动提升带来的隐式开销
byte、short、char 在算术表达式中一律升为 int，这是 JVM 规范硬性要求。看似“自动”，实则每次运算都多一次类型扩展指令，且结果无法直接赋回原类型。
- 高频计算场景（如图像像素处理、音频采样）中，大量
byte[]运算实际走的是int路径，内存带宽和寄存器压力反增；此时应考虑用int[]存储并控制值域，或用 Unsafe/VarHandle 批量操作 - 方法参数传递时，传
byte却调用int参数方法，虽编译通过，但丧失类型意图——建议为小整数定义专用封装类（如UInt8），用构造器约束范围，避免裸类型误用
安全转型：不只是加括号
基本类型转换失败会在编译期报错，但对象引用转型（如 (String)obj）可能引发 ClassCastException。真正影响性能与稳定性的，往往是后者。
立即学习“Java免费学习笔记（深入）”；
- 用
instanceof预检再转型，比直接强转 + 捕获异常快得多——异常抛出代价远高于一次类型检查 - 泛型能彻底规避多数集合取值转型：用
List<BigDecimal>而非List，既免转型又防运行时错误 - 对不确定来源的对象（如 JSON 反序列化结果、反射获取值），优先用
Objects.equals()、Comparable.compareTo()等契约方法，而非依赖具体类型转型
装箱拆箱：隐形的性能黑洞
自动装箱（int → Integer）和拆箱（Integer → int）看似方便，实则每次调用 Integer.valueOf() 或 intValue() 都涉及对象创建、缓存查找或空指针风险。
- 循环内避免
Integer sum = 0; sum += i;—— 这会反复装箱拆箱，改用原始类型long sum = 0L;更稳妥 - 集合存储数值时，若确定无 null 值且追求极致性能，考虑使用
IntArrayList（来自 Trove 或 Eclipse Collections）等原始类型集合库 - 方法参数设计上，优先接收原始类型（
int）而非包装类（Integer），除非需要表达 null 含义
