Analysis on resource leakage /goroutine leakage / memory leakage /cpu full in go

Dry cargo is full. , What are you waiting for ？！

Catalog

Resource leakage

Typical cases 1

Typical cases 2

goroutine leak

Typical cases 1

Typical cases 2

Typical case 3

Memory leak

CPU Full

---

Resource leakage

It often occurs in the operation of resources , If the file is opened but not closed 、 Streaming requests do not close .

Typical cases 1

The loop needs to be executed once at a time defer, What would you do ？

First, let's look at the general practice ：

    for i := 1; i <= 5; {
        defer fmt.Println(i) // Possible resource leak, 'defer' is called in a 'for' loop
        i++
    }

First , There is already the possibility of resource leakage , If we say that some resource operations are performed inside the loop , Such as file operation ,
If the file is closed , If the number of cycles is large , It is equivalent to that you will execute this when the loop ends n Time close operation .

But is this really OK , Some of my friends said , Obviously, every time i Are not real values that should be executed every time
Here defer Just pass in the parameters ？

    for i := 1; i <= 5; i++{
        defer func(num int) {  // Possible resource leak, 'defer' is called in a 'for' loop
            fmt.Println(i)
        }(i)
    }

Is this really OK ？
Obviously, it doesn't reach the inner part of our loop, which needs to be executed once at a time defer The needs of , And there is the suspicion of resource leakage .
What to do then ？

func main() {
    for i := 1; i <= 5; {
        func(){
            defer fmt.Println(i)   //  Each loop executes once defer, Not until the end of the cycle , Avoid resource leakage 
            i++
        }()
    }
}

Typical cases 2

Yes close operation , In other words, there is an end / Close resource operation , But there is no opportunity to implement

Such as ：

    fmt.Println(" The task is in progress ")
    a := 1
    if a > 0 { //  Simulation error 
        fmt.Println(" An error occurred in the task ")
        return
    }

    fmt.Println(" Normal end of mission ")
    defer func() {
        fmt.Println(" Here, you can close resources ")  //  Suppose you close resources here 
    }()

What you think at this time you think , Will the close resource operation be executed , I won't , This will cause resource leakage .

goroutine leak

seeing the name of a thing one thinks of its function , from goroutine The resulting leak , finger （ single / Multiple ）goroutine Long term resident in memory , Savage devour CPU And memory

Typical cases 1

goroutine The function of has actually ended , but goroutine And I can't quit 、 or goroutine The number of crazy abnormal rise .

Reasons for not being able to exit, such as the reference to it chan Never close（ The mission has actually been accomplished ） That's what happened goroutine leak ;
The reason for the abnormal rise is that the code has not been effectively controlled , No, right goroutine Control the quantity of 、 There is no conditional restriction on the caller that generated it , Although it's very light , But it can't stand the unrestricted rise .

The code is as follows ：

    fmt.Println(" The task is in progress ")
    ch := make(chan int)

    //  A function is simulated here ： After sending data three times, the sending ends 
    go func() {
        for i := 1; i <= 3; i++ {
            ch <- i
            fmt.Println(" Has been sent ： ", i)
        }

        fmt.Println(" Sending has ended ")
    }()

    go func() {  //  Set as co process A
        for i := range ch { //  Here we keep reading ch The data of 
            fmt.Println(" Received ： ", i)
        }

        fmt.Println(" It will be lonely here , Because it will never be executed ")
    }()

    select {}

speed running:

 The task is in progress 
 Has been sent ：  1
 Received ：  1
 Received ：  2
 Has been sent ：  2
 Has been sent ：  3
 Sending has ended 
 Received ：  3
fatal error: all goroutines are asleep - deadlock!

It's obviously deadlocked , coroutines A The function of is to receive from ch The data of , After receiving it, it's over , Actually, it has been received 3 That's the end of it , But it won't end , Because it doesn't know whether the other party has finished sending 、 When do you want to receive it ？
So the synergy A There was a leak .

This code is not very typical , Because the deadlock is over , A more typical case is as follows .

Typical cases 2

goroutine There is a dead circle running inside , Because the code bug Causes some conditions to create an endless loop , It's time to goroutine Never quit , Resources have been unable to release , Cause leakage .

Typical case 3

A surge in quantity .
If you want to process hundreds of millions of data （ It's big ）, Ergodic 、 Concurrent start-up process to run , But the processing time of each data is long , This may lead to a lot of goroutine, It will burst the memory all at once
This leads to very large resource consumption , That is, the wave crest lasts longer , Cause leakage .

Avoiding this situation requires better control of the code , The critical moment can remove the blocking 、 Timely notification of signals 、 Timely intervention control 、 Avoid useless execution all the time 、 Bai Pao, etc .

Memory leak

Memory leak refers to memory growth and failure to reach a stable state , Serious impact on system performance .

CPU Full

Typical code

    fmt.Println(" The task is in progress ")
    ch := make(chan int)

    go func() {
        flag := false
        if flag {
            ch <- 0 //  Never write 
        }
    }()

    //  A function is simulated here ： After sending data three times, the sending ends 
    go func() {
        for {
            select {
            case <-ch:
            default: 
                fmt.Println("default")
            }
        }

        fmt.Println(" When can I finish ？")
    }()

    select {}

Simulate other case There is no chance to execute , Lead to default Fast non-stop idling ,CPU All at once it was full