Java中仅引用类型向下转型（如(SubClass)obj）和泛型擦除后的强转会产生运行时开销，需JVM执行checkcast指令进行类元数据比对；基本类型转换无运行时开销。
Java高频循环中强制类型转换（cast）的CPU开销通常极小，多数情况下可忽略不计；真正影响性能的往往是类型检查引发的分支预测失败、内存访问模式变化，或隐含的装箱/拆箱操作——而非“转换”本身。
明确哪些cast实际产生运行时开销
Java中只有两类强制转换会在运行时执行检查并可能触发开销：
-
引用类型向下转型（如
(SubClass)obj）：JVM需执行 instanceof 检查，涉及vtable查找与类元数据比对；高频下可能干扰流水线预测 -
泛型擦除后的真实类型校验（如
List<String>中取元素后强转）：本质仍是引用类型cast，同上 -
注意：基本类型间转换（
int → long、double → float）是编译期确定的指令级操作，无分支、无查表，现代CPU单周期完成，无可观测延迟
用JMH做隔离性基准测试
避免被JIT优化干扰，必须用JMH（Java Microbenchmark Harness）控制变量：
- 启用
@Fork(jvmArgs = {"-XX:+PrintAssembly", "-XX:CompileCommand=print,.*"})查看是否生成了checkcast指令 - 对比两组方法：一组含
(ConcreteType) obj，另一组用instanceof预检+安全转型（减少异常路径） - 确保测试对象在堆上稳定分配（用
@State(Scope.Benchmark)+@Setup预热），避免逃逸分析导致栈上分配掩盖真实行为
关注HotSpot JIT的实际优化行为
HotSpot在C2编译后常能消除冗余cast：
立即学习“Java免费学习笔记（深入）”；
- 若某引用始终指向同一子类实例（如循环内反复调用
list.get(i)返回固定类型），JIT可能将checkcast优化为NOP - 可通过
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly观察是否出现mov %rax,%r10后紧跟test %r10,%r10类型校验指令 - 若cast前后紧邻
invokevirtual调用，JIT可能合并类型检查与虚方法分派，反而提升效率
比cast更值得优化的常见瓶颈
实际 profiling（如使用 async-profiler）常发现，所谓“cast慢”其实是误判：
- 真正耗时的是后续的
toString()、equals()或字段读取——而这些因cast后才触发，被错误归因 - ArrayList.get(i) 返回 Object 再 cast，不如直接用原始类型数组或 IntArrayList 等专用结构，避免泛型擦除和引用间接访问
- 频繁
(SomeEnum)x可能暴露设计问题：应优先用enum.ordinal()或switch(x)（JDK 14+ 支持枚举switch编译为tableswitch）
