文件描述符是操作系统分配给进程用于访问文件、网络连接、管道等资源的整数标识。在Python程序中，打开文件、建立套接字或创建管道时都会占用文件描述符，如果使用后没有及时关闭，或者异常发生时没有正确释放，描述符数量就会逐渐增长。长期运行的程序最终可能因为达到系统上限而无法打开新的文件或连接，甚至导致服务不可用。要定位这类问题，可以在Python进程内部进行检测，也可以借助操作系统提供的命令从外部观察。下面从不同角度介绍几种常用的检测和排查方法。
一、使用psutil进行基础检测
psutil是一个跨平台的系统监控和进程管理库，除了可以获取CPU、内存、磁盘等系统信息，还能查看指定进程当前打开的文件列表。通过比较某个操作前后的文件描述符数量，可以快速判断该操作是否造成了资源泄漏。要使用psutil，需要先安装对应的包。
pip install psutil
下面的示例先获取当前进程对象，记录打开文件描述符数量，然后故意打开一个文件但不调用close方法，再次统计数量，并输出可能泄漏的文件信息。这里使用current_process.open_files()返回一个列表，每个元素包含文件路径和文件描述符等属性。如果后一次统计数量大于前一次，就说明新打开的文件没有关闭。
import psutil
import os
# 获取当前进程对象
current_process = psutil.Process(os.getpid())
# 统计打开前的文件描述符数量
before_open = len(current_process.open_files())
print(f"打开前文件描述符数量：{before_open}")
# 模拟打开文件但不关闭
f = open("test.txt", "w")
# 此处故意不调用 f.close()
# 统计打开后的文件描述符数量
after_open = len(current_process.open_files())
print(f"打开后文件描述符数量：{after_open}")
if after_open > before_open:
print("检测到未关闭的文件描述符：")
for file_info in current_process.open_files():
print(f"文件路径：{file_info.path}，文件描述符：{file_info.fd}")
这种检测方法适合在开发和调试阶段定位具体哪段代码导致了泄漏。需要注意，open_files()主要反映普通文件的打开情况，对于套接字、管道等类型的描述符可能无法完全覆盖。如果需要更全面的描述符统计，还可以结合num_fds()方法。另外，如果进程本身已经打开了大量描述符，仅依靠前后数量差异可能不够精确，此时可以进一步结合文件路径信息进行过滤，确定哪些文件没有被正确关闭。
二、上下文管理器与对象回收检测
Python的with语句通过上下文管理器协议自动管理资源，离开代码块时会调用__exit__方法释放资源。对于内建的文件对象，with open(...) as f:是推荐做法，能够有效避免忘记关闭。但对于自定义的资源类，如果没有实现__enter__和__exit__方法，即使使用with也无法自动释放，仍然可能造成描述符泄漏。
为了检测对象销毁时资源是否被正确释放，可以在类中重写__del__方法，在对象即将被垃圾回收时检查底层文件描述符是否已经关闭。如果仍然处于打开状态，说明该对象从创建到销毁都没有执行关闭操作，可以据此输出警告信息。同时结合weakref模块可以观察对象是否真的被回收，以及回收时是否触发自定义回调。下面的示例定义了一个自定义资源类，并创建弱引用来观察其回收情况。
import weakref
class CustomResource:
def __init__(self, name):
self.name = name
self.fd = open(f"{name}.txt", "w")
print(f"资源{name}初始化，分配描述符")
def close(self):
if not self.fd.closed:
self.fd.close()
print(f"资源{name}的描述符已关闭")
def __del__(self):
if hasattr(self, "fd") and not self.fd.closed:
print(f"警告：资源{self.name}被销毁时文件描述符未关闭")
def resource_finalizer(ref):
print("资源对象已被垃圾回收")
res = CustomResource("demo")
ref = weakref.ref(res, resource_finalizer)
del res
在这个示例中，CustomResource在初始化时打开文件并分配描述符，但没有在__del__中主动关闭，只是检查并输出警告。当执行del res后，对象的引用计数归零，垃圾回收机制会调用__del__。由于文件没有关闭，控制台会显示相应的警告信息。这种方式能够帮助开发者在对象生命周期结束时发现未释放的资源，但它依赖垃圾回收时机，不能作为实时检测手段，更适合用于测试和调试阶段。
三、长期运行服务的定期监控方案
对于需要长期持续运行的Web服务、后台任务或数据处理进程，单次检测很难发现缓慢增长的描述符泄漏。更实用的做法是在进程内部启动定时监控，周期性统计当前打开文件描述符数量，并根据预设阈值发出告警。这样可以在问题发展到严重阶段之前及时介入，避免影响线上服务。
下面的监控函数接受两个参数：采样间隔和告警阈值。函数内部通过psutil.Process(os.getpid())获取当前进程，进入无限循环后每隔指定时间统计一次打开文件数量。如果数量超过阈值，则打印告警信息。在实际应用中，可以将告警逻辑替换为写入日志、发送内部消息或触发运维通知等操作。
import psutil
import os
import time
def monitor_fd(interval=5, threshold=100):
process = psutil.Process(os.getpid())
while True:
fd_count = len(process.open_files())
print(f"当前文件描述符数量：{fd_count}")
if fd_count > threshold:
print(f"告警：文件描述符数量超过阈值{threshold}")
# 此处可以接入日志系统或通知服务
time.sleep(interval)
if __name__ == "__main__":
monitor_fd(interval=3, threshold=50)
该监控方案的优势在于可以自定义采样频率和阈值，适合不同负载的服务。对于高并发场景，阈值需要根据业务实际情况设置，例如一个HTTP服务可能同时保持大量连接，正常描述符数量本身就较高。此外，长期运行的服务还可以结合resource模块提供的接口获取更详细的资源使用统计，避免只依赖open_files()造成漏报。监控本身也会带来少量开销，因此采样间隔不宜设置得过短，以免影响主业务逻辑。
四、常见泄漏原因与修复建议
导致文件描述符未关闭的原因通常比较集中。第一类是打开资源后忘记调用close方法，也没有使用with语句，这类问题在代码量较大时容易被忽略。第二类是在可能抛出异常的代码中，close方法没有被放入finally块，导致异常路径下跳过关闭逻辑。第三类是自定义资源类没有实现上下文管理器协议，或者虽然实现了close但调用方仍然没有正确使用。
针对这些原因，修复建议可以归纳为以下几点。首先，优先使用with语句管理资源，因为with块结束时无论是否发生异常都会自动关闭文件，代码更简洁。其次，如果无法使用with，应当将close放在finally块中执行，确保任何情况下都能释放。第三，对于自定义的资源封装类，应当实现__enter__和__exit__方法，使其支持上下文管理器协议，并在__exit__中完成关闭动作。
# 优先使用with语句
with open("data.txt", "r") as f:
content = f.read()
# 离开with块后文件已自动关闭
# 手动管理时使用try...finally
f = open("data.txt", "r")
try:
data = f.read()
finally:
f.close()
实际开发中，还可以借助代码审查和静态检查工具来发现资源未关闭的隐患。团队内部可以约定资源管理规范，例如所有文件、网络连接和锁对象必须使用with语句或显式关闭。对历史代码进行重构时，可以优先排查频繁执行的文件操作和异常处理分支，避免因为单个资源泄漏长期累积造成系统故障。
五、使用lsof命令辅助排查
除了在Python代码内部进行检测，操作系统层面的命令也能帮助定位文件描述符问题。lsof是list open files的缩写，可以列出指定进程当前打开的所有文件描述符，包括普通文件、网络套接字、管道等，非常适合在线上环境或无法修改代码的情况下进行外部排查。它的输出信息比open_files()更底层，能够看到Python内部检测方法可能遗漏的资源类型。
例如，要查看进程ID为1234的进程打开的所有文件，可以执行以下命令。
lsof -p 1234
如果只想关注Python进程产生的文件描述符，或者输出内容较多需要过滤，可以结合grep命令进行筛选。例如下面的命令可以只显示与python相关的行。
lsof -p 1234 | grep python
使用lsof时需要注意，它列出的是操作系统层面的打开文件信息，角度更底层，能够看到Python内部open_files()可能遗漏的套接字或管道。但它的输出需要人工分析，不适合作为程序内的自动化监控手段，更适合在问题已经出现时进行定位。结合代码内部检测和系统命令，可以更完整地还原文件描述符泄漏的路径和原因。
通过本文介绍的几种方法，开发者可以根据不同场景选择合适的检测手段。在开发和测试阶段，推荐使用psutil进行快速验证，并结合weakref和__del__检测资源对象的回收情况。对于线上长期运行的服务，建议内置定期监控与告警机制，同时保留系统命令作为外部排查工具。