英文:
What if the gc were optional in go?
问题
这样的语言是否可行，或者go语言中是否有一些特定的功能绝对需要某种形式的垃圾回收？
注意：我并不反对垃圾回收，但是作为一个有C/C++背景并且正在开发实时服务器应用程序的人，我更喜欢保持对内存何时以及如何被回收的一定程度的控制（不能在实时运行中出现10秒的垃圾回收）。
鉴于我的要求，我的担忧是否现实？还是说go的垃圾回收如此出色，我的担忧是没有根据的？
对于尝试将我的C++实时服务器移植到go语言，go的垃圾回收是我唯一的保留意见。
英文:
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.
答案1
得分: 9
使用可选的垃圾回收（GC）需要对语言进行更改。这是一个完全有效的Go函数，会让C程序员感到不舒服：
func foo() *int {
a := 1
return &a
}
这是可以的，因为Go编译器会发现变量a需要在堆上分配。它将在稍后进行垃圾回收，你不需要关心它。（好吧，在某些情况下可能需要关心。但大多数情况下不需要。）
你可以构造各种情况，让编译器做类似这样的事情。如果没有垃圾回收器，就不会是同样的情况。
有一些事情可以帮助减少GC时间，但在某种程度上，你将抵消了语言的优势。我不太愿意推荐这些做法，但有以下选项：
- 自由列表
- 使用unsafe包，甚至可以编写自己的分配器并手动释放内存，但你需要为每种要分配的类型编写一个函数。或者使用反射传入要分配的类型，返回一个空接口，并使用类型断言获取具体的值。
总之，对于具有硬实时要求的应用程序来说，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:
func foo() *int {
a := 1
return &a
}
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:
- Free lists
- With the unsafe package you can even write your own allocator and manually free memory, but you'd need a function for every type you want to allocate. Or use reflection to pass in the type you want to allocate, return an empty interface, and use type assertions to get concrete values out.
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论