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 规范硬性要求。看似“自动”，实则每次运算都多一次类型扩展指令，且结果无法直接赋回原类型。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 高频计算场景（如图像像素处理、音频采样）中，大量
byte[]运算实际走的是int路径，内存带宽和寄存器压力反增；此时应考虑用int[]存储并控制值域，或用 Unsafe/VarHandle 批量操作 - 方法参数传递时，传
byte却调用int参数方法，虽编译通过，但丧失类型意图——建议为小整数定义专用封装类（如UInt8），用构造器约束范围，避免裸类型误用
安全转型：不只是加括号
基本类型转换失败会在编译期报错，但对象引用转型（如 (String)obj）可能引发 ClassCastException。真正影响性能与稳定性的，往往是后者。
- 用
instanceof预检再转型，比直接强转 + 捕获异常快得多——异常抛出代价远高于一次类型检查 - 泛型能彻底规避多数集合取值转型：用
List<bigdecimal></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 含义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
