使用np.loadtxt后文件是否仍打开？如何检测文件状态？

np.loadtxt执行后文件是否仍处于打开状态？ #

这取决于你传递给np.loadtxt的参数类型：

• 若传递文件路径字符串（如np.loadtxt("a.txt")）：numpy内部会通过上下文管理器（with语句）打开文件，读取完成后自动关闭文件对象，不会遗留未关闭的文件句柄。
• 若传递手动打开的文件对象（如f = open("a.txt"); np.loadtxt(f)）：numpy不会主动关闭该文件，文件会保持打开状态，直到你手动调用f.close()或文件对象被垃圾回收。

如何检测文件是否已关闭？ #

根据场景不同，有两种检测方式：

• 持有文件对象时：直接访问文件对象的closed属性，示例代码：

  f = open("a.txt")
  print(f.closed)  # 输出False，文件未关闭
  np.loadtxt(f)
  print(f.closed)  # 输出False，numpy未关闭该文件，需手动调用f.close()
  f.close()
  print(f.closed)  # 输出True，文件已关闭
  

• numpy内部打开的文件：由于你没有文件对象的引用，无法通过Python代码直接检测，需借助系统工具查看进程的打开文件句柄：
  • Linux/macOS：执行lsof -p <进程ID>命令，查看输出中是否包含目标文件a.txt。
  • Windows：打开Process Explorer，找到目标进程后查看其「句柄」列表，确认是否存在a.txt。

关于多进程读取阻塞的额外说明 #

你遇到的600个进程阻塞问题，大概率不是numpy未关闭文件导致的，更可能的原因包括：

• 系统文件描述符限制：每个进程打开文件会占用一个文件描述符，系统默认的进程描述符上限或全局上限可能无法支撑600个进程同时打开文件。
• 磁盘IO瓶颈：大量进程并发读取同一文件会导致磁盘IO队列拥堵，进程因等待IO完成而阻塞，表现出类似锁等待的现象。
• 文件系统并发限制：部分文件系统在处理大量并发读请求时，存在内部锁机制，会导致进程排队等待。

内容的提问来源于stack exchange，提问作者Meng Mai