Questions tagged «garbage-collection»

2
纯语言中的垃圾回收有何不同？
在像Haskell这样的纯语言中，所有数据都是不可变的，并且无法以任何方式更改现有的数据结构。另外，许多关于不变数据的算法和功能性编程模式本质上会产生大量垃圾（map例如，创建中间列表的链）。 面对纯净性，垃圾收集器会采用哪些策略和技术？在不纯语言的GC中（不是在纯上下文中），什么功能很好？纯语言为GC创建了哪些其他新问题？
6
为什么LMAX的团队为什么要使用Java并设计架构以避免不惜一切代价避免GC？
为什么LMAX的团队为什么要用Java 设计LMAX Disruptor，但所有设计都着眼于最大限度地减少GC使用？如果不想运行GC，那么为什么要使用垃圾回收语言？ 他们的优化，硬件知识水平和他们的想法都很棒，但是为什么要使用Java？ 我不反对Java或其他任何东西，但是为什么要使用GC语言？为什么不使用不带GC的D之类的语言或其他语言却允许高效的代码呢？是团队最熟悉Java还是Java拥有我没有看到的某些独特优势？ 假设他们使用带有手动内存管理功能的D进行开发，会有什么区别？他们将不得不考虑低级（他们已经是），但是他们可以从系统本身中榨取最佳性能。
9
内存非托管编程的复杂性是什么？
换句话说，自动垃圾收集解决了哪些具体问题？我从来没有做过底层编程，所以我不知道释放资源会变得多么复杂。 GC所解决的错误（至少对于外部观察者而言）似乎是一种很好地了解他的语言，库，概念，习惯用法等的程序员所不会做的事情。但是我可能是错的：手动内存处理本质上是复杂的吗？
7
垃圾回收的演示比手动内存管理更快
我已经在很多地方读取（赫克，我甚至写了那么我自己），垃圾回收可能（理论上）比手工内存管理更快。 但是，展示要比讲讲难得多。 我从未真正看到过任何代码可以证明这种效果。 是否有人拥有（或知道在哪里可以找到）证明这种性能优势的代码？
1
垃圾收集器压缩堆中的对象时，是否会更改堆栈上的引用？
这似乎是一个简单的问题，但是在对该主题进行了大量阅读之后，我仍然没有找到明确的答案（也许是因为它是如此简单）。 我的问题是：当垃圾收集器压缩堆中的对象时，如何更新对堆栈中那些对象的引用？我可以想到两种可能的解决方案： 遍历堆栈（和堆中的引用）并更新引用以指向对象的新位置。类似于搬家，这就像给有您地址的任何人发送一封信，并要求他们用您的新地址更新他们的地址簿。 提供某种查找表。这就像在本地邮局留下转发地址。 垃圾收集器是否主要使用这两种方法之一？还有其他方法吗？都？
6
垃圾收集器如何防止每次收集都扫描整个内存？
一些（至少是Mono和.NET的）垃圾收集器具有它们经常扫描的短期存储区域，以及具有次要扫描频率的辅助存储区域。Mono将其称为托儿所。 为了找出可以丢弃的对象，它们扫描从根，堆栈和寄存器开始的所有对象，并处置所有不再被引用的对象。 我的问题是，它们如何防止所有使用中的内存在每次收集时都被扫描？原则上，找出不再使用哪些对象的唯一方法是扫描所有对象及其所有引用。但是，这将防止OS换出内存，即使应用程序未使用它，也感觉需要进行大量工作，对于“ Nursery Collection”也是如此。感觉他们并没有通过使用托儿所而获得太多收益。 我是否缺少某些东西？或者垃圾收集器实际上是在每次收集对象时扫描每个对象和每个引用吗？
3
在垃圾回收中使用哈希表是否可以解决标记和清除问题？
在mark-sweep-compact垃圾回收算法中，重新定位对象时必须停止工作，因为引用图变得不一致，并且必须替换指向该对象的所有引用的值。 但是，如果您有一个哈希表，其中对象ID为键，指针为值，并且引用将指向该ID而不是对象地址...那么固定引用将仅需要更改一个值，并且仅当对象时才需要暂停试图在复制期间写入... 我的思路有误吗？
4
低暂停GC背后的算法是什么？
某些语言（例如Java）引入了低暂停GC。 这些GC可以完成大部分工作，而不会暂停整个世界。这显然是一个相当棘手的问题，因为它需要在线程修改内存时对其进行分析，从而导致可以在进程开始时使用该数据，而在完成时不再使用该数据，或者似乎是垃圾的数据，但是因为参考已移动到内存中，并且从未出现在GC所寻找的位置。 因此，基本上来说，其背后的算法是什么？ 研究论文或真正技术文章的链接将被视为有效答案，因为该主题确实是技术性的。
5
内存管理语言的参考计数模式？
Java和.NET都为你管理内存美妙的垃圾收集器，方便的方式快速释放的外部对象（Closeable，IDisposable），但只有当他们是由一个单一的对象所拥有。在某些系统中，可能需要由两个组件独立消耗资源，并且仅在两个组件都释放资源时才释放资源。 在现代C ++中，您可以使用来解决此问题，shared_ptr当所有shared_ptr都被销毁时，它将确定性地释放资源。 在面向对象的，不确定的垃圾收集系统中，是否有任何记录的，经过验证的模式来管理和释放昂贵的资源，这些资源没有一个所有者？
6
Java开发人员应该了解垃圾收集算法吗？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 最近有人在采访中问我是否知道任何垃圾收集算法。 我知道什么是垃圾回收，但是我从未真正考虑过学习垃圾回收算法，因为作为开发人员，我不必担心它，垃圾回收器为我完成了所有艰苦的工作。 你们认为Java开发人员应该了解垃圾收集器算法吗？如果是，您能告诉我应该看哪个？
3
为什么移动平台不支持分代垃圾回收？
Windows Phone / Xbox和Android都不支持分代垃圾回收。这让很多程序员感到沮丧。似乎有合理的工程原因，但我无法弄清楚。 当前的电话比2001年运行带有世代GC的.NET 1.1的台式机/笔记本电脑具有更多的内存和更好的CPU，我无法想到ARM处理器在世代GC上比x86差的任何原因。在电话和控制台上对多任务的需求也减少了，因此有相对更多的可用堆空间。 那有什么呢？ 编辑：需要澄清的几点： 这些平台专门为应用程序使用垃圾收集，因此我的问题不是关于为什么不支持GC的问题；我的问题是关于为何不进行分代垃圾回收。 人们对缺乏世代GC感到沮丧的原因是非世代GC效率极低。（这意味着电池寿命不是原因。） 我确实认为，缺乏世代GC支持是有诚实的技术原因。这不是一个反问。
4
非确定性资源管理是抽象的泄漏吗？
据我所知，资源管理有两种普遍形式：确定性破坏和显式破坏。前者的示例是C ++析构函数和智能指针或Perl的DESTROY子例程，而后者的示例将是Ruby的块至管理资源范例或.NET的IDispose接口。 较新的语言似乎选择后者，这可能是使用非引用计数类型的垃圾收集系统的副作用。 我的问题是：鉴于智能指针或引用计数垃圾收集系统的析构函数（几乎是同一件事）允许隐式和透明的资源销毁，它比依赖于显式的非确定性类型的抽象性泄漏少吗？符号？ 我将举一个具体的例子。如果您有一个超类的三个C ++子类，则其中一个实现可能不需要任何特定的销毁。也许它以另一种方式发挥了魔力。它不需要任何特殊的销毁是无关紧要的-所有子类仍然以相同的方式使用。 另一个示例使用Ruby块。两个子类需要释放资源，因此，即使其他特定子类可能不需要它，因为它们不需要特殊的销毁，所以超类会选择在构造函数中使用块的接口。 后者是否泄漏了资源破坏的实施细节，而前者却没有？ 编辑：比方说，将Ruby与Perl进行比较可能更公平，因为其中一个具有确定性的销毁能力，而另一个则没有，但是它们都被垃圾回收了。
4
内存管理，用于在C ++中的线程之间快速传递消息
假设有两个线程，它们通过彼此异步发送数据消息进行通信。每个线程都有某种消息队列。 我的问题很低：可以期望什么是管理内存的最有效方法？我可以想到几种解决方案： 发件人通过创建对象new。接听电话delete。 内存池（用于将内存传输回发送方） 垃圾收集（例如Boehm GC） （如果对象足够小）按值复制以避免完全分配堆 1）是最明显的解决方案，因此我将其用于原型。很有可能它已经足够好了。但是与我的特定问题无关，我想知道如果要针对性能进行优化，哪种技术最有前途。 我希望从理论上讲池化是最好的，尤其是因为您可以使用有关线程之间信息流的更多知识。但是，我担心这也是最难解决的问题。很多调整... :-( 此后，垃圾收集应该很容易添加（在解决方案1之后），我希望它表现的很好。因此，我想如果1）效率太低，这是最实用的解决方案。 如果对象又小又简单，则按值复制可能是最快的。但是，我担心这会在受支持的消息的实施方面造成不必要的限制，因此我想避免这种情况。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.