不能直接查数量，gc.get_objects()返回所有被GC跟踪的活动对象引用列表，需遍历并用isinstance()过滤统计dict和list实例数，但结果包含大量运行时内部对象，实际应用中应结合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() 只是起点，不是答案。
