去破坏者？

Question

我知道 Go 中没有析构函数，因为技术上没有类。因此，我使用 initClass执行与构造函数相同的功能。但是，有没有办法在终止的情况下创建一些东西来模拟析构函数，例如用于关闭文件？现在我只是打电话defer deinitClass ，但这是相当骇人听闻的，我认为这是一个糟糕的设计。什么是正确的方法？

Answer 1

在 Go 生态系统中，有一个无处不在的习惯用法来处理包装珍贵(和/或外部)资源的对象:一种专门用于释放该资源的特殊方法，显式调用 - 通常通过 defer机制。
这种特殊方法通常命名为 Close() ，并且对象的用户在完成对象所代表的资源后必须显式调用它。 io标准包甚至有一个特殊的接口(interface)， io.Closer ，声明那个单一的方法。在 TCP 套接字、UDP 端点和文件等各种资源上实现 I/O 的对象都满足 io.Closer ，并且预计是明确的 Close d 使用后。
调用这样的清理方法通常是通过 defer 完成的。保证方法将运行的机制，无论在获取资源后执行的某些代码是否会panic()或不。
您可能还会注意到，在 Go 中没有隐式“析构函数”与没有隐式“构造函数”相当平衡。这实际上与 Go 中没有“类”无关:语言设计者只是尽可能地避免使用魔法。

请注意，Go 解决此问题的方法可能看起来技术含量较低，但实际上它是具有垃圾收集功能的运行时唯一可行的解​​决方案。在有对象但没有 GC 的语言中，比如 C++，销毁对象是一个定义明确的操作，因为对象在超出范围或 delete 时被销毁。在其内存块上调用。在带有 GC 的运行时中，对象将在将来的某个几乎不确定的点被 GC 扫描销毁，并且可能根本不会被销毁。因此，如果对象包装了一些宝贵的资源，那么该资源可能会在最后一次对封闭对象的实时引用丢失之后被回收，甚至可能根本不会被回收——正如@twotwotwo 在他们各自的回答。
另一个需要考虑的有趣方面是 Go 的 GC 是完全并发的(与常规程序执行)。这意味着将要收集死对象的 GC 线程可能(并且通常不会)不是在该对象处于事件状态时执行该对象代码的线程。反过来，这意味着如果 Go 类型可以有析构函数，那么程序员需要确保析构函数执行的任何代码都与程序的其余部分正确同步——如果对象的状态影响它外部的一些数据结构。这实际上可能会迫使程序员添加此类同步，即使对象的正常操作不需要它(并且大多数对象都属于此类)。想想那些在对象的析构函数被调用之前碰巧被销毁的外部数据结构会发生什么(GC 以非确定性的方式收集死对象)。换句话说，当对象销毁被明确编码到程序流中时，它更容易控制和推理:既用于指定何时必须销毁对象，也用于保证销毁的正确顺序。它外部的数据结构。
如果您熟悉 .NET，它处理资源清理的方式与 Go 非常相似:包装一些宝贵资源的对象必须实现 IDisposable接口(interface)和方法，Dispose()由该接口(interface)导出，当您完成此类对象时，必须显式调用。 C# 通过 using 为这个用例提供了一些语法糖。使编译器安排调用 Dispose() 的语句当对象超出上述语句声明的范围时。在 Go 中，您通常会 defer调用清理方法。

还有一个注意事项。 Go 希望您非常认真地对待错误(与大多数主流编程语言的 "just throw an exception and don't give a fsck about what happens due to it elsewhere and what state the program will be in" attitude 不同)，因此您可能会考虑检查至少一些对清理方法的调用的错误返回。
一个很好的例子是 os.File 的实例。表示文件系统上的文件的类型。有趣的是，拨打 Close()由于合法原因，打开文件可能会失败，如果您正在写入该文件，这可能表明并非您写入该文件的所有数据实际上都已进入文件系统。有关解释，请阅读 close(2) manual 中的“注释”部分。 .
换句话说，只是做类似的事情

fd, err := os.Open("foo.txt")
defer fd.Close()

在 99.9% 的情况下，只读文件是可以的，但是对于为写入而打开的文件，您可能需要实现更多涉及的错误检查和一些处理它们的策略(仅报告、等待然后重试、询问然后-也许-重试或其他)。