Python内存分析：统计dict和list数量方法

本文深入解析了如何利用 Python 的 `gc.get_objects()` 配合 `isinstance()` 统计内存中字典和列表实例数量，同时直击其局限性——结果包含大量运行时内部对象、无法覆盖未被 GC 跟踪的对象、易受垃圾回收延迟影响，且在多线程下不安全；文章不仅指出常见误用（如忽略 `gc.collect()`、错误使用 `type()` 判断类型），更强调真实调试中应聚焦“为什么这些对象不该存在”，推荐结合 `tracemalloc` 追踪分配源头、限定代际筛选、分析引用链等实用策略，帮你从徒劳数数转向精准定位内存泄漏根因。

gc.get_objects() 能查到所有 dict/list 吗

不能直接“查数量”，gc.get_objects() 返回的是当前被 GC 跟踪的**所有活动对象的引用列表**，但它不区分类型、不聚合统计、也不包含未被 GC 跟踪的对象（比如某些内置类型的小整数、短字符串、或显式调用 gc.disable() 后创建的对象）。真正能拿到的，是一大堆混杂的 dict、list、function、module 等实例。

如何用 gc.get_objects() 统计 dict 和 list 实例数

核心是遍历返回结果并用 isinstance() 过滤。注意必须传入 gc.get_objects() 的返回值（一个 list），再逐个判断：

import gc
objs = gc.get_objects()
dict_count = sum(1 for obj in objs if isinstance(obj, dict))
list_count = sum(1 for obj in objs if isinstance(obj, list))

常见错误：

• 漏掉 gc.collect() 前调用 —— 某些刚 del 掉但还没被回收的 dict/list 仍会出现在结果里，导致数量虚高
• 误用 type(obj) is dict —— 会漏掉继承自 dict 的子类实例（如某些 ORM 的映射类）
• 在多线程环境直接调用 —— gc.get_objects() 不是线程安全的，可能抛 RuntimeError

为什么统计结果常比预期多得多

因为 Python 运行时本身大量使用 dict 和 list：模块的 __dict__、函数的 __defaults__、帧对象的局部变量、甚至 gc 自身内部结构都藏有它们。你看到的“12000 个 dict”里，可能只有几十个是你代码显式创建的。

更实用的做法是限定范围：

• 用 gc.get_objects(generation=0) 只查最新一代（通常是最近分配的）
• 配合 obj.__class__.__module__ != 'builtins' 过滤掉标准库内部对象
• 对疑似泄漏点（如某个 class 实例）调用 gc.get_referrers(obj) 往上追引用链

替代方案：用 tracemalloc + gc 更准定位新增 dict/list

如果目标是“排查内存增长”，靠静态快照统计意义有限。推荐组合：

import gc, tracemalloc
tracemalloc.start()
# ... 执行可疑操作 ...
gc.collect()
stats = tracemalloc.take_snapshot().statistics('traceback')
# 然后过滤出分配了 dict/list 的 traceback 行

这样能看到哪些代码行实际触发了 dict() 或 [] 分配，而不是单纯数存量。很多“数量异常”其实是短生命周期对象堆积（比如循环里不断新建又丢弃），gc.get_objects() 抓不到它们的生成路径。

真正难的不是数清楚有多少个 dict，而是确认哪些该活、哪些不该活——这得结合引用链和业务逻辑判断，gc.get_objects() 只是起点，不是答案。

终于介绍完啦！小伙伴们，这篇关于《Python内存分析：统计dict和list数量方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！