如果 gc 在 go 中是可选的怎么办?

发布于 2024-12-11 17:35:51 字数 248 浏览 0 评论 0原文

这样的语言是否可行,或者 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

傲影 2024-12-18 17:35:51

使用可选的 GC 需要更改语言。这是一个完全有效的 Go 函数,会让 C 程序员感到毛骨悚然:

func foo() *int {
    a := 1
    return &a
}

这很好,因为 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:

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文