应该是为了和播客 App 保持一致吧。

@rylaihzh #35 有的，欢迎投简历

@techYoung #33 从我们实际项目中抽出来的一个比较独立的小项目，差不多需要 2-3 天的业余时间完成。

@techYoung #29 您好，可以的。

看到楼里面很多人说自己养猫让猫自由采食，这是极不推荐的做法。先不说卫生和营养流失问题，这种喂食方法会让猫把食物跟那个饭盆联系起来，而不是它的主人。

@fzls #16 你家的两只猫和我家的长得一模一样啊 😂

能买汽油 /混动最好别买电动车。自适应巡航只在长距离高速有用，且同价位的油车基本都配备。功能上完全一致，只是没有大屏幕而已。。

@silencil #19 开发工程师确实是 20 起的，15 是我们在招的产品助理的起薪。薪资范围忘记改了，抱歉。

@xieqiqiang00 #3 被你抢先了，可恶

"正经人谁写日记啊"

总包基本一致，解个一元一次方程可求得 n 的值🐶

@Sasasu @flycloud

是，编译器确实是在编译阶段就分析（预测）出了 data 不会再被使用了，然后直接 GC 掉了。

使用楼主主贴中给出的程序，运行 go build -gcflags '-live'，可以看到编译器知道在 fmt.Println(len(data)) 这行之后 data 再也不会被使用了。

看来变量的 liveness 和 scope 并不一定是一致的。

你运行一下上面我贴的代码试试呗，看会不会被 GC 。

@flycloud

> 应该是 gc 机制如此。

GC 实现不了回收一个还在被引用的内存，因为这需要 GC 有预测未来的能力，这是不可能的。


> 不是这样哈，分配出来的 slice，全部遍历了，也是一样的结果。

你确定吗？我在 macOS 下试了一下下面这段代码，过了十分钟也还是 2G 内存

func main() {
data := make(map[int32][]int32)
for i := 0; i < 1024; i++ {
msg := make([]int32, 1024 * 512, 1024 * 512)
for j:=0;j<1024*512;j++ {
msg[j] = rand.Int31()
}
data[int32(i)] = msg
}
fmt.Println(len(data))

if true {
sig := make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)
<-sig
}
}

不管是什么垃圾回收算法，一定是根据内存是否还被引用来判断是否应该被回收。data 在程序结束前一直保持着对 map 的引用，所以是不会被 GC 的。所以 data 一定不是被 “GC” 了。

我猜测是因为你的程序中只用到了一个大 slice 的一小部分，所以没有用到的部分可能是被 Go 优化器回收了？不过这个就纯属拍脑袋瞎猜了。

@lisonfan #27 我已知的是 minerstat 会把显卡设置成 Compute 模式（默认是 Graphic ）。不过估计还做了其他的“优化”设置来提高挖矿效率。

@lisonfan #23 太惨了老哥 😂 ，我这倒是一切正常。是不是显卡驱动版本太老了？

@marcong95 #11 有参考资料吗？能降低点噪音还是不错。我平时在家工作，确实有点吵。