Go（lang）內存使用情況：RSIZE增長和139GB的VSIZE？

我在Go 上寫了我的第一個web服務器/ webservices程序，我意識到RSIZE（如命令行程序「top」所示）在向我的webservices重複相同的請求之後會增長。這是否意味着有內存泄漏？Go（lang）內存使用情況：RSIZE增長和139GB的VSIZE？

我還注意到，我的應用程序和「頂部」上的進程都有139GB的VSIZE（兩者都是這個大小）。這是正常的嗎？

我使用轉到1.1.2 OS X 10.8

非常感謝

2013-09-29 Daniele B

大VSIZE在達爾文是正常的。 RSIZE是否平穩，還是繼續增長？ – JimB

我在OSX 10.7上注意到完全一樣的東西，所以我認爲VSIZE是正常的。它似乎不會對性能產生負面影響。 – Aktau

你真正使用的物理內存

大VSIZE並不代表;不會擔心這一點。

單個請求後RSIZE的增長也不用擔心。 RAM被垃圾回收回收，這會花費CPU週期，所以Go和其他GC'd語言等待很多請求，直到他們需要釋放RAM（或者至少在分配大量RAM之前）以運行集合。更少的收藏=>更少的CPU時間。

在通常意義上的泄漏是罕見的，因爲GC應該最終釋放你沒有提及的內存。如果你的緩衝區按需增長但永遠不縮小，那麼這些緩衝區可能會產生類似泄漏的效果，如果你不小心持有一個真正死亡的內存引用，你可能會遇到問題。但除非這個過程永遠持續增長，否則我不會認爲你在這裏遇到了這個問題。

下面是Go的一些內存管理技巧;有些也間接適用於其他語言：

您經常不需要擔心。集合通常非常快速，並且相對於數據的大小，您經常需要大量內存。在你潛入之前，確保有一個問題需要解決。 :)
runtime.ReadMemStats(ms)可以告訴你多久你的程序已經花了GC，有很多像你多少分配其他有用的信息（見runtime模塊文檔在http://golang.org/pkg/runtime/）
如果你花費太多在GC的時間，不知道爲什麼，memprofile是下一步;一個完整的例子涉及給程序一個可選的-memprofile標誌在Go博客上：http://blog.golang.org/profiling-go-programs
一般來說，通過減少不必要的分配，特別是大對象的分配（比如說持有整個HTTP響應的緩衝區）來減少GC。有時，有一些自然的方法可以在不污染程序的情況下實現 - 例如，您可以在循環的多次迭代中重用對象，而不是每次都分配一次。其他時候，您可以回收舊物件而不是新物件;標準sync.Pool包幫助，並有一個很好的回收的一般描述（從sync.Pool是標準之前）on the CloudFlare blog。

快樂去吧！

2013-11-03 06:01:11 twotwotwo

回答