时间戳

首页 > 解决方案 > Golang 加密/tls 内存泄漏

go - Golang 加密/tls 内存泄漏

问题描述

问题：为什么 *tls.Conn 即使在变量超出范围并且使用该(*tls.Conn).Close()方法正确关闭后也不会被垃圾收集？完整的代码重现下面给出。

动机：到目前为止，我已经尝试了 2 个 websocket 库（https://github.com/gorilla/websocket和https://github.com/gobwas/ws）作为长期运行服务（> 24 小时）的一部分，其中在其整个生命周期中作为客户端维护约 10 个 websocket 连接。有时它们与服务器断开连接，在这种情况下，我会建立一个新连接。内存使用量在其生命周期内稳步增长，并且从内存配置文件中，它指向底层 *tls.Conn 对象留在堆上。（不被垃圾收集）。

完整代码重现

package main

import (
    "crypto/tls"
    "fmt"
    "log"
    _ "net/http/pprof"
    "os"
    "os/signal"
    "runtime"
    "syscall"
    "time"
)

func finalizer(_ interface{}) {
    fmt.Println("finalizer called")
}

func main() {
    // setup interrupt handler
    c := make(chan os.Signal)
    signal.Notify(c, os.Interrupt, syscall.SIGTERM)

    for i := 0; i < 100; i++ {
        go func() {
            for {
                tlsConnectThenCloseAfterWait()
            }
        }()
    }

    <-c
    os.Exit(1)

}

func tlsConnectThenCloseAfterWait() {
    conn, err := tls.Dial("tcp", "mail.google.com:443", &tls.Config{})
    if err != nil {
        log.Fatalln("failed to connect: " + err.Error())
    }
    defer func() {
        err := conn.Close()
        if err != nil {
            log.Fatalln("closing conn failed")
        }
    }()

    runtime.SetFinalizer(conn, finalizer)
    conn.Write([]byte("hello how are you"))

    timer := time.NewTimer(time.Second)
    <-timer.C
}

的输出GODEBUG=gctrace=1 ./main

gc 1 @0.088s 1%: 0+9.0+0 ms clock, 0+12/11/0+0 ms cpu, 4->5->1 MB, 5 MB goal, 12 P
gc 2 @0.102s 3%: 0+4.9+0.99 ms clock, 0+5.9/6.0/0+11 ms cpu, 4->4->1 MB, 5 MB goal, 12 P
gc 3 @0.114s 5%: 0+4.9+1.0 ms clock, 0+3.9/10/2.9+12 ms cpu, 4->4->2 MB, 5 MB goal, 12 P
gc 4 @0.171s 4%: 0+5.0+0 ms clock, 0+1.0/9.9/0+0 ms cpu, 4->5->3 MB, 5 MB goal, 12 P
gc 5 @0.196s 4%: 0+5.9+0 ms clock, 0+2.9/9.9/0+0 ms cpu, 5->7->3 MB, 6 MB goal, 12 P
gc 6 @0.352s 2%: 1.0+2.0+0 ms clock, 12+0/1.9/1.9+0 ms cpu, 6->7->4 MB, 7 MB goal, 12 P
gc 7 @0.365s 2%: 0.99+3.0+0 ms clock, 11+3.0/5.0/0+0 ms cpu, 7->8->5 MB, 8 MB goal, 12 P
gc 8 @0.399s 3%: 0+13+0 ms clock, 0+18/29/1.0+0 ms cpu, 9->11->6 MB, 10 MB goal, 12 P
gc 9 @1.278s 1%: 1.0+28+0 ms clock, 12+9.9/53/0+0 ms cpu, 10->13->9 MB, 13 MB goal, 12 P
gc 10 @1.433s 2%: 1.0+22+0 ms clock, 12+45/55/1.0+0 ms cpu, 14->16->9 MB, 18 MB goal, 12 P
gc 11 @1.534s 2%: 0+6.0+0 ms clock, 0+4.0/15/3.0+0 ms cpu, 16->17->11 MB, 19 MB goal, 12 P
gc 12 @2.479s 1%: 0+3.0+0 ms clock, 0+0/6.0/18+0 ms cpu, 20->20->12 MB, 22 MB goal, 12 P
gc 13 @2.656s 1%: 1.0+10+0 ms clock, 12+3.0/30/4.9+0 ms cpu, 23->25->16 MB, 25 MB goal, 12 P
gc 14 @3.737s 1%: 0+6.0+0 ms clock, 0+3.0/18/9.0+0 ms cpu, 31->33->20 MB, 33 MB goal, 12 P
gc 15 @4.830s 0%: 0+5.9+0 ms clock, 0+5.0/13/16+0 ms cpu, 39->40->25 MB, 41 MB goal, 12 P
gc 16 @6.733s 0%: 0.99+16+0.99 ms clock, 11+7.9/47/80+11 ms cpu, 50->50->32 MB, 51 MB goal, 12 P
gc 17 @8.140s 0%: 0.99+21+0 ms clock, 11+3.0/59/125+0 ms cpu, 64->64->42 MB, 65 MB goal, 12 P
gc 18 @11.168s 0%: 1.0+28+0 ms clock, 12+24/78/97+0 ms cpu, 82->82->54 MB, 84 MB goal, 12 P
gc 19 @14.433s 0%: 0.99+27+0 ms clock, 11+9.0/74/146+0 ms cpu, 106->106->70 MB, 108 MB goal, 12 P
gc 20 @18.883s 0%: 0+47+0 ms clock, 0+6.0/133/211+0 ms cpu, 137->138->91 MB, 140 MB goal, 12 P
gc 21 @24.437s 0%: 0.99+30+0.99 ms clock, 11+15/91/101+11 ms cpu, 177->178->118 MB, 182 MB goal, 12 P
gc 22 @31.872s 0%: 1.0+105+0 ms clock, 12+60/317/256+0 ms cpu, 230->233->155 MB, 236 MB goal, 12 P
gc 23 @41.705s 0%: 0+101+0 ms clock, 0+15/283/549+0 ms cpu, 302->303->200 MB, 310 MB goal, 12 P
gc 24 @54.302s 0%: 0+92+0 ms clock, 0+9.0/278/472+0 ms cpu, 390->392->260 MB, 400 MB goal, 12 P
gc 25 @70.777s 0%: 0+38+0 ms clock, 0+4.9/113/321+0 ms cpu, 508->508->337 MB, 521 MB goal, 12 P
gc 26 @92.203s 0%: 0+108+0 ms clock, 0+57/326/391+0 ms cpu, 658->662->442 MB, 675 MB goal, 12 P
gc 27 @120.781s 0%: 2.0+99+0 ms clock, 24+11/292/529+0 ms cpu, 862->864->574 MB, 884 MB goal, 12 P

终结器永远不会被调用，并且内存不断增长。

使用go version go1.15.8 windows/amd64

此处还链接到 github 问题：https ://github.com/golang/go/issues/41987

标签： gomemory-leaksgarbage-collectionfinalizer

解决方案

您似乎在滥用runtime.SetFinalizer；这是文档所说的：

[第一个参数]必须是指向new通过调用、获取复合文字的地址或获取局部变量的地址分配的对象的指针。

（我的重点）

如果我将&conn（而不是conn自身）传递给runtime.SetFinalizer，则确实会调用终结器，并且堆永远不会超过 8 MB：

$ GODEBUG=gctrace=1 ./main
gc 1 @1.789s 0%: 0.041+0.67+0.018 ms clock, 0.33+0.31/1.0/2.3+0.14 ms cpu, 4->4->1 MB, 5 MB goal, 8 P
gc 2 @1.874s 0%: 0.044+0.69+0.015 ms clock, 0.35+0.20/1.0/2.4+0.12 ms cpu, 4->4->2 MB, 5 MB goal, 8 P
gc 3 @1.880s 0%: 0.064+0.79+0.014 ms clock, 0.51+0.22/1.1/2.3+0.11 ms cpu, 4->4->2 MB, 5 MB goal, 8 P
gc 4 @1.887s 0%: 0.14+1.5+0.080 ms clock, 1.1+1.6/2.5/0+0.64 ms cpu, 5->5->3 MB, 6 MB goal, 8 P
gc 5 @1.904s 0%: 0.097+1.1+0.025 ms clock, 0.77+1.0/1.9/2.6+0.20 ms cpu, 6->6->3 MB, 7 MB goal, 8 P
gc 6 @1.974s 0%: 0.12+1.7+0.12 ms clock, 0.99+1.4/2.9/1.2+0.98 ms cpu, 6->7->3 MB, 7 MB goal, 8 P
gc 7 @2.900s 0%: 0.22+1.9+0.025 ms clock, 1.8+5.7/2.9/0+0.20 ms cpu, 7->7->4 MB, 8finalizer called
 MB goal, 8finalizer called
 P
finalizer called
finalizer called
finalizer called
finalizer called
finalizer called
finalizer called
--snip--

编译程序-gcflags="-m"显示局部变量conn被移动到堆中。我不是终结器专家（到目前为止），但我怀疑您的滥用runtime.SetFinalizer会导致保留对conn变量的引用，从而使其每个实例都没有资格进行垃圾收集，从而导致内存泄漏。

我不清楚你为什么要使用终结器。传统观点是最好避免使用终结器。

推荐阅读