cProfile、line profiler、memory profiler 分别用来解决什么问题？

这个问题问得很实战，一看就是写过性能敏感服务的同学。我梳理一下自己在不同排查场景下，这三个工具的定位，尽量不堆概念，用经验串联起来。

---

🧭 一句话区分：它们在不同尺度上帮你定位问题

• 🔬 cProfile：告诉你“哪个函数”是瓶颈。

• ⚡ line_profiler：告诉你“哪一行代码”最耗时。

• 💾 memory_profiler：告诉你“哪一行代码”吃了最多内存。

当性能问题出现时，我的习惯是先用 cProfile 缩小包围圈，再用 line_profiler 精确打击，如果怀疑内存泄漏就上 memory_profiler。下面分开细说。

---

🔬 cProfile —— 宏观函数级的热点探测器

它解决的核心问题：整个程序/请求跑下来，几十上百个函数，CPU 时间都花在哪儿了？

它是标准库自带，不用安装，输出一张函数调用表，包含调用次数、总时间、自身时间等。比如你跑一个数据处理脚本，发现 90% 的时间都耗在一个 parse_json 函数上，那你就有方向了。

它的局限也很明显：它只能告诉你函数级别的耗时。如果 parse_json 里有一百行代码，你到底该优化哪一行？cProfile 解决不了，但它帮你把排查范围从“整个程序”缩小到了“一个函数”。

典型用法（不用改代码）：

python -m cProfile -s cumtime my_script.py

或者嵌入代码：

import cProfile, pstats
profiler = cProfile.Profile()
profiler.enable()
# ... 跑逻辑 ...
profiler.disable()
stats = pstats.Stats(profiler).sort_stats('cumulative')
stats.print_stats(10)

⚡ line_profiler —— 行级显微镜

它解决的核心问题：你已经定位到某个函数很慢，但它内部逻辑复杂，到底是循环开销大、还是某个计算表达式特别耗时？

line_profiler 可以逐行给出执行时间和命中次数。我印象最深的一次，是一个图像处理函数，cProfile 告诉我它很慢，我用 line_profiler 一看，发现 95% 的时间都耗在了一个嵌套循环里的 float 类型转换上，直接优化那一行，性能提升了三倍。没有它，我得靠注释代码或加计时器一行行试，效率极低。

典型用法：在需要分析的函数上加上 @profile 装饰器，然后运行：

kernprof -l -v my_script.py

输出类似：

Line #   Hits    Time  Per Hit   % Time  Line Contents
 5       1000    0.3    0.0      0.0     for item in data:
 6       1000    5.2    0.0      1.0         total = 0
 7     100000   82.5    0.0     17.8         for sub in item:
 8      99000  375.0    0.0     81.2             total += complex_calc(sub)

一眼看出第 8 行是罪魁祸首。

---

💾 memory_profiler —— 内存黑洞探测仪

它解决的核心问题：程序内存占用越来越高，或者偶尔 OOM，到底是哪个对象、哪一行代码在疯狂吃内存？

memory_profiler 同样可以做到行级的内存增量分析。它会在每一行代码执行后，记录当前进程的内存占用变化。用它我抓到过循环里反复拼接字符串导致内存翻倍的问题（改成 join 瞬间降下来），也发现过某个第三方库在初始化时预分配了巨大的缓存。

典型用法：在可疑函数上加 @profile 装饰器，然后：

python -m memory_profiler my_script.py

输出例子：

Line #    Mem usage    Increment   Line Contents
 3       45.2 MiB      0.0 MiB    def process():
 4       45.2 MiB      0.0 MiB        data = []
 5       68.9 MiB     23.7 MiB        data = [i for i in range(1000000)]

第 5 行直接告诉你列表占了多少内存。

---

🧩 三个工具的配合思路（真实排查路径）

当你面对一个“又慢又耗内存”的服务时，我的排查路径通常是：

1. 整体 CPU 打桩：先用 cProfile 跑一遍典型请求，导出火焰图或统计表，找出最耗时的 2~3 个函数。

2. 热点函数开刀：对着这些函数加 @profile（line_profiler），找到具体的耗时代码行，进行逻辑优化、向量化或缓存。

3. 内存侧写：如果怀疑内存泄漏或峰值过高，换 memory_profiler 对关键流程逐行看内存增量，找出意外持有的大对象、未释放的引用、或者可以惰性计算的数组。

一个提醒：line_profiler 和 memory_profiler 都是侵入式的，会引入较大开销，不适合在生产长期开启，只适合在开发或预发环境做剖面分析。

---