Go destructors

在围棋生态系统中，有一个无处不在的习惯用法，用于处理包装宝贵(和/或外部)资源的对象:指定用于释放该资源的特殊方法，称为explicitly-通常通过defer机制.

这种特殊的方法通常被命名为Close()，对象的用户在使用完对象所代表的资源后，必须显式地调用它.io标准包甚至有一个特殊的接口io.Closer，用于声明单一方法.在各种资源(如TCP套接字、UDP端点和文件)上实现I/O的对象都满足io.Closer，并且在使用后预期显式地达到Closed.

调用这样的清理方法通常是通过defer机制完成的，这保证了无论在资源获取之后执行的某些代码是否将panic()，该方法都将运行.

您可能还注意到，在GO中没有隐式"析构函数"相当于没有隐式"构造函数".这实际上与围棋中没有"类"没有任何关系:语言设计者实际上只是尽可能避免magic个.

请注意，Go解决这个问题的方法可能技术含量较低，但事实上，对于以垃圾收集为特色的运行时，它是唯一可行的解决方案.在一个有对象但没有GC的语言中，比如C++， destruct 对象是一个定义良好的操作，因为对象在其超出范围时被 destruct ，或者当它的内存块被调用delete时.在使用GC的运行时中，该对象将在future 的某个主要不确定的点被GC扫描 destruct ，因此如果该对象包装了一些宝贵的资源，那么该资源可能会在对封闭对象的最后一次实时引用丢失的那一刻被回收，正如@twoo在他们各自的回答中所解释的那样，它甚至可能根本不会被回收.

另一个需要考虑的有趣方面是，GO的GC是完全并发的(与常规程序执行一起).这意味着将要收集死对象的GC线程可能(通常也会)不是在该对象处于活动状态时执行其代码的线程.反过来，这意味着如果Go类型可以有析构函数，那么程序员将需要确保析构函数执行的任何代码都与程序的睡觉正确同步-如果对象的状态影响到它外部的某些数据 struct .这实际上可能会迫使程序员添加这样的同步，即使对象的正常操作并不需要它(并且大多数对象都属于这种类别).并考虑在调用对象的析构函数(GC以不确定的方式收集死对象)之前被销毁的那些外部数据 struct 会发生什么情况.换句话说，当对象销毁被显式编码到程序流中时，控制对象销毁和推理对象销毁要容易得多:这既是为了指定何时必须销毁对象，也是为了确保与销毁外部数据 struct 相关的销毁的正确顺序.

如果您熟悉.NET，它处理资源清理的方式与Go非常相似:包装一些宝贵资源的对象必须实现IDisposable接口，并且在处理完这样的对象时，必须显式调用由该接口导出的方法Dispose().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个错误)，因此您可以考虑判断至少some个清除方法调用的错误返回.

表示文件系统上的文件的os.File类型的实例就是一个很好的例子.有趣的是，在打开的文件might上调用Close()会因为合法的原因而失败，如果您对该文件是writing，这可能表示并非所有写入该文件的数据实际上都到达了该文件on the file system.中以获得解释，请阅读close(2) manual中的"注释"部分.

换句话说，只是做一些

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

在99.9%的情况下，只读文件是可以的，但对于打开以进行写入的文件，您可能希望实施更复杂的错误判断和一些处理策略(仅报告、等待然后重试、询问然后重试或其他).