Ruby的File.open和对f.close的需求

在大多数编程语言中，众所周知，处理文件的流程是开放使用关闭的。但是我在ruby代码中多次看到无与伦比的File.open调用，而且我在ruby文档中发现了这一知识宝典：

当垃圾回收器声明I / O流时，它们会自动关闭。

darkredandyellow友好的irc解决了这个问题：
[17:12]是的，而且，文件描述符的数量通常受操作系统限制
[17:29]我假设您可以在垃圾收集器清理之前很容易用完可用的文件描述符向上。在这种情况下，您可能要自己使用关闭它们。“被垃圾收集者宣称。” 表示GC在将来的某个时候起作用。而且很贵 显式关闭文件的很多原因。

1. 我们是否需要明确关闭
2. 如果是，那么GC为什么会自动关闭？
3. 如果没有，那为什么要选择呢？

我在红宝石代码中多次看到无与伦比的File.open呼叫

能给我举个例子吗？我只在新手编写的代码中看到过这些新手，他们缺乏 “大多数编程语言中的常识，即处理文件的流程是开放使用-关闭”。

经验丰富的Rubyist要么明确关闭文件，要么更习惯于使用的块形式File.open，它会自动为您关闭文件。它的实现基本上看起来像这样：

def File.open(*args, &block)
  return open_with_block(*args, &block) if block_given?
  open_without_block(*args)
end

def File.open_without_block(*args)
  # do whatever ...
end

def File.open_with_block(*args)
  yield f = open_without_block(*args)
ensure
  f.close
end

脚本是一种特殊情况。脚本通常运行时间很短，并且使用的文件描述符很少，以至于根本无法关闭它们，因为无论如何，脚本退出时操作系统都会关闭它们。

我们需要显式关闭吗？

是。

如果是，那么GC为什么会自动关闭？

因为在收集了对象之后，您再也无法关闭文件，因此您将泄漏文件描述符。

请注意，关闭文件的不是垃圾收集器。垃圾收集器在收集对象之前仅对对象执行任何终结器。碰巧的是File该类定义了一个终结器来关闭文件。

如果没有，那为什么要选择呢？

因为浪费的内存很便宜，但是浪费的文件描述符却不是。因此，将文件描述符的生存期与某些内存块的生存期联系起来是没有意义的。

你根本无法预测，当垃圾收集器将运行。你甚至不能预测，如果它将运行在所有的：如果你从来没有的内存用完，垃圾收集器将永远不会运行，因此终结永远不会运行，因此该文件将永远不会被关闭。

使用后，您应始终关闭文件描述符，这也会刷新它。人们通常将File.open或等效方法与块一起使用来处理文件描述符寿命。例如：

File.open('foo', 'w') do |f|
    f.write "bar"
end

在该示例中，文件自动关闭。

根据http://ruby-doc.org/core-2.1.4/File.html#method-c-open

没有关联的块，File.open是:: new的同义词。如果给出了可选代码块，它将作为参数传递给打开的文件，并且当该块终止时，File对象将自动关闭。该块的值将从File.open返回。

因此，当块终止时将自动关闭：D

1. 是
2. 如果您不这样做，或者出现其他故障
3. 见2。

我们可以使用该File.read()函数读取红宝石文件.....，例如，

file_variable = File.read("filename.txt")

在此示例中，file_variable可以具有该文件的完整值。