运行时类型识别：.class属性与getClass()方法的性能差异对比

.class是编译期常量，零开销；getClass()是运行时方法调用，有2–5纳秒开销，语义不同：前者获取已知类的Class对象，后者获取对象实际运行时类型，不可互换。

直接说结论：.class 是编译期常量，零开销；getClass() 是运行时方法调用，有微小但可测的开销。两者语义不同，不能简单替换，性能差异只在高频反射或极端敏感场景下才需关注。

本质区别决定性能起点不同

这不是“快慢”的问题，而是“有没有执行成本”的问题：

• .class 是类字面量（class literal），由编译器在编译时解析为常量池中的 Class 引用，JVM 在类加载阶段就完成解析，后续使用不触发任何方法调用或类型检查
• getClass() 是 Object 的 final native 方法，每次调用都需进入 JVM 内部，执行对象头读取、类型校验、Class 对象返回等步骤——哪怕只是读一个字段，它仍是方法调用

实际开销有多大？

在现代 HotSpot JVM（如 JDK 17+）中：

• 单次 getClass() 调用耗时约 2–5 纳秒（取决于是否被 JIT 内联）
• .class 访问等价于静态字段读取，通常被优化为常量折叠或直接内存寻址，接近 0 纳秒
• 若 getClass() 出现在循环内（如每毫秒调用万次以上）、或作为反射元数据频繁入口（如自定义序列化框架），累积开销可能影响吞吐量

JIT 会优化 getClass() 吗？

会，但有条件：

• 当对象类型在编译期可推断（例如局部 final 变量、明确构造的实例），JIT 可能将 getClass() 内联并常量化，效果接近 .class
• 但若对象来自多态引用（如 List item = map.get(key)），JIT 无法确定实际类型，getClass() 就无法完全消除——必须走虚表或内联缓存路径
• 而 .class 从不依赖运行时状态，永远稳定、永远无分支

选哪个？别只看性能

真正该按语义选，而非微基准测试结果：

• 要获取某个已知类的 Class 对象（如作为泛型参数、注册类型、构造器入参）→ 用 A.class
• 要获取某个未知对象的实际运行时类型（如处理继承体系、判断具体子类、做类型分发）→ 必须用 obj.getClass()
• 拿 getClass() 去替代 A.class 属于语义错误：前者返回的是 obj 实际类型（可能是 A 的子类），后者永远是 A 本身