你有没有遇到过在使用pandas的时候批处理任务跑完了del df执行了甚至还使用了import gc; gc.collect()但是进程内存确没有减少。我们首先就会想到这可能是pandas 有内存泄漏其实这不一定就是泄漏。可能是引用、分配器的正常行为。而且在pandas 3.0 之后这类情况更多了因为Copy-on-Write 改变了数据共享的方式Arrow 支持的 dtype 让内存行为变得更难预测。RSS 不是正在使用的内存很多人把 RSS 当成实际内存占用来看这是问题的根源。RSS 是操作系统报告的常驻内存大小而Python 对象实际需要多少内存是另一回事。分配器为了提高效率会预留一大块内存池arena以备后用。删掉一个 DataFramePython 层面的对象确实释放了但 RSS 不一定下降因为分配器Python 的、NumPy 的、Arrow 的、libc 的只是把这块内存标记为可重用并没有还给操作系统。这就解释了一个常见现象监控面板上看着像在泄漏但程序跑得好好的吞吐量很稳定。内存在进程内部被重复利用RSS 高位运行其实是正常的。Copy-on-Write 带来的认知陷阱pandas 3.0 默认启用了 Copy-on-Write。从用户角度看索引操作和很多方法都像是返回了副本不用再担心意外修改原数据。听起来很好但这里有个容易忽略的点CoW 改善的是行为安全性跟内存什么时候释放没有直接关系。底层实现上CoW 会让多个 DataFrame 或 Series 共享同一块数据缓冲区直到某个对象发生写操作才触发真正的复制。换句话说你以为创建了好几个独立的副本实际上它们可能都指向同一块内存。只要任意一个派生对象还活着这块内存就不会被释放。哪删掉了主 DataFrame没用的如果某个 Series 切片还在作用域里那一大块缓冲区照样活得好好的。最常见的假泄漏视图比主对象活得久import pandas as pd df pd.DataFrame({a: range(10_000_000), b: range(10_000_000)}) view df[[a]] # looks small, but can keep dfs blocks alive del df # you expect memory drop # view still references the underlying data, so buffers can remain这是实际使用的时候碰到最多的情况。一个看起来人畜无害的 view实际上在底层持有整个大表的数据块引用。你删掉了 df但 view 没删内存就这么留着了。那些不是副本的副本即便不考虑 CoWpandas 本身就有很多这类行为操作返回的对象可能共享底层数据块或者内部维护着某些引用。而Python 变量只是冰山一角。闭包、缓存字典、全局变量、异步任务这些任何一个都可能悄悄地让对象存活下去。几个高频踩坑场景把中间结果存进列表方便调试snapshots [] for chunk in chunks: df transform(chunk) snapshots.append(df) # you keep every chunk alive每个 chunk 都活着内存持续增长。按用户 ID 或任务 ID 缓存结果开发阶段觉得挺聪明上了生产变成了内存博物馆——只进不出。还有一种是 GroupBy 加上一长串 apply 链式调用中间产生大量临时对象GC 来不及回收尤其在循环里更明显。Arrow buffers快是真快粘也是真粘pandas 3.0 默认启用了专用的 string dtype装了 PyArrow 的话字符串列会用 Arrow 作为底层存储。性能和内存效率都有提升但代价是内存行为变得更复杂。Arrow 有自己的缓冲区管理和内存池机制。你可能会看到这种诡异的现象pyarrow.total_allocated_bytes()显示 Arrow 那边已经释放得差不多了但psutil.Process().memory_info().rss却一直往上涨。这不一定是泄漏更可能是内存池化加上碎片化加上延迟释放的综合效果。双缓冲区从 Parquet 读数据是很常见的操作。先读成 Arrow Table再转成 pandas DataFrame如果两个对象都留在作用域里等于同一份数据在内存中存了两遍。import pyarrow.parquet as pq table pq.read_table(big.parquet) df table.to_pandas() # now you may hold Arrow buffers pandas objects # If table stays referenced, memory wont drop as you expect解决方法也很简单转换完就 del 掉源对象。排查检查清单与其凭直觉猜测不如系统地排查。第一步确认到底是持续增长还是一次性的高水位。同一个进程里把任务跑两遍如果第一遍 RSS 上升、第二遍稳定那多半是分配器在重用内存不是泄漏。如果 RSS 随着工作量线性增长那确实有东西在不断积累——可能是真正的泄漏也可能是某个无限增长的缓存。第二步关注对象引用而不是内存数字。用gc.get_objects()采样观察对象数量变化趋势用tracemalloc追踪 Python 层面的分配模式用objgraph找出哪些类型在增长、被谁持有。第三步区分 Python 堆和原生缓冲区。Python 分配可以用 tracemalloc 和 pympler 看进程 RSS 用 psutilArrow 的内存用pyarrow.total_allocated_bytes()。如果 Python 层面很平稳但 RSS 在涨问题多半出在原生内存池或碎片上。第四步排查意外引用。DataFrame 或 Series 有没有被存进全局变量、类属性或者某个缓存字典有没有往列表里追加数据忘了清理lambda 或回调函数有没有闭包了 df有没有返回的对象内部持有大对象的引用第五步实在搞不定就用进程隔离。跑 Arrow/Parquet 密集型任务时把工作放到 worker 进程里定期回收 worker比如每处理 N 个文件就重启一次让操作系统来当垃圾收集器。总结pandas 的内存泄漏多数时候是下面几种情况视图或切片持有大缓冲区的引用导致无法释放Copy-on-Write 机制让数据共享的时间比预想的长Arrow 或其他原生分配器即使对象释放后仍保留内存池缓存、列表、闭包、长期任务导致对象被意外持有。真正有效的应对方式不是gc.collect()而是缩短对象生命周期避免无意间保留引用测量正确的指标必要时用进程回收来兜底。https://avoid.overfit.cn/post/44a0a3f2e4544cbe9307e9afe262779bby Nikulsinh Rajput