當你的 VPS 運行著多個服務應用,但其中一個有時會佔用所有的資源,以至於都無法透過 ssh 存取伺服器。你轉到使用 Kubernetes 集群,為所有應用程式設定限制。隨後看到一些應用程式被重新啟動,因為 OOM-killer 解決了記憶體」洩漏「問題。
當然, OOM 並不總是洩漏問題,也可能是資源超支。洩漏問題大機率是由程式錯誤引起的,我們今天談論的主題是如何盡量避免這種情況。
過多的資源消耗會傷害錢包,這意味著我們需要立即採取行動。
現在讓我們來談談最佳化。希望你能明白為什麼我們不要太早優化!
#現在我們依照 Go 中的標準實體分類,來給一些實用建議。
盡量使用第三個參數:<span style="font-size: 15px;"> make([]T, 0, len)</span>
如果不知道元素確切的數量並且切片是短暫的,可以分配更大一點,保障切片在運行時不會增長。
盡量不要在複製時使用 append,例如在合併兩個或多個切片時。
一個包含許多元素或大元素的切片,使用 for 去取得單一元素。透過這種方法,將避免不必要的複製。
如果對傳入的切片進行某種操作並傳回已修改的結果,我們可以傳回它。這樣能避免新的記憶體分配。
如果需要從切片中切下一小塊並僅使用它,該切片的主要部分也將被保留。正確的做法是,為這小塊切片使用新的副本,而將舊的切片丟給 GC。
如果拼接字串可以在一個語句中完成,那就使用<span style="font-size: 15px;"></span>
# 運算子。如果需要在循環中執行此操作,請使用<span style="font-size: 15px;">string.Builder</span>
#,並使用它的<span style="font-size: 15px;">Grow</span>
方法預先指定<span style="font-size: 15px;">Builder</span>
的大小,減少記憶體分配次數。
string 和 []byte 在底層結構上非常相近,有時這兩種類型之間可以透過強轉換來避免記憶體分配。
可以池化字串,從而幫助編譯器只儲存一次相同的字串。
我們可以使用 map(級聯)而不是複合鍵,我們可以使用位元組切片。盡量不使用 <span style="font-size: 15px;">fmt</span>
包,因為它所有的方法都用到了反射。
我們理解的小結構體是不超過4個欄位不超過一個機器字大小。
一些典型的拷貝場景
解引用是昂貴的,我們應該盡可能少地這樣做,尤其是在循環中。同時它也失去了使用快速暫存器的能力。
這項工作由編輯器進行最佳化,這意味著它很便宜。
我們可以對齊結構體(根據字段的大小,以正確的順序排列它們),以此減小結構體本身的大小。
嘗試編寫可供編譯器內聯的小函數,它會很快,甚至快過自己在函數中嵌入程式碼。對於熱路徑(hot path)尤其如此。
哪些不會內聯
嘗試使用小參數,因為它們的複製將被優化。嘗試複製和堆疊增長在GC負載保持平衡。避免大量參數,讓你的程式使用快速暫存器(它們的數量是有限的)。
這似乎比在函數體中宣告這些變數更有效率。
幫助編譯器最佳化你的程式碼,儲存中間結果,然後會有更多的選項來最佳化你的程式碼。
盡量不要使用 defer,或至少不要在循環中使用它。
避免在熱路徑分配內存,尤其是短生命物件。製作最常見分支(if,switch)
和slice 一樣,初始化map 時,指定其大小。
struct{} 什麼都不是(不佔記憶體),因此例如傳遞訊號時,使用它是非常有益的。
map 只能增長,不能縮小。我們需要重置 map 時,刪除其所有元素是無濟於事的。
如果 map 不包含指針,那麼 GC 就不會在上面浪費寶貴的時間。字串也使用了指針,因此應該使用位元組數組而不是字串作為鍵。
同樣,我們不想使用指針,但我們可以使用 map 和 slice 的組合,將鍵存儲在 map 中,將值存在 slice。這樣我們就可以不受限制地更改值。
請記住,要為介面分配值時,首先需要將其複製到某處,然後將指針貼給它。關鍵是複製。事實證明,介面的裝箱和拆箱的成本將近似於結構體大小的一次分配。
在某些情況下,介面的裝箱和拆箱期間沒有指派。例如,變數和常數的小值或布林值、具有一個簡單欄位的結構體、指標(包括map、channel、func)
<span style="font-size: 15px;"></span>
##與其他地方一樣,盡量避免不必要的分配。例如將一個接口分配給另一個接口,而不是裝箱兩次。僅在需要時使用<span style="font-size: 15px;"></span>
避免在頻繁呼叫的函數參數和傳回結果中使用介面。我們不需要額外的拆裝包操作。減少使用介面方法呼叫的頻率,因為它會阻止內聯。避免不必要的解引用<span style="font-size: 15px;"></span>
尤其是在循環中,因為事實證明它太昂貴了。解引用是我們不想自費執行的操作。 ######channel 同步比其他同步原語方法慢。另外, select 中的 case 越多,我們的程式就越慢。但是,select,case 加 default 有被最佳化。
這也很昂貴,我們應該避免它。例如,只檢查(獲取)一次最大切片索引,而不是多次。最好立即嘗試獲得極端選項。
在整篇文章中,我們看到了一些相同的最佳化規則。
幫助編譯器做出正確的決定,它會感謝你的。在編譯時分配內存,使用中間結果,並儘量保持你的程式碼可讀。
我再次重申,對於隱式最佳化,基準是強制性的。如果因為編譯器在不同版本之間變化太快,昨天工作的東西明天就不能工作,反之亦然。
不要忘記使用 Go 內建的分析和追蹤工具。
以上是Go:簡單的優化筆記的詳細內容。更多資訊請關注PHP中文網其他相關文章!