调用 gc.disable() 后延迟未降是因为它只禁用循环引用回收，不抑制引用计数释放，且易致内存积压引发更长STW停顿；应优先控制对象创建、消除循环引用并合理调用 set_threshold。
为什么调用 gc.disable() 后延迟没降下来？
直接关掉 GC 并不总能降低延迟，因为 Python 的垃圾回收主要影响的是 gc.collect() 触发时的停顿，而不是每次对象分配。如果程序中大量创建短生命周期对象（比如循环里拼字符串、构造临时字典），gc.disable() 反而会让内存持续上涨，最终触发更猛烈的全量回收，造成更长的 STW（Stop-The-World）停顿。
真正有效的做法是：控制触发时机 + 减少可回收对象数量 + 避免跨代扫描开销。
- 只在确定无引用环、且已知对象生命周期可控的代码段（如高频实时计算循环）中临时禁用：
gc.disable()/gc.enable() - 禁用前务必确保没有未释放的循环引用（比如闭包持有了自身、类实例互相引用），否则内存会泄漏
-
gc.disable()不影响引用计数机制，所以纯引用计数可回收的对象仍会及时释放
怎样用 gc.set_threshold() 控制回收频率？
Python GC 默认按“代际”运行：第 0 代最频繁（每分配 700 个对象触发一次），第 1、2 代依次变慢。高频延迟敏感场景下，第 0 代太激进反而导致频繁小停顿。
调高阈值能显著减少回收次数，但需权衡内存占用：
立即学习“Python免费学习笔记（深入）”；
- 查看当前阈值：
gc.get_threshold()→ 默认返回(700, 10, 10) - 降低第 0 代触发频率：
gc.set_threshold(5000, 10, 10)（注意：不是越大越好，超过 10000 容易积压太多待扫描对象） - 若确认无循环引用，可彻底关闭第 1、2 代：
gc.set_threshold(5000, 0, 0)，只保留第 0 代可控回收 - 调整后建议配合
gc.get_count()监控各代对象数，避免某一代长期不触发导致突增回收
哪些对象会强制触发 GC 扫描？如何规避？
只要对象含有 __del__ 方法、或参与了循环引用（哪怕只是两个 dict 互相赋值），就会被 GC 放入第 0 代跟踪。这类对象是延迟波动的主要来源。
- 避免在热路径中创建含
__del__的对象（如自定义资源包装类），改用contextlib.closing或显式.close() - 用
weakref.ref替代强引用循环，例如缓存中存weakref.ref(obj)而非obj - 用
collections.namedtuple或types.SimpleNamespace替代带方法的轻量类，它们不参与 GC 跟踪 - 检查是否误用了
functools.lru_cache缓存了不可哈希对象（如 dict/list），这会导致缓存项无法被清理并拖慢 GC
延迟敏感服务上线前必须验证的三件事
GC 调优不是设几个参数就完事，真实环境里容易因数据分布变化失效。
- 用
gc.set_debug(gc.DEBUG_STATS)在预发开启统计，观察日志里collected数量和耗时，确认是否真有高频小回收 - 在压测中用
tracemalloc检查 top 分配者，如果dict、list、str占比高，说明问题在业务逻辑而非 GC 参数 - 容器部署时注意：CGroup 内存限制可能触发内核 OOM Killer，此时
gc.collect()可能被系统信号中断，表现像“GC 失效”，需结合/sys/fs/cgroup/memory/memory.limit_in_bytes核对
GC 参数只是调节杠杆，真正决定延迟上限的是对象创建模式和引用结构。改代码比调参数更有效，也更容易验证。
