jit 编译器不会因“对象参数”本身擦除核心逻辑，本质是对象行为不稳定（如多态切换、动态代理）引发去优化或逃逸分析失败；防止擦除关键在于提升对象可预测性、不扰动性与非逃逸性。
JIT 编译器不会因为“对象参数”本身擦除核心逻辑，所谓“对象参数导致擦除”，本质是对象行为不稳定（如多态实现频繁切换、运行时类加载、代理注入）引发 JIT 去优化（deoptimization），或对象创建模式触发逃逸分析失败、间接加剧 Code Cache 碎片化。防止擦除的关键不是改对象类型，而是让对象在 JIT 眼中可预测、不扰动、不逃逸。
用对象类型稳定性收敛 JIT 的 profile 信任
JIT 对虚方法调用（如 obj.process()）做内联的前提，是观察到该调用点长期只绑定 1–2 种具体类型。一旦对象实例来源混杂（比如不同租户走不同策略类、AOP 动态生成代理、Mock 替换破坏单实现假设），profile 数据就失效，已编译代码会被标记为 made not entrant 或 made zombie，强制回退解释执行。
在服务初始化或请求入口处完成对象实例的确定性选择：
if (tenant == "A") processor = new FastPathProcessor(); else processor = new LegacyFallbackProcessor();
后续所有高频调用都基于这个已知类型的引用，而非接口或泛型抽象避免在循环/高频路径中 new 对象或切换实现：
不要在 for 循环里new XxxService().handle(item)；应把 service 实例复用，且确保其 classloader 和继承链在运行期不变更启动加
-XX:+PrintCompilation -XX:+LogCompilation，检查日志中是否频繁出现made not entrant—— 这是对象类型扰动最直接的 JIT 信号
让对象生命周期可控，避免逃逸干扰编译决策
JIT 的逃逸分析（Escape Analysis）若判定对象会逃逸出当前方法或线程，就会放弃栈上分配、锁消除等关键优化，同时增加 GC 压力，间接推高 Code Cache 使用（如 Lambda capture、内部类实例频繁生成）。这类对象虽不直接“擦除代码”，但会让 JIT 持续处于保守编译状态。
把临时对象构造移出热点循环：
错误：for (item : list) { Result r = new Result(); r.setVal(item.calc()); }
正确：Result r = new Result(); for (item : list) { r.reset(); r.setVal(item.calc()); }优先使用 primitive、数组、不可变对象（如
LocalDateTime）替代易逃逸结构：StringBuffer（同步开销大、易逃逸）→ 改用StringBuilder（无锁、栈友好）HashMap（扩容、entry 创建易逃逸）→ 若 key/value 固定，考虑预分配数组 + 线性查找验证逃逸分析是否生效：加
-XX:+PrintEscapeAnalysis，看到allocates to stack表示成功；若全是allocates to heap，说明对象行为仍不可控
用对象字段访问模式强化 JIT 内联信心
JIT 更倾向内联那些字段访问明确、无副作用的方法。若一个对象方法体里大量使用 this.xxx 且字段类型稳定（非 Object、非泛型擦除后类型），C2 编译器更容易做常量传播和去虚拟化。
避免在核心计算方法中通过反射、
MethodHandle或VarHandle访问字段：
这些操作无法被 JIT 静态推导，会阻止内联，也增加 profile 噪声字段声明尽量用具体类型，少用
Object或泛型通配符：private int value;✅private Object value;❌（JIT 无法推断后续value.intValue()是否安全）方法体保持小而纯：控制在 35 字节以内，无 try-catch、无 synchronized、无日志打印，配合
-XX:+PrintInlining确认是否打出inline (hot)标记
对象参数本身不是开关，而是 JIT 观察运行时契约的窗口。你给它的对象越稳定、越简单、越早确定，它就越敢深度编译、越不容易“擦掉”已优化的代码。
