不行指的是？
不能全部依赖GC，设计和写代码的时候也要注意控制内存开销，避免无法GC和太多GC的使用方式。
--
修改:gpmn FROM 117.173.227.*
FROM 117.173.227.*

我前几天碰到内存没回收的情况。生产者定时生产一个数组，消费者收到即刻消费这个数组。当然由于粗心，生产者的数组一直在累加而不是循环开始清空状态，这样消费端内存慢慢的就炸了。看了pprof是这个消费端在数组里面数据量大占用几百m的时候，gc不了，手动在代码里runtime.gc也不回收。修复了生产者端的问题，消费端内存就正常了。
【 在 fork 的大作中提到: 】
: 看这个 https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
:
: 通过cgo用jemalloc来管理内存，真的好折腾。

- 来自「最水木 for iPhone 8」
--
FROM 120.229.67.*

【 在 lichehuo 的大作中提到: 】
: 我前几天碰到内存没回收的情况。生产者定时生产一个数组，消费者收到即刻消费这个数组。当然由于粗心，生产者的数组一直在累加而不是循环开始清空状态，这样消费端内存慢慢的就炸了。看了pprof是这个消费端在数组里面数据量大占用几百m的时候，gc不了，手动在代码里runtime.gc也不回收。修复了生产者端的问题，消费端内存就正常了。
: :
: - 来自「最水木 for iPhone 8」

没看明白，你这个数组凭啥指望GC能回收内存？ 你也说了“由于粗心，生产者的数组一直在累加而不是循环开始清空状态”， 难道指望GC智能判断这个其实是“粗心”了？
--
FROM 1.91.32.*

因为我是var定义的，不应该被回收吗
【 在 hongdiao 的大作中提到: 】
: 【 在 lichehuo 的大作中提到: 】
: : 我前几天碰到内存没回收的情况。生产者定时生产一个数组，消费者收到即刻消费这个数组。当然由于粗心，生产者的数组一直在累加而不是循环开始清空状态，这样消费端内存慢慢的就炸了。看了pprof是这个消费端在数组里面数据量大占用几百m的时候，gc不了，手动在代码里runtime.gc也不回收。修复了生产者端的问题，消费端内存就正常了。
: : :
: ....................

- 来自「最水木 for iPhone 8」
--
FROM 120.229.67.*

贴代码.

【 在 lichehuo 的大作中提到: 】
: 因为我是var定义的，不应该被回收吗
: - 来自「最水木 for iPhone 8」
--
FROM 49.7.47.*