文件描述符泄漏的检测与预防主要依赖系统工具和规范代码实践。1. 预防方面，应无脑使用with语句管理资源，确保资源自动释放；2. 事后诊断可使用lsof、/proc/<pid>/fd/等系统工具查看打开的文件描述符；3. python内置模块如resource、gc、tracemalloc可辅助监控和调试；4. 生产环境应通过监控文件描述符数量、错误日志、psutil库等手段实现及时预警；5. 复杂情况下可通过内存快照分析定位泄漏源头。
文件描述符泄漏在Python应用中是个挺常见但又容易被忽视的问题，尤其是在长期运行的服务里。简单来说，检测它主要得靠一些系统级的工具，结合Python自身的资源管理机制，以及一些调试技巧。最直接的预防方式，当然是规范地使用上下文管理器。
要解决或检测未关闭的文件描述符，我们得从预防和事后诊断两方面入手。
预防为主：上下文管理器（with
立即学习“Python免费学习笔记（深入）”；
这是Python处理文件I/O和许多其他资源（比如锁、网络连接）的黄金法则。当你使用
with open('file.txt', 'r') as f: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
lsof -p <PID>
# 示例：查看PID为12345的进程打开了哪些文件 lsof -p 12345 | grep 'REG' # 查找普通文件 lsof -p 12345 | grep 'IPv4' # 查找IPv4网络连接
/proc/<PID>/fd/
/proc/<PID>/fd/
ls -l
lsof
netstat
Python内置模块（辅助性）
resource
RLIMIT_NOFILE
gc
gc.set_debug(gc.DEBUG_UNCOLLECTABLE)
sys.getallocatedblocks()
tracemalloc
tracemalloc
说实话，每次遇到这种问题，我都会先问自己，是不是又忘了
with
首先，最直接的影响就是资源耗尽。操作系统对单个进程能打开的文件描述符数量是有上限的（
ulimit -n
其次，性能会受影响。即使还没达到上限，大量的打开文件描述符也会增加操作系统的负担，因为它需要维护这些文件状态。文件描述符越多，查找、管理这些资源所需的时间就越长，从而拖慢整个程序的运行效率。
再者，可能会导致数据不一致或丢失。如果文件描述符没有被正确关闭，那么对文件的写入操作可能没有及时刷新到磁盘，导致数据丢失或文件内容不完整。在某些场景下，这甚至可能引发更严重的数据损坏问题。
最后，这种问题往往难以定位和复现。它通常发生在程序长时间运行后，缓慢积累，而不是立即出现。在开发环境或测试环境，由于运行时间短，并发量小，可能根本观察不到，等到上线后才爆发出来，那时候排查起来就特别头疼了。我曾遇到过一个长期运行的服务，就是因为一个小小的文件操作没用
with
预防胜于治疗，这话放在文件描述符泄漏上再合适不过了。在代码写出来的那一刻，就得把这个意识刻进DNA里。
无脑使用 with
with
__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 <PID> | wc -l
OSError: [Errno 24] Too many open files
/proc/<PID>/fd
ls -l /proc/<PID>/fd/
应用内部度量：
psutil
psutil
import psutil; p = psutil.Process(); print(p.num_fds())
事后分析与调试：
py-spy
objgraph
_io.BufferedReader
_io.TextIOWrapper
socket.socket
总的来说，处理文件描述符泄漏，预防是第一位的，监控是第二位的，而高效的诊断工具则是你最后的防线。
以上就是怎样用Python检测未关闭的文件描述符？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
333
收藏
