Python 3.15 预览版带来了新的采样分析器。它不再要求程序为每个函数调用记录完整事件，而是定期采集运行中的调用栈，再用统计结果回答一个更适合生产排障的问题：程序的大部分时间究竟消耗在哪里？
这套工具覆盖 CPU 分析、GIL 分析、火焰图、热力图，以及附加到正在运行的进程。理解这些模式的差别，才能避免把“CPU 忙”误判成“Python 代码慢”，或把 GIL 等待误判成普通锁竞争。
采样分析器解决什么问题
传统的确定性分析会记录大量函数调用和返回事件，定位细节很精确，但额外开销也可能改变被观测程序的行为。采样分析器采用另一种策略：每隔一段时间查看线程当前的调用栈，并累计各个栈帧出现的次数。
因此，采样结果更像是“时间预算表”：某个函数及其调用路径出现得越频繁，说明程序越可能把时间花在那里。它特别适合处理以下场景：
- 服务已经运行起来，需要低侵入地观察热点。
- 任务执行时间较长，完整调用记录成本过高。
- 需要快速回答“哪个调用路径最值得优化”。
- 希望从图形化结果中观察热点，而不是阅读长篇文本日志。
采样分析的边界也很明确：短暂执行的函数可能一次都没有被采到；采样结果是统计估计，不是每一次调用的完整证明。调整采样频率可以在细节和开销之间取得平衡，但不能让它变成确定性分析器。
CPU 模式与 GIL 模式
CPU 模式关注线程实际消耗处理器时间的位置。看到某个函数在火焰图中占据较宽区域，通常意味着它所在的调用路径频繁出现在采样结果中，可能是 Python 字节码、C 扩展，或者底层库执行时间较多。
GIL 模式回答的是另一个问题：线程是否因为全局解释器锁而等待。一个多线程服务可能整体 CPU 使用率不高，但多个线程仍然无法有效并行执行 Python 代码；这时 CPU 热点和 GIL 等待热点并不一定相同。
可以用下面这段程序制造一个容易观察的 CPU 工作负载。代码本身可以直接运行；实际分析命令请以所使用的 Python 3.15 预览构建版本帮助信息为准，因为预览阶段的命令行参数可能继续调整。
# workload.py
import math
import time
def cpu_work(iterations: int) -> float:
total = 0.0
for value in range(iterations):
total += math.sqrt(value + 1) * math.sin(value)
return total
def main() -> None:
deadline = time.monotonic() + 15
result = 0.0
while time.monotonic() < deadline:
result += cpu_work(50_000)
print(f"result={result:.3f}")
if __name__ == "__main__":
main()
运行负载：
python3.15 workload.py
在支持该预览特性的构建中，可以先查看分析器的实际参数，再选择 CPU 或 GIL 模式：
python3.15 -m profiling --help
python3.15 -m profiling --mode cpu workload.py
python3.15 -m profiling --mode gil workload.py
上面的 --mode 写法用于表达操作流程；如果你的预览版本使用子命令或不同选项名称，应以 --help 输出为准。关键不是死记参数，而是明确分析目标：要找计算热点时使用 CPU 视角，要检查线程是否被 GIL 阻塞时使用 GIL 视角。
如何读火焰图和热力图
火焰图把调用栈组织成横向区域。通常可以这样读：
- 横向宽度代表采样数量，越宽通常意味着累计时间越多。
- 纵向高度代表调用栈深度，越往上越接近当前正在执行的函数。
- 从宽区域向下追踪，可以找到是谁调用了热点函数。
- 不要只盯着最顶层函数；真正有价值的线索往往是完整调用路径。
火焰图适合回答“时间集中在哪些调用栈”。热力图则更适合观察热点分布，例如不同线程、不同时间段或不同调用区域是否持续繁忙。分析并发程序时，热力图可以帮助区分持续性热点和偶发尖峰。
一个常见误区是把火焰图的宽度理解成单次调用耗时。采样器看到的是多次采样的累计结果，所以宽度通常表示统计意义上的时间占比，而不是某一次请求的精确耗时。
附加到正在运行的进程
对线上服务而言，最有价值的能力之一是附加到已经运行的进程。这样可以在不重启服务、不提前修改启动命令的情况下，获取一段时间内的采样数据。
实践时需要关注几个条件：
- 分析进程和工具通常需要匹配的用户权限。
- 容器或沙箱环境可能限制读取目标进程信息。
- 采样会产生开销，生产环境应设置有限的采样时长。
- 进程退出、重启或 PID 被复用时，采样结果可能失效。
- 采样数据可能包含模块名、函数名和业务调用路径，需要按日志和诊断数据的安全要求处理。
可以先启动一个持续运行的进程：
python3.15 -c 'import time; time.sleep(300)' &
PID=$!
printf 'target pid: %s\n' "$PID"
随后使用预览构建提供的附加模式。下面的命令展示了应有的操作形态，具体选项仍以本地版本为准：
python3.15 -m profiling --attach "$PID" --mode cpu --duration 10 --output cpu-profile.json
python3.15 -m profiling --attach "$PID" --mode gil --duration 10 --output gil-profile.json
建议先在测试环境验证附加权限、输出格式和可视化流程，再把它纳入线上诊断手册。对于高流量服务，短时间、多次采样通常比一次长时间采样更容易控制风险，也便于比较部署前后的变化。
一份可执行的采用清单
把 Python 3.15 采样分析器加入排障流程时，可以按下面的顺序操作：
- 使用与线上应用一致的 Python 3.15 预览构建，在测试环境复现负载。
- 先运行 CPU 模式，确认最宽的调用路径和主要业务动作是否一致。
- 多线程问题再运行 GIL 模式，区分计算热点与锁等待。
- 使用火焰图定位调用链，用热力图观察线程或时间上的分布。
- 设置固定采样时长，并保存命令、版本、负载和环境信息。
- 不要只依据一次采样下结论，至少用两次运行或不同负载进行对比。
- 优化后重新采样，验证热点是否移动，以及吞吐和延迟是否真的改善。
采样分析器的价值在于快速缩小问题范围，而不是替代基准测试、追踪系统或确定性分析。Python 3.15 仍处于预览阶段时，命令行接口和输出细节应当视为可变部分；但 CPU 视角、GIL 视角和统计采样的分析方法，已经足以帮助团队建立更可靠的性能排查习惯。