这是一个关于非垃圾收集语言(C, c++等)的问题。
有人告诉我，c++比c#更快的原因之一是内置的垃圾收集，它有可能减慢速度。此外，有人告诉我，有一些用例可以将已释放的内存保留在堆栈上。
至于后者，我从来没有得到过一个例子，除了:
Minecraft在早期有性能问题，因为它是用Java编写的，而不是c++，因为垃圾收集。
我想知道这是否有任何有效性，如果有任何理由不立即删除任何分配的对象，只要所有的引用都丢失了?
在C/c++中，除了提供alloca()函数的编译器外，分配的内存从不在堆栈上。在这种情况下，内存将在函数结束时被释放。
在性能方面:一个好的GC通常与malloc()/free()运行速度相同。这两种方法都有开销，但大致相同。显然，你总能找到规则的例外。而且Java的GC并不总是一个好的GC。
在游戏或其他与视频输出同步的内容中，您还希望将GC调整为每帧运行一次，而不是随机触发。否则，每次GC触发时都很容易出现停顿。这并不是因为GC慢，而是因为释放被延迟了，直到它突然同时发生。它只是打乱了时间。
我想知道这是否有任何有效性，如果有任何理由不立即删除任何分配的对象，只要所有引用都丢失了?
这就是所有现代gc的工作方式，它们仅在内存压力增加达到设定阈值时触发(即在短时间内分配太多，或者当您使用的内存%接近可用的100%时)。
原因是多线程。当所有线程都持有对一块内存的引用时，将其作为垃圾收集和压缩传递的结果移动，将使GC线程以外的线程正常使用它，因此，如果出现这种情况，GC必须冻结所有其他线程，完成其工作，然后解冻所有内容，这是非常昂贵的。因此，它将对象保留在内存中，直到有实际的需要释放内存。毕竟，内存是用来使用的。
Minecraft在早期有性能问题，因为它是用Java编写的，而不是c++，因为垃圾收集
如果有的话，它可能有问题，因为Java没有值类型，每个整数都是一个实际的类对象，包含所有隐含的内容(带有指向实际数据的指针的托管框，同步互斥字段等)。然而，这与垃圾收集器或前面提到的c#无关。