如果 gc 在 go 中是可选的怎么办?
这样的语言是否可行,或者 go 中是否有特定的功能绝对需要某种形式的 gc?
注意:我并不反对 gc,而是来自 C/C++ 背景并致力于对于实时服务器应用程序,我更喜欢对如何以及何时获取内存进行一定程度的控制(不能在实时运行过程中进行 10 秒的垃圾收集)。
考虑到我的要求,我的担忧是否现实?还是go gc太好了,我的担心是多余的?
Go 的 gc 是我对尝试 C++ 实时服务器端口的唯一保留。
Would such a language be feasible or are there specific features in go that absolutely require some form of a gc?
note: I am not anti-gc, but coming from a C/C++ background and working on a real-time server application, I prefer to maintain some level of control how and when memory is reaped (can't have a 10s garbage-collection happening in the middle of a live run).
Are my concerns realistic, given my requirements? Or is the go gc so good that my concerns are unfounded?
Go's gc is my only reservation about attempting a port of my C++ real-time server to go.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
使用可选的 GC 需要更改语言。这是一个完全有效的 Go 函数,会让 C 程序员感到毛骨悚然:
这很好,因为 Go 编译器会发现变量
a
需要在堆上分配。稍后它会被垃圾收集,你不必关心。 (好吧,在某些情况下你可能会这样做。但大多数时候你不会。)你可以编造各种场景,让编译器执行类似的操作。如果没有垃圾收集器,情况就不一样了。
您可以采取一些措施来帮助缩短 GC 时间,但在某种程度上您会抵消该语言的优势。我犹豫是否推荐这些做法,但可以选择:
最重要的是,对于具有硬实时要求的应用程序来说,Go 可能不是一个好的选择。也就是说,我也不认为您会看到任何接近 10 秒垃圾收集的情况。考虑您的真正要求是什么,如果您有任何疑问,请进行一些测量。
如果可以的话,尝试最新的 Go 代码。有一些垃圾收集器改进和一些编译器优化会导致更少的分配。但是,如果您的发布时间较短,您可能会在几个月内停留在当前的稳定版本上。
Go with optional GC would require language changes. Here's a perfectly valid Go function that will make a C programmer's skin crawl:
This is fine because the Go compiler will figure out that the variable
a
needs to be allocated on the heap. It will be garbage collected later and you don't have to care. (Well, ok, in some situations you might. But most of the time you don't.)You can concoct all kinds of scenarios where the compiler will do things like this. It just wouldn't be the same without a garbage collector.
There are things you can do to help GC times, but to a certain extent you'll be nullifying the advantages of the language. I hesitate to recommend these practices, but are options:
The bottom line is, Go probably isn't a good choice for applications with hard real-time requirements. That said, I also don't think you'll see anything approaching a 10 second garbage collection. Consider what your requirements really are and if you have any doubts, do some measurements.
Try the latest Go code if you can. There are some garbage collector improvements and some compiler optimizations that cause fewer allocations. If your release time frame is shorter, though, you may be stuck with the current stable release for several months.