多租户 jit 隔离需实现租户级编译上下文隔离、资源配额与熔断、预热灰度对齐及租户维度可观测性。具体包括：租户标识绑定线程上下文、独立 profile 与编译命名空间、带租户哈希的符号名；每租户独立编译队列与硬性资源限制；按租户预热、灰度启用 jit 及独立 preload；所有日志、指标、trace 强制打标 tenant_id。
多租户环境下，JIT 编译资源（如编译线程、内存缓冲区、profile 数据缓存）若被多个租户共享，容易出现“编译污染”：A 租户的热点函数触发 JIT 编译后，其类型假设、内联决策或优化路径可能因 B 租户同名但语义不同的函数而失效，导致反复编译、缓存抖动，甚至 CPU 毛刺。真正的隔离不是禁用 JIT，而是建立租户粒度的编译屏障。
租户级 JIT 编译上下文隔离
JIT 编译器需感知租户身份，并为每个租户维护独立的 profile 收集空间与编译命名空间。关键不在代码是否复用，而在运行时特征是否混叠：
- 在请求入口处注入租户标识（如 HTTP Header 中的 X-Tenant-ID），并绑定至当前执行线程或虚拟线程的上下文（如 Java 的 InheritableThreadLocal
或 PHP 的 request context） - 修改 JIT 运行时钩子（如 OpenJDK 的 CompilationPolicy::shouldCompileNewMethod 或 PHP 的 zend_jit_compile_op_array 入口），依据上下文租户 ID 动态选择 profile 存储槽位和编译队列
- 禁止跨租户复用已编译的 native code 缓存——即使函数签名相同，也视为不同租户的独立方法，生成带租户哈希前缀的符号名（如 tenant_abc123_calcTotal）
资源配额与编译熔断机制
避免大租户独占 JIT 线程池或 buffer，需在调度层设硬性边界：
- 为每个租户分配独立的 JIT 编译队列，并设置最大并发编译数（如 ≤2）、单次编译最大耗时（如 300ms）、buffer 占用上限（如 ≤64MB）
- 当某租户连续触发 5 次编译失败（如类型不稳定、IR 生成超时），自动降级为解释执行 + 关闭其 JIT 开关，持续 5 分钟后可试探恢复
- 监控指标必须按租户聚合：如 jit.compilation.count{tenant="fin-01"}、jit.codecache.usage{tenant="edu-02"}，纳入 SLO 告警
预热与灰度控制的租户对齐
生产环境 JIT 效果依赖稳定 profile，但多租户无法全局预热。应将预热行为与租户生命周期绑定：
- 租户首次激活时，由平台自动加载其典型请求样本（如 OpenAPI Spec 中标记的高频 endpoint），在隔离沙箱中执行 warmup 循环，生成专属 profile 快照
- 灰度发布新版本模型或 SDK 时，JIT 配置（如 opcache.jit=1255）必须按租户分组启用，不可全量推送；支持 per-tenant 的 JIT 参数热更新（无需重启进程）
- 禁止跨租户共享 preload 脚本——每个租户的 opcache.preload 文件应独立编译，且加载时校验租户签名，防止恶意覆盖
可观测性必须穿透租户维度
没有租户标签的 JIT 日志等于无日志。所有底层指标需强制打标：
- 每条 JIT 编译日志必须含 tenant_id、method_fqn、trigger_reason（call_count / loop_backedge / inline_depth）
- 暴露 /metrics/jit?tenant=xxx 端点，返回该租户实时的编译成功率、平均编译耗时、codecache 命中率
- APM 工具（如 OpenTelemetry）需在 span 中注入 JIT 决策链路：从字节码执行 → profile 达标 → IR 生成 → 机器码发射，全程可追溯租户上下文
