去破坏者？

Golang不知道大家是否熟悉？今天我将给大家介绍《去破坏者？》，这篇文章主要会讲到golang等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

问题内容

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

正确答案

在 Go 生态系统中，存在一种处理包装珍贵（和/或外部）资源的对象的普遍用法：一种指定用于释放该资源的特殊方法，通常通过该机制 显式调用。defer

这种特殊方法通常被命名为Close()，并且对象的用户在使用完对象所代表的资源后必须显式调用它。io标准包甚至有一个特殊的接口，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 类型可以具有析构函数，那么程序员需要确保析构函数执行的任何代码都与程序的其余部分正确同步——如果对象的状态影响到它外部的某些数据结构。这实际上可能会迫使程序员添加此类同步，即使对象的正常操作不需要它（并且大多数对象都属于此类）。想想那些外部数据结构在对象发生之前被破坏了会发生什么” s 析构函数被调用（GC 以不确定的方式收集死对象）。换句话说，当对象被显式编码到程序流中时，控制和推理“对象销毁”要容易得多：既可以指定何时必须销毁对象，又可以保证对象销毁的正确顺序。破坏其外部的数据结构。

如果您熟悉 .NET，它处理资源清理的方式与 Go 非常相似：包装一些宝贵资源的对象必须实现IDisposable接口，并且Dispose()由该接口导出的方法 , 必须是当你用完这样一个对象时显式调用。C# 通过语句为这个用例提供了一些语法糖，这using使得编译器安排Dispose()在对象超出所述语句声明的范围时调用对象。在 Go 中，您通常会defer调用清理方法。

还要注意一点。Go 希望你非常认真地对待错误（与大多数主流编程语言不同，它们“只是抛出一个异常，而不是 fsck 关于在其他地方发生什么以及程序将处于什么状态”的态度），所以你可能考虑检查至少 一些 对清理方法的调用的错误返回。

一个很好的例子是os.File表示文件系统上文件的类型的实例。有趣的是，由于合法原因，调用Close()打开的文件 可能会失败，如果您正在 写入 该文件，这可能表明并非您写入该文件的所有数据都实际落在 文件系统中。 如需解释，请阅读close(2)手册中的“注意事项”部分。

换句话说，只是做类似的事情

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

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

文中关于golang的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《去破坏者？》文章吧，也可关注golang学习网公众号了解相关技术文章。