golang文件锁清除？

Golang中更好的错误处理：理论和实践技巧

云和安全管理服务专家新钛云服张春翻译

这种方法有几个缺点。首先，它可以对程序员隐藏错误处理路径，特别是在捕获异常不是强制性的情况下，例如在Python中。即使在具有必须处理的Java风格的检查异常的语言中，如果在与原始调用不同的级别上处理错误，也并不总是很明显错误是从哪里引发的。

我们都见过长长的代码块包装在一个try-catch块中。在这种情况下，catch块实际上充当goto语句，这通常被认为是有害的（奇怪的是，C中的关键字被认为可以接受的少数用例之一是错误后清理，因为该语言没有Golang-样式延迟语句）。

如果你确实从源头捕获异常，你会得到一个不太优雅的Go错误模式版本。这可能会解决混淆代码的问题，但会遇到另一个问题：性能。在诸如Java之类的语言中，抛出异常可能比函数的常规返回慢数百倍。

Java中最大的性能成本是由打印异常的堆栈跟踪造成的，这是昂贵的，因为运行的程序必须检查编译它的源代码。仅仅进入一个try块也不是空闲的，因为需要保存CPU内存寄存器的先前状态，因为它们可能需要在抛出异常的情况下恢复。

如果您将异常视为通常不会发生的异常情况，那么异常的缺点并不重要。这可能是传统的单体应用程序的情况，其中大部分代码库不必进行网络调用——一个操作格式良好的数据的函数不太可能遇到错误（除了错误的情况）。一旦您在代码中添加I/O，无错误代码的梦想就会破灭：您可以忽略错误，但不能假装它们不存在！

try{

doSometing()

}catch(IOExceptione){

//ignoreit

}

与大多数其他编程语言不同，Golang接受错误是不可避免的。如果在单体架构时代还不是这样，那么在今天的模块化后端服务中，服务通常和外部API调用、数据库读取和写入以及与其他服务通信。

以上所有方法都可能失败，解析或验证从它们接收到的数据（通常在无模式JSON中）也可能失败。Golang使可以从这些调用返回的错误显式化，与普通返回值的等级相同。从函数调用返回多个值的能力支持这一点，这在大多数语言中通常是不可能的。Golang的错误处理系统不仅仅是一种语言怪癖，它是一种将错误视为替代返回值的完全不同的方式！

重复iferr!=nil

对Go错误处理的一个常见批评是被迫重复以下代码块：

res,err:=doSomething()

iferr!=nil{

//Handleerror

}

对于新用户来说，这可能会觉得没用而且浪费行数：在其他语言中需要3行的函数很可能会增长到12行：

这么多行代码！这么低效！如果您认为上述内容不优雅或浪费代码，您可能忽略了我们检查代码中的错误的全部原因：我们需要能够以不同的方式处理它们！对API或数据库的调用可能会被重试。

有时事件的顺序很重要：调用外部API之前发生的错误可能不是什么大问题（因为数据从未通过发送），而API调用和写入本地数据库之间的错误可能需要立即注意，因为这可能意味着系统最终处于不一致的状态。即使我们只想将错误传播给调用者，我们也可能希望用失败的解释来包装它们，或者为每个错误返回一个自定义错误类型。

并非所有错误都是相同的，并且向调用者返回适当的错误是API设计的重要部分，无论是对于内部包还是RESTAPI。

不必担心在你的代码中重复iferr!=nil——这就是Go中的代码应该看起来的样子。

自定义错误类型和错误包装

从导出的方法返回错误时，请考虑指定自定义错误类型，而不是单独使用错误字符串。字符串在意外代码中是可以的，但在导出的函数中，它们成为函数公共API的一部分。更改错误字符串将是一项重大更改——如果没有明确的错误类型，需要检查返回错误类型的单元测试将不得不依赖原始字符串值！事实上，基于字符串的错误也使得在私有方法中测试不同的错误案例变得困难，因此您也应该考虑在包中使用它们。回到错误与异常的争论，返回错误也使代码比抛出异常更容易测试，因为错误只是要检查的返回值。不需要测试框架或在测试中捕获异常。

可以在database/sql包中找到简单自定义错误类型的一个很好的示例。它定义了一个导出常量列表，表示包可以返回的错误类型，最著名的是sql.ErrNoRows。虽然从API设计的角度来看，这种特定的错误类型有点问题（您可能会争辩说API应该返回一个空结构而不是错误），但任何需要检查空行的应用程序都可以导入该常量并在代码中使用它不必担心错误消息本身会改变和破坏代码。

对于更复杂的错误处理，您可以通过实现返回错误字符串的Error()方法来定义自定义错误类型。自定义错误可以包括元数据，例如错误代码或原始请求参数。如果您想表示错误类别，它们很有用。DigitalOcean的本教程展示了如何使用自定义错误类型来表示可以重试的一类临时错误。

通常，错误会通过将低级错误与更高级别的解释包装起来，从而在程序的调用堆栈中传播。例如，数据库错误可能会以下列格式记录在API调用处理程序中：调用CreateUser端点时出错：查询数据库时出错：pq：检测到死锁。这很有用，因为它可以帮助我们跟踪错误在系统中传播的过程，向我们展示根本原因（数据库事务引擎中的死锁）以及它对更广泛系统的影响（调用者无法创建新用户）。

自Go1.13以来，此模式具有特殊的语言支持，并带有错误包装。通过在创建字符串错误时使用%w动词，可以使用Unwrap()方法访问底层错误。除了比较错误相等性的函数errors.Is()和errors.As()外，程序还可以获取包装错误的原始类型或标识。这在某些情况下可能很有用，尽管我认为在确定如何处理所述错误时最好使用顶级错误的类型。

Panics

不要panic()！长时间运行的应用程序应该优雅地处理错误而不是panic。即使在无法恢复的情况下（例如在启动时验证配置），最好记录一个错误并优雅地退出。panic比错误消息更难诊断，并且可能会跳过被推迟的重要关闭代码。

Logging

我还想简要介绍一下日志记录，因为它是处理错误的关键部分。通常你能做的最好的事情就是记录收到的错误并继续下一个请求。

除非您正在构建简单的命令行工具或个人项目，否则您的应用程序应该使用结构化的日志库，该库可以为日志添加时间戳，并提供对日志级别的控制。最后一部分特别重要，因为它将允许您突出显示应用程序记录的所有错误和警告。通过帮助将它们与信息级日志分开，这将为您节省无数时间。

微服务架构还应该在日志行中包含服务的名称以及机器实例的名称。默认情况下记录这些时，程序代码不必担心包含它们。您也可以在日志的结构化部分中记录其他字段，例如收到的错误（如果您不想将其嵌入日志消息本身）或有问题的请求或响应。只需确保您的日志没有泄露任何敏感数据，例如密码、API密钥或用户的个人数据！

对于日志库，我过去使用过logrus和zerolog，但您也可以选择其他结构化日志库。如果您想了解更多信息，互联网上有许多关于如何使用这些的指南。如果您将应用程序部署到云中，您可能需要日志库上的适配器来根据您的云平台的日志API格式化日志-没有它，云平台可能无法检测到日志级别等某些功能。

如果您在应用程序中使用调试级别日志（默认情况下通常不记录），请确保您的应用程序可以轻松更改日志级别，而无需更改代码。更改日志级别还可以暂时使信息级别甚至警告级别的日志静音，以防它们突然变得过于嘈杂并开始淹没错误。您可以使用在启动时检查以设置日志级别的环境变量来实现这一点。

原文：

Golang的内存分配是由golangruntime完成，其内存分配方案借鉴自tcmalloc。

主要特点就是

本文中的element指一定大小的内存块是内存分配的概念，并为出现在golangruntime源码中

本文讲述x8664架构下的内存分配

Golang内存分配有下面几个主要结构

Tiny对象是指内存尺寸小于16B的对象，这类对象的分配使用mcache的tiny区域进行分配。当tiny区域空间耗尽时刻，它会从mcache.alloc[tinySpanClass]指向的mspan中找到空闲的区域。当然如果mcache中span空间也耗尽，它会触发从mcentral补充mspan到mcache的流程。

小对象是指对象尺寸在（16B，32KB]之间的对象，这类对象的分配原则是：

1、首先根据对象尺寸将对象归为某个SpanClass上，这个SpanClass上所有的element都是一个统一的尺寸。

2、从mcache.alloc[SpanClass]找到mspan，看看有无空闲的element，如果有分配成功。如果没有继续。

3、从mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合适的mspan，返回给mcache。如果没有找到就进入mcentral.grow()—mheap.alloc()分配新的mspan给mcentral。

大对象指尺寸超出32KB的对象，此时直接从mheap中分配，不会走mcache和mcentral，直接走mheap.alloc()分配一个SpanClass==0的mspan表示这部分分配空间。

对于程序分配常用的tiny和小对象的分配，可以通过无锁的mcache提升分配性能。mcache不足时刻会拿mcentral的锁，然后从mcentral中充mspan给mcache。大对象直接从mheap中分配。

在x8664环境上，golang管理的有效的程序虚拟地址空间实质上只有48位。在mheap中有一个pagespageAlloc成员用于管理golang堆内存的地址空间。golang从os中申请地址空间给自己管理，地址空间申请下来以后，golang会将地址空间根据实际使用情况标记为free或者alloc。如果地址空间被分配给mspan或大对象后，那么被标记为alloc，反之就是free。

Golang认为地址空间有以下4种状态：

Golang同时定义了下面几个地址空间操作函数：

在mheap结构中，有一个名为pages成员，它用于golang堆使用虚拟地址空间进行管理。其类型为pageAlloc

pageAlloc结构表示的golang堆的所有地址空间。其中最重要的成员有两个：

在golang的gc流程中会将未使用的对象标记为未使用，但是这些对象所使用的地址空间并未交还给os。地址空间的申请和释放都是以golang的page为单位（实际以chunk为单位）进行的。sweep的最终结果只是将某个地址空间标记可被分配，并未真正释放地址空间给os，真正释放是后文的scavenge过程。

在gcmark结束以后会使用sweep()去尝试free一个span；在mheap.alloc申请mspan时刻，也使用sweep去清扫一下。

清扫mspan主要涉及到下面函数

如上节所述，sweep只是将page标记为可分配，但是并未把地址空间释放；真正的地址空间释放是scavenge过程。

真正的scavenge是由pageAlloc.scavenge()—sysUnused()将扫描到待释放的chunk所表示的地址空间释放掉（使用sysUnused()将地址空间还给os）

golang的scavenge过程有两种：

下面先写一段测试程序，然后看下运行结果：

运行结果：

发生了错误，提示：fatalerror:concurrentmapreadandmapwrite，map发生了同时读和写了；但是这个错误并不是每次运行都会出现，就是有的时候会出现，有的时候并不会出现，根据笔者多次运行结果(其他例子，读者可以自己尝试下)来看还会有另外一种报错就是：fatalerror:concurrentmapwrites，就是map发生了同时写，但是只是读是不会有问题的。关于不同的运行结果小伙伴们可以自己写几个例子去测试下。下面就这两个错误的发生，笔者给出如下解释：

（1）fatalerror:concurrentmapreadandmapwrite

就是当一个goroutine在写数据，而同时另外一个goroutine要读数据就会报错，不过这个报错也很好理解：还没写完就读，读的数据会有问题，或者反过来还没读完就开始写了，同样会导致读取的数据有问题；

（2）fatalerror:concurrentmapwrites

两个goroutine同时写一个内存地址，这种操作也是不允许的，会导致一些比较奇怪的问题；

总体来看其实就是写map的操作和其他的读或者写同时发生了，导致的报错，做过几年开发的人可能会想到使用锁来解决，比如写map某个key的时候，通过锁来保证其他goroutine不能再对其写或者读了。

实现思路：

（1）当写map的某个key时，通过锁来保证其他goroutine不能再对其写或者读了。

（2）当读map的某个key时，通过锁来保证其他的goroutine不能再对其写，但是可以读。

于是我们马上想到golang的读写锁貌似符合需求，下面来实现下：

再来看下运行结果：

发现没有报错了，并且多次运行的结果都不会报错，说明这个方法是有用的，不过在go1.9版本后就有sync.Map了，不过这个适用场景是读多写少的场景，如果写很多的话效率比较差，具体的原因在这里笔者就不介绍了，后面会写篇文章详细介绍下。

今天的文章就到这里了，如果有不对的地方欢迎小伙伴给我留言，看到会即时回复的。

从Gov1.12版本开始，Go使用了非分代的、并发的、基于三色标记清除的垃圾回收器。

关于垃圾回收，比较常见的算法有引用计数、标记清除和分代收集，Golang语言使用的垃圾回收算法是标记清除。

Golang语言的标记清除垃圾回收算法，为了防止GC扫描时内存变化引起的混乱。那么就需要STW，即StopTheWorld。具体在Golang语言中是指，在GC时先停止所有goroutine。再进行垃圾回收，等待垃圾回收结束后再恢复所有被停止的goroutine。

标记清除方法

启动STW，暂停程序的业务逻辑，找出不可达对象和可达对象。

将所有可达对象做标记，清除未标记的对象。停止STW，程序继续执行。循环往复，直到进程程序生命周期结束。因为STW需要暂停程序，为了减少暂停程序的时间。将清除操作移出STW执行周期，但是优化效果不明显。

所谓三色标记，实际上只是为了方便叙述而抽象出来的一种说法，三色对应垃圾回收过程中对象的三种状态。白色是对象未被标记，gcmarkBits对应位为0，该对象将会在本次GC中被清理。灰色是对象还在标记队列中等待被标记，黑色是对象已被标记，gcmarkBits对应位为0，该对象将会在本次GC中被回收。

在Golang游戏leaf系列(一)概述与示例(下文简称系列一)中，提到过Go模块用于创建能够被Leaf管理的goroutine。Go模块是对golang中go提供一些额外功能。Go提供回调功能，LinearContext提供顺序调用功能。善用goroutine能够充分利用多核资源，Leaf提供的Go机制解决了原生goroutine存在的一些问题：

我们来看一个例子（可以在LeafServer的模块的OnInit方法中测试）：

这里的Go方法接收2个函数作为参数，第一个函数会被放置在一个新创建的goroutine中执行，在其执行完成之后，第二个函数会在当前goroutine中被执行。由此，我们可以看到变量res同一时刻总是只被一个goroutine访问，这就避免了同步机制的使用。Go的设计使得CPU得到充分利用，避免操作阻塞当前goroutine，同时又无需为共享资源同步而忧心。

这里主动调用了d.Cb(-d.ChanCb)，把这个回调取出来了。实际上，在skeleton.Run里会自己取这个通道

看一下源码：

New方法，会生成指定缓冲长度的ChanCb。然后调用Go方法就是先执行第一个func,然后把第二个放到Cb里。现在手动造一个例子：

这里解释一下，d.Go根据源码来看，实际也是调用了一个协程。然后上面两次d.Go并不能保证先后顺序。目前的输出结果是1+2那个先执行了，把3写入d.ChanCb，然后把3读出来，继续读时，d.ChanCb里没有东西，阻塞了。然后1+1那个协程启动了，最后又读到了2。

现在把time.Sleep(time.Second)的注释解开，会是啥结果呢

这里执行到time.Sleep睡着了，上面两个d.Go仍然是不确定顺序的，但是会各自的function先执行掉，然后陆续把cb写入d.ChanCb。看这次输出，1+2先写进去的。所以最后执行d.Cb时，就把3先读出来了。然后d.ChanCb的长度为1，说明还有一个，就是输出2了。

另外，就是close时会判断g.pendingGo

这个例子的意思很明显，NewLinearContext这种方式，即使先调用的慢了半秒，它还是会先执行完。

这里先是用了一个list，加入的时候用mutexLinearGo锁了，都加到最后。然后新开协程去处理，读的时候从最前面开始读，也要用mutexLinearGo锁。执行的时候，也要上锁mutexExecution，确保f()执行完并且写入g.ChanCb回调，这个mutexExecution锁才会解除。现在可以改造一个带回调的例子：

结果说明，确实是2先被写入了d.ChanCb。