如何在 Golang API 中避免内存泄漏？

关注公众号：JongSunShine 获取更多资料

建议你在将Golang API投入生成之前阅读此文，此文是基于真实的线上问题修复经历，如有巧合，纯属踩雷！

几个星期前，在修复我们的主服务器的漏洞时，我们尝试了很多方法来调试和修复它，因为它已经投入生产几个星期了。 但是我们总是需要通过我们的自动缩放机制来缓解，使其看起来似乎一切正常。直到后来我们才明白，这是coding中出现了问题。

01      架构

我们在整个系统架构中使用了微服务模式。 有一个网关 API (我们称之为主 API )为我们的用户(移动和网络)提供 API。 它的角色类似于 API 网关，所以它的任务只处理来自用户的请求，然后调用所需的服务，并向用户构建响应。 此AP服务完全由 Golang 来编写。

这个 bug 真的让我们很沮丧，因为我们没有任何关于这个 bug 的日志。 我们只知道响应时间很长。 Cpu 和内存使用量不断增加。 这就像一场噩梦。

阶段1:     使用定制的 http.Client

在开发这个服务时，我们真正学到的一件事是：“不要相信默认配置，切记”。我们使用一个内置的 http客户端，而不是使用默认的一个从 http 的包

client:=http.Client{} //default

我们根据需要添加一些配置。 因为我们需要重新连接，所以我们在参数中进行了一些配置，并控制了最大空闲可重用连接。

func main() {
   keepAliveTimeout:= 600 * time.Second
   timeout:= 2 * time.Second
   defaultTransport := &http.Transport{
      Dial: (&net.Dialer{
         KeepAlive: keepAliveTimeout,}
   ).Dial,
      MaxIdleConns: 100,
      MaxIdleConnsPerHost: 100,}client:= &http.Client{
      Transport: defaultTransport,
      Timeout:   timeout,
   }
}复制代码

func Func()error {
   req, err:= http.NewRequest("GET","http://example.com?q=one",nil)
   if err != nil {
      return err
   }
   resp, err:= client.Do(req)
   //=================================================
   // CLOSE THE RESPONSE BODY
   //=================================================
   if resp != nil {
      defer resp.Body.Close() // MUST CLOSED THIS
   }

   if err != nil {
      return err
   }
   //=================================================
   // READ THE BODY EVEN THE DATA IS NOT IMPORTANT
   // THIS MUST TO DO, TO AVOID MEMORY LEAK WHEN REUSING HTTP
   // CONNECTION
   //=================================================
   _, err = io.Copy(ioutil.Discard, resp.Body) // WE READ THE BODY
   if err != nil {
      return err
   }
}复制代码

type sampleChannel struct {
   Data *Sample
   Err error
}

func (u *usecase) GetSample(id int64, someparam string, anotherParam string) ([]*Sample, error) {
   chanSample := make(chan sampleChannel, 3)
   wg := sync.WaitGroup{}
   wg.Add(1)
   go func() {
      defer wg.Done()
      chanSample <- u.getDataFromGoogle(id, anotherParam) // just example of function

   }()
   wg.Add(1)
   go func() {
      defer wg.Done()
      chanSample <- u.getDataFromFacebook(id, anotherParam)
   }()
   wg.Add(1)
   go func() {
      defer wg.Done()
      chanSample <- u.getDataFromTwitter(id, anotherParam)
   }()
   wg.Wait()
   close(chanSample)
   result := make([]*Sample, 0)
   for sampleItem := range chanSample {
      if sampleItem.Error != nil {
         logrus.Error(sampleItem.Err)
      }
      if sampleItem.Data == nil {
         continue
      }
      result = append(result, sampleItem.Data)
   }
   return result

}复制代码

如果我们看看上面的代码，它看起来没有什么问题。 但是这个函数是访问量最大的函数，在我们的主 API 中调用最多。 因为这个函数将执行3个带有巨大处理的 API 调用。

超时控制

为了改进这一点，我们在channel采用了超时控制的方法。 因为使用上述样式代码(使用 WaitGroup 将等待所有进程完成) ，我们必须等待所有 API 调用完成，这样我们才能处理并将响应返回给用户。

这是我们最大的错误之一。 当我们的一个服务器死亡时，这段代码可能会造成巨大的灾难。 因为要等很长时间才能恢复dead服务。 当然，有了5K qps/s，这就是一场灾难。

第一次尝试的解决方案:

我们通过添加超时来修改它。 所以我们的用户不会等这么长时间，他们只会得到一个内部服务器错误。

func (u *usecase) GetSample(id int64, someparam string, anotherParam string) ([]*Sample, error) {
   chanSample := make(chan sampleChannel, 3)
   defer close(chanSample)
   go func() {
      chanSample <- u.getDataFromGoogle(id, anotherParam) // just example of function
   }()

   go func() {
      chanSample <- u.getDataFromFacebook(id, anotherParam)
   }()
   
   go func() {
      chanSample <- u.getDataFromTwitter(id,anotherParam)
   }()
   
   result := make([]*feed.Feed, 0)
   timeout := time.After(time.Second * 2)
   for loop := 0; loop < 3; loop++ {
      select {
      case sampleItem := <-chanSample:
         if sampleItem.Err != nil {
            logrus.Error(sampleItem.Err)
            continue
         }

         if feedItem.Data == nil {
            continue
         }
         result = append(result,sampleItem.Data)
      case <-timeout:
         err := fmt.Errorf("Timeout to get sample id: %d. ", id)
         result = make([]*sample, 0)
         return result, err
      }
   }
   return result, nil;
}复制代码

func (u *usecase) GetSample(c context.Context, id int64, someparam string, anotherParam string) ([]*Sample, error) {
   if c== nil {
      c= context.Background()
   }
   
   ctx, cancel := context.WithTimeout(c, time.Second * 2)
   defer cancel()

   chanSample := make(chan sampleChannel, 3)
   defer close(chanSample)
   go func() {
      chanSample <- u.getDataFromGoogle(ctx, id, anotherParam) // just example of function

   }()
   
   go func() {
      chanSample <- u.getDataFromFacebook(ctx, id, anotherParam)
   }()
   
   go func() {
      chanSample <- u.getDataFromTwitter(ctx, id,anotherParam)
   }()
   
   result := make([]*feed.Feed, 0)
   for loop := 0; loop < 3; loop++ {
      select {
      case sampleItem := <-chanSample:
         if sampleItem.Err != nil {
            continue
         }

         if feedItem.Data == nil {
            continue
         }

         result = append(result,sampleItem.Data)
         // ============================================================
         // CATCH IF THE CONTEXT ALREADY EXCEEDED THE TIMEOUT
         // FOR AVOID INCONSISTENT DATA, WE JUST SENT EMPTY ARRAY TO
         // USER AND ERROR MESSAGE
         // ============================================================

      case <-ctx.Done(): // To get the notify signal that the context already exceeded the timeout
         err := fmt.Errorf("Timeout to get sample id: %d. ", id)
         result = make([]*sample, 0)
         return result, err
      }
   }
   
   return result, nil;
}复制代码

因此，我们为代码中的每个 goroutine 调用使用上下文。 这可以帮助我们释放内存并取消 goroutine 调用。 此外，为了获得更好的控制性和可靠性，我们还将上下文传递给 HTTP 请求。

func ( u *usecase) getDataFromFacebook(ctx context.Context, id int64, param string) sampleChanel {

   req, err := http.NewRequest("GET", "https://facebook.com", nil)
   if err != nil {
      return sampleChannel{
         Err: err,
      }
   }
   // ============================================================
   // THEN WE PASS THE CONTEXT TO OUR REQUEST.
   // THIS FEATURE CAN BE USED FROM GO 1.7
   // ============================================================
   if ctx != nil {
      req = req.WithContext(ctx) // NOTICE THIS. WE ARE USING CONTEXT TO OUR HTTP CALL REQUEST
   }

   resp, err := u.httpClient.Do(req)
   if err != nil {
      return sampleChannel{
         Err: err,
      }
   }

   body, err := ioutils.ReadAll(resp.Body)
   if err != nil {
      return sampleChannel{
         Err: err,
      }
      sample := new(Sample)
      err := json.Unmarshall(body, &sample)
      if err != nil {
         return sampleChannle{
            Err: err,
         }
      }
      return sampleChannel{
         Err:  nil,
         Data: sample,
      }
   }
}复制代码

有了这些设置和超时控制，我们的系统更加安全和可控。

经验教训:

1，不要在在生产中使用默认选项.

2，不要在在生产中使用默认选项. 如果您正在构建一个大的并发 api，千万不要使用默认选项

3,大量阅读，大量尝试，大量失败，大量收获

4,我们从这个经验中学到了很多，这种经验只有在真实的案例和真实的用户中才能获得。 我很高兴能参与修复这个漏洞

关注微信公众号