TA貢獻1821條經驗 獲得超6個贊
這是一個您可能感興趣的線程：為 GOGC=off 添加 runtime.Free()
有趣的部分：
Go GC 不再具有手動釋放塊的能力。此外，運行時。Free 是不安全的（人們可能會釋放仍在使用中的指針或雙重釋放），然后 Go 努力擺脫的各種 C 內存問題將再次出現。另一個原因是運行時有時會在你背后分配，程序無法顯式釋放內存。
如果你真的想用 Go 手動管理內存，請根據 syscall.Mmap 或 cgo malloc/free 實現自己的內存分配器。
對于像 Go 這樣的并發語言來說，長時間禁用 GC 通常是一個糟糕的解決方案。Go 的 GC 只會在未來變得更好。
TL;DR：是的，但不要這樣做
TA貢獻1827條經驗 獲得超8個贊
我有點晚了，但是這個問題在谷歌上排名很高，所以這里是 DGraph 數據庫的創建者的一篇文章，它解釋了 malloc/calloc 的替代方法，即 jemalloc，值得一看
https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
使用這些技術，我們可以兩全其美：我們可以在關鍵的、內存綁定的代碼路徑中進行手動內存分配。同時，我們可以在非關鍵代碼路徑中獲得自動垃圾回收的好處。即使您不習慣使用 Cgo 或 jemalloc，您也可以將這些技術應用于更大的 Go 內存塊，并產生類似的影響。
而且我還沒有測試過，但是有一個叫jemalloc-go的github庫
https://github.com/spinlock/jemalloc-go
舉報