文件描述符泄漏的检测与预防主要依赖系统工具和规范代码实践。1. 预防方面，应无脑使用with语句管理资源，确保资源自动释放；2. 事后诊断可使用lsof、/proc//fd/等系统工具查看打开的文件描述符；3. python内置模块如resource、gc、tracemalloc可辅助监控和调试；4. 生产环境应通过监控文件描述符数量、错误日志、psutil库等手段实现及时预警；5. 复杂情况下可通过内存快照分析定位泄漏源头。
文件描述符泄漏在Python应用中是个挺常见但又容易被忽视的问题，尤其是在长期运行的服务里。简单来说，检测它主要得靠一些系统级的工具，结合Python自身的资源管理机制，以及一些调试技巧。最直接的预防方式，当然是规范地使用上下文管理器。
解决方案
要解决或检测未关闭的文件描述符，我们得从预防和事后诊断两方面入手。
预防为主：上下文管理器（
with
语句）
立即学习“Python免费学习笔记（深入）”；
这是Python处理文件I/O和许多其他资源（比如锁、网络连接）的黄金法则。当你使用
with open('file.txt', 'r') as f:
这样的结构时，Python会确保文件在
with
块结束时（无论正常结束还是发生异常）被正确关闭。这比手动调用
f.close()
要靠谱得多，因为你永远不会忘记关闭它，也不用担心异常导致文件未关闭的情况。我个人觉得，任何时候只要能用
with
，就别犹豫。
# 推荐做法：使用 with 语句try: with open('my_log.txt', 'a') as f: f.write('这是一条日志。n') # 文件在这里会自动关闭except IOError as e: print(f"写入文件时发生错误: {e}")# 不推荐做法：手动管理，容易出错# f = open('another_log.txt', 'a')# try:# f.write('另一条日志。n')# finally:# f.close() # 如果这里忘记了，或者在f.write()之前就出错，文件就没关
事后诊断与调试：
系统级工具（最有效）
lsof
(Linux/macOS): 这是我最常用的工具。
lsof -p
可以列出某个进程打开的所有文件描述符，包括普通文件、网络连接、管道等等。如果你发现某个进程的文件描述符数量异常增长，或者有很多不该打开的文件，那十有八九就是泄漏了。
# 示例：查看PID为12345的进程打开了哪些文件lsof -p 12345 | grep 'REG' # 查找普通文件lsof -p 12345 | grep 'IPv4' # 查找IPv4网络连接
/proc//fd/
(Linux): 在Linux上，你可以直接进入
/proc//fd/
目录，这里会列出该进程所有打开的文件描述符，每个都是一个指向实际文件的符号链接。你可以
ls -l
看看它们指向哪里。这比
lsof
更底层，但有时也更直观。
netstat
(Windows/Linux): 主要用于查看网络连接，但网络连接本质上也是文件描述符。
Python内置模块（辅助性）
resource
模块 (Unix-like): 可以用来查询或设置进程的资源限制，比如
RLIMIT_NOFILE
（最大文件描述符数量）。虽然不能直接检测泄漏，但可以帮你了解当前进程的限制，以及是否快要触及上限。
gc
模块：
gc.set_debug(gc.DEBUG_UNCOLLECTABLE)
可以帮助你发现那些因为循环引用而无法被垃圾回收的对象。虽然不直接针对文件描述符，但如果一个文件对象因为循环引用而无法被回收，那它的文件描述符就可能一直开着。
sys.getallocatedblocks()
或
tracemalloc
：
tracemalloc
是Python 3.4+ 提供的内存跟踪工具，它可以告诉你哪些代码行分配了最多的内存。如果你的文件对象占用了大量内存（虽然文件描述符本身不占太多内存，但文件内容可能占），这也能提供一些线索。
为什么文件描述符泄漏是个大问题？
说实话，每次遇到这种问题，我都会先问自己，是不是又忘了
with
语句？文件描述符泄漏这玩意儿，就像个隐形的定时炸弹，平时没啥动静，一旦积累到一定程度，‘砰’地一下，你的服务就挂了。
首先，最直接的影响就是资源耗尽。操作系统对单个进程能打开的文件描述符数量是有上限的（
ulimit -n
）。一旦你的程序打开的文件描述符超过这个限制，它就无法再打开任何新的文件、建立新的网络连接，甚至连日志都写不进去，直接报错“Too many open files”。这会导致服务彻底瘫痪，用户请求无法响应，业务中断。
其次，性能会受影响。即使还没达到上限，大量的打开文件描述符也会增加操作系统的负担，因为它需要维护这些文件状态。文件描述符越多，查找、管理这些资源所需的时间就越长，从而拖慢整个程序的运行效率。
再者，可能会导致数据不一致或丢失。如果文件描述符没有被正确关闭，那么对文件的写入操作可能没有及时刷新到磁盘，导致数据丢失或文件内容不完整。在某些场景下，这甚至可能引发更严重的数据损坏问题。
最后，这种问题往往难以定位和复现。它通常发生在程序长时间运行后，缓慢积累，而不是立即出现。在开发环境或测试环境，由于运行时间短，并发量小，可能根本观察不到，等到上线后才爆发出来，那时候排查起来就特别头疼了。我曾遇到过一个长期运行的服务，就是因为一个小小的文件操作没用
with
，积累下来就把服务器搞崩了。那种找问题的过程，简直是噩梦。
如何在开发阶段就避免文件描述符泄漏？
预防胜于治疗，这话放在文件描述符泄漏上再合适不过了。在代码写出来的那一刻，就得把这个意识刻进DNA里。
无脑使用
with
语句： 真的，这是最简单也最有效的办法。无论是打开文件、建立数据库连接（很多ORM或DB API也支持上下文管理器）、还是处理网络套接字，只要涉及到需要“打开”和“关闭”的资源，优先考虑
with
语句。Python的上下文管理器协议（
__enter__
和
__exit__
方法）就是为此而生的。如果你自己写了一个类，里面管理着某种资源，也应该考虑实现这个协议，让你的类也能被
with
语句管理。
# 示例：自定义一个简单的上下文管理器class MyResource: def __init__(self, name): self.name = name self.file = None def __enter__(self): print(f"资源 {self.name} 已打开。") self.file = open(f"{self.name}.log", "a") return self.file def __exit__(self, exc_type, exc_val, exc_tb): if self.file: self.file.close() print(f"资源 {self.name} 已关闭。") if exc_type: print(f"退出时发生异常: {exc_val}") return False # 不抑制异常with MyResource("test_log") as f: f.write("一些测试内容。n") # raise ValueError("模拟一个错误") # 试试看抛出异常，__exit__也会执行
严格的代码审查（Code Review）： 在团队协作中，代码审查是发现这类问题的绝佳时机。Reviewer应该特别关注文件I/O、网络操作等部分，检查是否所有资源都使用了
with
或
try...finally
进行了妥善关闭。有时候，你觉得一个文件操作就是那么简单，写完就完了，但现实往往会给你一记响亮的耳光，一个小小的疏忽就能埋下大隐患。
单元测试和集成测试： 编写测试用例时，可以模拟长时间运行或高并发场景。虽然直接测试文件描述符泄漏有点复杂，但你可以测试资源是否被正确释放。例如，对于一个处理文件的函数，测试它在执行前后，文件是否真的被关闭了。或者，在测试结束后，检查进程打开的文件描述符数量是否回到了基线水平（虽然这在隔离的单元测试中可能很难做到）。
使用静态分析工具（Linting）： Pylint、Flake8等工具虽然不直接检测文件描述符泄漏，但它们可以配置规则来检查一些常见的资源管理反模式，比如没有
with
语句的
open()
调用。这能提供一个初步的预警。
生产环境中如何监控和定位文件描述符泄漏？
在生产环境，当问题真正发生时，你最需要的是快速定位和止损。
系统级监控：
监控进程文件描述符数量： 这是最直接的指标。你可以通过
lsof -p | wc -l
命令获取某个进程当前打开的文件描述符数量，然后将其作为监控指标（比如Prometheus或Grafana）定期采集。如果这个数字持续上涨，或者突然飙升，那基本可以确定有泄漏了。监控错误日志： 当文件描述符耗尽时，你的应用程序通常会抛出
OSError: [Errno 24] Too many open files
这样的错误。确保你的日志系统能捕获并告警这类错误。这是最直接的信号。
/proc//fd
目录检查： 当告警触发后，SSH到服务器上，直接
ls -l /proc//fd/
就能看到当前进程打开了哪些文件。通过这些符号链接，你可以大致判断是哪些文件类型（日志文件、数据库连接、网络套接字等）在泄漏，从而缩小排查范围。
应用内部度量：
psutil
库： Python的
psutil
库提供了一个跨平台的接口来获取进程信息。你可以用它来获取当前进程打开的文件数量：
import psutil; p = psutil.Process(); print(p.num_fds())
。将这个数值暴露给你的监控系统，可以实现更精细的应用层监控。自定义计数器： 如果你对某些特定的文件操作（比如某个模块独有的文件处理）特别不放心，可以在代码中手动维护一个计数器，每打开一个文件就加1，每关闭一个文件就减1。然后将这个计数器暴露出来。这有点像埋点，虽然麻烦，但在关键路径上可能很有用。
事后分析与调试：
py-spy
： 这是一个非侵入式的Python采样分析器。虽然主要用于CPU性能分析，但它也能帮助你理解程序在做什么，如果某个文件操作相关的函数长时间出现在栈顶，或者有大量文件相关的对象被创建，可能会提供一些线索。内存快照/堆分析： 在一些极端情况下，你可以尝试在泄漏发生时，对Python进程进行内存快照，然后使用像
objgraph
这样的工具来分析内存中的对象。查找
_io.BufferedReader
、
_io.TextIOWrapper
或
socket.socket
等文件或网络相关的对象实例，看看它们是不是不该存在却依然存在，并且追踪它们的引用链，就能找到泄漏的源头。这通常是比较复杂的调试手段，但非常有效。
总的来说，处理文件描述符泄漏，预防是第一位的，监控是第二位的，而高效的诊断工具则是你最后的防线。
以上就是怎样用Python检测未关闭的文件描述符？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1367666.html
微信扫一扫 
支付宝扫一扫 
