System类不参与JIT编译控制，真正影响JIT的是JVM启动参数（如-Xint、-XX:CompileCommand）和诊断选项，而非System.setProperty等Java层调用。
System 类本身不提供监控或干预 JIT 编译的参数。Java 中没有 System.setProperty("jit.disable", "true") 这类机制，java.lang.System 是标准 API 工具类，负责 I/O、系统属性、时间戳等基础功能，**不参与 JIT 编译控制**。
真正能影响 JIT 优化的，是 JVM 启动参数与运行时诊断选项
所谓“防止 JIT 对核心代码优化”，实际场景通常指：调试时需禁用编译以稳定复现问题、验证解释执行行为，或临时规避某次错误优化（如去优化崩溃、类型假设失效）。可行方式如下：
-
彻底禁用 JIT：启动时加
-Xint，强制全程解释执行。所有方法都不编译，适合底层调试，但性能断崖式下降，不可用于生产 -
阻止特定方法被编译：用
-XX:CompileCommand=exclude,ClassName::methodName。例如：-XX:CompileCommand=exclude,com.example.Service::processOrder，该方法将永远停留在解释执行 -
限制编译器层级：设
-XX:TieredStopAtLevel=1，只启用 C1（客户端）编译，跳过激进的 C2 优化，保留可调试性与较稳的性能 -
动态排除（运行时生效）：通过
jcmd <pid> VM.compile_command "exclude ClassName::method"实时下发，无需重启进程
为什么不能靠 System.setProperty 或 System 类干预？
JIT 编译决策发生在 JVM 内部的 HotSpot 运行时系统中，由方法调用计数器、回边计数器、类型反馈等运行时数据驱动。这些机制在 native 层实现，与 Java 层的 System 类完全解耦。设置系统属性（如 System.setProperty("foo", "bar")）仅影响应用逻辑或部分库行为，对 JIT 编译器无任何作用。
需要监控 JIT 行为？用标准诊断工具，而非 System 类
要确认某段代码是否被 JIT、是否被排除、是否发生去优化，应使用：
-
-XX:+PrintCompilation：输出每次编译事件（方法名、层级、耗时） -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining：查看内联决策，判断热点方法是否被深度优化 -
jstat -compiler <pid>：观察 Compiled/Failed 数值变化，Failed 持续增长说明编译受阻 -
JIT Watcher或hsdis+-XX:+PrintAssembly：可视化编译结果与生成指令
不复杂但容易忽略：JIT 控制权始终在 JVM 启动参数和运行时诊断命令手里，System 类只是你写的代码里一个普通工具，它不指挥 JIT，也不被 JIT 指挥。
