CPython 3.11 无分层JIT，仅单层解释器内嵌动态特化状态机；其通过字节码执行频次与类型反馈驱动UNINITIALIZED→MONOMORPHIC→DEOPTIMIZED流转，非JVM式Tiered编译。
Python 3.11 的热点检测不是“多层”，而是单层 + 动态特化状态机
直接说结论：CPython 3.11 没有 JVM 那种明确的 Tier 1/Tier 2 分层编译（如 C1/C2），它压根不带 JIT 编译器。所谓“分层热点检测”是误传，实际是**单层解释器内嵌的自适应特化状态机**——靠字节码执行时的类型反馈和命中频次，在 UNINITIALIZED → MONOMORPHIC → DEOPTIMIZED 之间动态流转。
这个机制被部分文档或社区文章类比为“Tiered”，但容易误导人去配 JVM 式参数（比如 -XX:TieredStopAtLevel=1），在 Python 里完全无效。
为什么你会看到“Tier 1/2”说法？源头在哪
混淆主要来自三方面：
- Java 开发者迁移到 Python 后，习惯性套用 JVM 术语描述 CPython 新行为
- CPython 3.11 的源码注释里出现过
tier字样（如opcode_tier），实为内部调试标记，非公开配置项 - 某些性能分析工具（如
py-spy或自定义 trace hook）把“未特化→已特化”路径粗略标为 Tier 1/Tier 2，属于可视化映射，非运行时真实层级
真正起作用的是每条字节码指令绑定的 inline cache 状态，例如 BINARY_ADD 指令旁附带一个 32-bit 状态字段，记录最近一次操作数类型组合是否稳定。
立即学习“Python免费学习笔记（深入）”；
怎么验证当前代码是否触发了特化？别信“Tier”标签
想确认某段循环是否进入 MONOMORPHIC 快速路径，唯一可靠方式是观察执行时间突变或启用底层追踪：
- 用相同输入反复运行同一函数，首次明显慢、后续稳定快 → 很可能已特化（如
total += i在整数循环中） - 设置环境变量
PYTHONTRACE=executor，配合调试版 Python（需从源码编译并启用--with-pydebug）才能看到specialize/deoptimize日志 -
dis.dis()只能看到字节码，无法反映特化状态；sys.getsizeof()也查不到缓存内容 —— 这些状态完全在解释器 C 层维护，对 Python 层不可见
常见误区：以为加 @functools.lru_cache 或改用 array.array 就能“激活 Tier 2”，其实它们和特化解释器无关，属于应用层优化。
真正影响特化效果的关键变量只有两个
不是 CPU 核数、不是 GIL 设置、也不是 PYTHONPATH，就两个硬指标：
-
执行频次：同一条字节码需被连续执行约 100–200 次（阈值在Objects/abstract.c中硬编码为_Py_HOT_CODE_THRESHOLD），才会尝试升级状态 -
类型稳定性：操作数类型不能频繁切换。例如total += i中若i一半是int、一半是float，就会反复DEOPTIMIZED，永远卡在UNINITIALIZED
这也是为什么纯数值计算脚本提升明显（如 sum(i*i for i in range(10**6))），而混合类型 Web 请求处理（str + dict + datetime 交织）收益有限——特化只对“单调重复”的热点指令生效，不是全局加速开关。
