5月iOS設(shè)備好評榜：iPhone 14僅排第43？
來到新的一月，安兔兔的各個榜單又重新匯總了數(shù)據(jù)，像安卓陣營的榜單都有著比較大的變動，不過iOS由于設(shè)備的更新?lián)Q代并沒有那么快，所以相對來說變化并不大，特別是iOS好評榜，老款設(shè)
Go 語言編寫代碼的最大優(yōu)點之一是能夠在輕量級線程，即 Goroutines 中并發(fā)運行你的代碼。
然而，擁有強大的能力也伴隨著巨大的責(zé)任。
盡管 Goroutines 非常方便，但如果不小心處理，它們很容易引入難以追蹤的錯誤。
Goroutine 泄露就是其中之一。它在背景中悄悄增長，可能最終在你不知情的情況下使你的應(yīng)用程序崩潰。
因此，本文主要介紹 Goroutine 泄露是什么，以及你如何防止泄露發(fā)生。
我們來看看吧！
當創(chuàng)建一個新的 Goroutine 時，計算機在堆中分配內(nèi)存，并在執(zhí)行完成后釋放它們。
Goroutine 泄露是一種內(nèi)存泄露，當 Goroutine 沒有終止并在應(yīng)用程序的生命周期中被留在后臺時就會發(fā)生。
讓我們來看一個簡單的例子。
func goroutineLeak(ch chan int) { data := <- ch fmt.Println(data)}func handler() { ch := make(chan int) go goroutineLeak(ch) return}隨著處理器的返回，Goroutine 繼續(xù)在后臺活動，阻塞并等待數(shù)據(jù)通過通道發(fā)送 —— 這永遠不會發(fā)生。
因此，產(chǎn)生了一個 Goroutine 泄露。
在本文中，我將引導(dǎo)你了解兩種常見的模式，這些模式很容易導(dǎo)致 Goroutine 泄漏：
讓我們深入研究！
遺忘的發(fā)送者發(fā)生在發(fā)送者被阻塞，因為沒有接收者在通道的另一側(cè)等待接收數(shù)據(jù)的情況。
func forgottenSender(ch chan int) { data := 3 // This is blocked as no one is receiving the data ch <- data}func handler () { ch := make(chan int) go forgottenSender(ch) return}雖然它起初看起來很簡單，但在以下兩種情境中很容易被忽視。
func forgottenSender(ch chan int) { data := networkCall() ch <- data}func handler() error { ctx, cancel := context.WithTimeout(context.Background(), 10*time.Millisecond) defer cancel() ch := make(chan int) go forgottenSender(ch) select { case data := <- ch: { fmt.Printf("Received data! %s", data) return nil } case <- ctx.Done(): { return errors.New("Timeout! Process cancelled. Returning") } }}在上面的例子中，我們模擬了一個標準的網(wǎng)絡(luò)服務(wù)處理程序。
我們定義了一個上下文，它在10ms后發(fā)出超時，隨后是一個異步進行網(wǎng)絡(luò)調(diào)用的Goroutine。
select語句等待多個通道操作。它會阻塞，直到其其中一個情況可以運行并執(zhí)行該情況。
如果網(wǎng)絡(luò)調(diào)用完成之前超時到達，case <- ctx.Done() 將會執(zhí)行，處理程序?qū)⒎祷匾粋€錯誤。
當處理程序返回時，不再有任何接收者等待接收數(shù)據(jù)。forgottenSender將被阻塞，等待有人接收數(shù)據(jù)，但這永遠不會發(fā)生！
這就是Goroutine泄露的地方。
這是另一個典型的情況。
func forgottenSender(ch chan int) { data := networkCall() ch <- data}func handler() error { ch := make(chan int) go forgottenSender(ch) err := continueToValidateOtherData() if err != nil { return errors.New("Data is invalid! Returning.") } data := <- ch return nil}在上面的例子中，我們定義了一個處理程序并生成一個新的Goroutine來異步進行網(wǎng)絡(luò)調(diào)用。
在等待調(diào)用返回的過程中，我們繼續(xù)其他的驗證邏輯。
如你所見，當continueToValidateOtherData返回一個錯誤導(dǎo)致處理程序返回時，泄露就發(fā)生了。
沒有人等待接收數(shù)據(jù)，forgottenSender將永遠被阻塞！
使用一個緩沖通道。
如果你回想一下，忘記的發(fā)送者發(fā)生是因為另一端沒有接收者。阻塞問題的罪魁禍首是一個無緩沖的通道！
一個無緩沖的通道是在消息發(fā)出時立即需要一個接收者的，否則發(fā)送者會被阻塞。它是在沒有為通道分配容量的情況下聲明的。
func forgottenSender(ch chan int) { data := 3 // This will NOT block ch <- data}func handler() { // Declare a BUFFERED channel ch := make(chan int, 1) go forgottenSender(ch) return}通過為通道添加特定的容量，在這種情況下為1，我們可以減少所有提到的問題。
發(fā)送者可以在不需要接收者的情況下將數(shù)據(jù)注入通道。
正如其名字所暗示的，被遺棄的接收者是完全相反的情況。
當一個接收者被阻塞，因為另一邊沒有發(fā)送者發(fā)送數(shù)據(jù)時，它就會發(fā)生。
func abandonedReceiver(ch chan int) { // This will be blocked data := <- ch fmt.Println(data) }func handler() { ch := make(chan int) go abandonedReceiver(ch) return}第3行一直被阻塞，因為沒有發(fā)送者發(fā)送數(shù)據(jù)。
讓我們再次了解兩個常見的場景，這些場景經(jīng)常被忽視。
func abandonedWorker(ch chan string) { for data := range ch { processData(data) } fmt.Println("Worker is done, shutting down")}func handler(inputData []string) { ch := make(chan string, len(inputData)) for _, data := range inputData { ch <- data } go abandonedWorker(ch) return}在上面的例子中，處理程序接收一個字符串切片，創(chuàng)建一個通道并將數(shù)據(jù)插入到通道中。
處理程序然后通過Goroutine啟動一個工作程序。工作程序預(yù)計會處理數(shù)據(jù)，并且一旦處理完通道中的所有數(shù)據(jù)，就會終止。
然而，即使消耗并處理了所有的數(shù)據(jù)，工作程序也永遠不會到達“第6行”！
盡管通道是空的，但它沒有被關(guān)閉！工作程序繼續(xù)認為未來可能會有傳入的數(shù)據(jù)。因此，它坐下來并永遠等待。
這是Goroutine再次泄漏的地方。
這與我們之前的一些示例非常相似。
func abandonedWorker(ch chan []int) { data := <- ch fmt.Println(data)}func handler() error { ch := make(chan []int) go abandonedWorker(ch) records, err := getFromDB() if err != nil { return errors.New("Database error. Returning") } ch <- records return nil}在上面的例子中，處理程序首先啟動一個Goroutine工作程序來處理和消費一些數(shù)據(jù)。
然后，處理程序從數(shù)據(jù)庫中查詢記錄，然后將記錄注入通道供工作程序使用。
如果數(shù)據(jù)庫出現(xiàn)錯誤，處理程序?qū)⒘⒓捶祷亍Ｍǖ缹⒉辉儆腥魏伟l(fā)送者傳入數(shù)據(jù)。
因此，工作程序被遺棄。
在這兩種情況下，接收者都被留下，因為他們“認為”通道將有傳入的數(shù)據(jù)。因此，它們阻塞并永遠等待。
解決方案是一個簡單的單行代碼。
defer close(ch)當你啟動一個新的通道時，最好的做法是推遲關(guān)閉通道。
這確保在數(shù)據(jù)發(fā)送完成或函數(shù)退出時關(guān)閉通道。
接收者可以判斷一個通道是否已關(guān)閉，并相應(yīng)地終止。
func abandonedReceiver(ch chan int) { // This will NOT be blocked FOREVER data := <- ch fmt.Println(data) }func handler() { ch := make(chan int) // Defer the CLOSING of channel defer close(ch) go abandonedReceiver(ch) return}關(guān)于 Goroutine 泄漏就是這么多了！
盡管它不像其他 Goroutine 錯誤那么強大，但這種泄漏仍然會大大耗盡應(yīng)用程序的內(nèi)存使用。
記住，擁有強大的力量也伴隨著巨大的責(zé)任。
保護我們的應(yīng)用程序免受錯誤的責(zé)任在于你我——開發(fā)人員！
本文鏈接：http://www.tebozhan.com/showinfo-26-15597-0.html常見的 Goroutine 泄露，你應(yīng)該避免
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 并發(fā)編程：你真的能回答好AQS嗎（補充中斷機制）
下一篇： Python自動查重：原理、方法與實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號