gc.collect() 并不总是立即释放内存，其效果取决于对象可达性、循环引用、分代回收机制、__del__方法行为及系统资源管理。
gc.collect() 并不总是“立即”释放内存，它的实际效果取决于对象的可达性、引用状态和 python 的垃圾回收策略。只有在满足特定条件时，它才能真正触发内存释放。
对象已不可达且无循环引用
当一个对象不再被任何变量、容器或栈帧引用（即完全不可达），且不参与循环引用时，Python 的引用计数机制本身就会在引用消失后立刻回收它——此时调用 gc.collect() 不会带来额外释放，因为内存早已被清理。但若该对象因循环引用而滞留（比如两个列表互相 append 对方），即使所有外部引用已删除，引用计数也不为 0；这时 gc.collect() 才真正起作用：它扫描并识别出这些不可达的循环组，将其标记为可回收，并执行销毁。
当前代中存在待回收的不可达对象
Python 的垃圾回收采用分代机制（0/1/2 三代），新对象默认在第 0 代。gc.collect() 默认只收集第 0 代；只有当该代中对象数量超过阈值，或你显式指定代数（如 gc.collect(2)），才会触发对应代的完整扫描。因此：
- 如果大量老旧对象堆积在第 2 代，但只调用 gc.collect()（无参数），它们不会被处理
- 若明确调用 gc.collect(2)，且第 2 代中存在不可达的循环引用对象，内存才可能被真正释放
对象析构函数不阻塞、无副作用
某些对象定义了 __del__ 方法。如果该方法执行缓慢、抛出异常，或内部又创建了新引用（例如把 self 存入全局列表），Python 会将该对象放入 gc.garbage 列表，跳过本次回收，甚至导致内存无法释放。这种情况下，即使调用 gc.collect()，对象也不会被销毁，内存仍被占用。
系统资源未被其他机制锁定
gc.collect() 只负责 Python 堆内对象的回收，不处理：
- 操作系统级资源（如 mmap 映射、C 扩展分配的堆外内存）
- 未关闭的文件句柄、数据库连接、网络 socket（它们占内存+系统资源）
- 由第三方库（如 numpy、pandas）缓存的底层内存块，除非其 Python 对象本身也被回收
例如：一个 pandas DataFrame 被 del 掉，但其底层 numpy 数组若被其他对象持有引用，或库内部做了内存池缓存，gc.collect() 就无法释放对应物理内存。