问题描述
我来自C ++背景，我一直在使用C＃大约一年。像许多其他人一样，我为什么决定性的资源管理不是内置于语言中而感到沮丧。我们有了处置模式，而不是确定性的析构函数。 是否通过他们的代码传播IDisposable癌症是值得的。
在我的C ++偏见的大脑中，似乎使用引用计数的智能指针与确定性析构函数是垃圾回收器的一大进步，它要求您实现IDisposable并调用处理清理你的非内存资源。诚然，我不是很聪明......所以我纯粹是从一种渴望中去问这个问题，以便更好地理解为什么事情是这样的。
如果C＃被修改为：
对象是引用计数。当对象的引用计数变为零时，将在对象上确定性地调用资源清理方法，然后将该对象标记为垃圾回收。垃圾收集发生在未来的某个非确定性时间，在这个时间点回收内存。在这种情况下，您不必实现IDisposable或记得调用Dispose。如果您有非内存资源可以发布，您只需实施资源清理功能。
- 为什么这是一个坏主意？
- 是否会破坏垃圾回收器的功能？
- 执行这样的事情是否可行？
编辑：
从目前的评论来看，这是一个糟糕的主意，因为
- GC没有引用计数就更快了
- 处理对象图中的周期问题
我认为第一是有效的，但第二很容易处理使用弱引用。
所以速度优化胜过你的缺点：
- 可能无法及时释放非内存资源
- 可能会很快释放非内存资源
如果您的资源清理机制是确定性的并且内置于该语言中，您可以消除这些可能性。 b $ b
Brad Abrams发布了在.Net框架开发过程中编写的。它详细介绍了很多未使用引用计数的原因，即使早期的优先事项之一是与使用引用计数的VB6保持语义等价。它研究了一些可能性，比如让某些类型的ref被计数，而不是其他类型（ IRefCounted ！！），或者计算具体实例，以及为什么没有这些解决方案被认为是可接受的。 / b>
I come from a C++ background and I've been working with C# for about a year. Like many others I'm flummoxed as to why deterministic resource management is not built-in to the language. Instead of deterministic destructors we have the dispose pattern. People start to wonder whether spreading the IDisposable cancer through their code is worth the effort.
In my C++-biased brain it seems like using reference-counted smart pointers with deterministic destructors is a major step up from a garbage collector that requires you to implement IDisposable and call dispose to clean up your non-memory resources. Admittedly, I'm not very smart... so I'm asking this purely from a desire to better understand why things are the way they are.
What if C# were modified such that:
Objects are reference counted. When an object's reference count goes to zero, a resource cleanup method is called deterministically on the object, then the object is marked for garbage collection. Garbage collection occurs at some non-deterministic time in the future at which point memory is reclaimed. In this scenario you don't have to implement IDisposable or remember to call Dispose. You just implement the resource cleanup function if you have non-memory resources to release.
- Why is that a bad idea?
- Would that defeat the purpose of the garbage collector?
- Would it be feasible to implement such a thing?
EDIT:From the comments so far, this is a bad idea because
- GC is faster without reference counting
- problem of dealing with cycles in the object graph
I think number one is valid, but number two is easy to deal with using weak references.
So does the speed optimization outweigh the cons that you:
- may not free a non-memory resource in a timely manner
- might free a non-memory resource too soon
If your resource cleanup mechanism is deterministic and built-in to the language you can eliminate those possibilities.
Brad Abrams posted an e-mail from Brian Harry written during development of the .Net framework. It details many of the reasons reference counting was not used, even when one of the early priorities was to keep semantic equivalence with VB6, which uses reference counting. It looks into possibilities such as having some types ref counted and not others (IRefCounted!), or having specific instances ref counted, and why none of these solutions were deemed acceptable.
这篇关于为什么没有引用计数+垃圾收集在C＃中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！