Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to prevent goroutine leakage from Go". In daily operation, I believe many people have doubts about how to prevent Go from leaking goroutine. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "how to prevent goroutine leakage from Go"! Next, please follow the editor to study!

Overview

Go's concurrency model is different from other languages. Although it simplifies the difficulty of developing concurrent programs, if you don't know how to use it, you will often encounter the problem of goroutine leakage. Although goroutine is a lightweight thread that takes up very few resources, there is no doubt that there is a problem if it is not released all the time and new protocols are being created, and the problem can only be discovered after a few days or more of running the program.

I think the problems described above can be solved from two aspects, as follows:

The first is prevention. In order to achieve prevention, we need to know what kind of code will leak and how to write it correctly.

Second, monitoring, although prevention reduces the probability of leakage, but no one dares to say that they do not make mistakes, therefore, we usually need some monitoring means to further ensure the robustness of the program.

Next, I will introduce it from these two perspectives in two articles. Today, I will first talk about the first point.

How to monitor leaks

This article focuses on the first point, but for a better demonstration, you can first introduce the simplest way of monitoring. Get the number of goroutine currently running through runtime.NumGoroutine (), and confirm if there is a leak. Its use is very simple, so we don't have to write an example for it.

A simple example.

Language-level concurrency support is a major advantage of Go, but this advantage can also be easily abused. Usually when we start Go concurrent learning, we often hear others say that the concurrency of Go is very simple. You can start goroutine by adding the go keyword before calling the function, that is, a concurrent unit, but many people may only hear this sentence, and then code similar to the following appears:

Package mainimport ("fmt"runtime"time") func sayHello () {for {fmt.Println ("Hello gorotine") time.Sleep (time.Second)} func main () {defer func () {fmt.Println ("the number of goroutines:", runtime.NumGoroutine ())} () go sayHello () fmt.Println ("Hello main")}

If you are familiar with Go, it is easy to find the problem with this code. SayHello is an endless loop, and there is no exit mechanism, so there is no way to release the created goroutine. We use the defer implementation at the top of the main function to print the number of goroutine currently running when the function exits. Not surprisingly, its output is as follows:

The number of goroutines: 2

However, because the above program is not resident and there is no leakage problem, the system will automatically recycle runtime resources after the program exits. But if this code is executed in a resident service, such as http server, every time a request is received, the sayHello will be started, and time goes by, and each time the started goroutine will not be released, your service will get closer and closer to collapse.

This example is relatively simple, and I'm sure friends who know a little bit about Go concurrency won't make this mistake.

Classification of leakage situation

The example described earlier is a leak caused by running an endless loop in goroutine. Next, I will analyze the various leaks according to the concurrent data synchronization. Simplicity falls into two categories, namely:

Leakage caused by channel

Leakage caused by traditional synchronization mechanism

The traditional synchronization mechanism mainly refers to the synchronization mechanism oriented to shared memory, such as exclusive lock, shared lock and so on. Leaks caused by these two situations are relatively common. Go due to the existence of defer, the second kind of situation, in general, is relatively easy to avoid.

Leakage caused by chanel

Let's start with channel. If you have read the official concurrent article, the translated version, you will find that the use of channel has been accidentally leaked. Let's sum up the circumstances that may lead to.

Send or not receive

We know that the sender is usually equipped with the corresponding receiver. Ideally, we want the receiver to always receive all the data sent so that there will be no problems. But the reality is that once the receiver exits abnormally and stops receiving upstream data, the sender will be blocked. This situation is described in great detail in the previous article.

Sample code:

Package mainimport "time" func gen (nums... int)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.