将 Dispose/Close 方法编写为异步方法是不是一个坏主意？
不要在同一个线程上进行清理（或启动后台线程并阻塞直到完成），而是在“后台”（IsBackground = false，因此它不会提前终止）线程上启动清理并立即返回。
什么时候这是一个坏主意？有多坏？这是个好主意吗？
Instead of doing the cleanup on the same thread (or launching a background thread and blocking till it completes) start the cleanup on a "background" (IsBackground = false, so it doesn't get terminated prematurely) thread and return immediately.
When is this a bad idea and how bad? Is this ever a good idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为与启动后台线程相比，您当时应该仔细考虑如何处置非托管资源。如果它是一个频繁使用的进程，您可能会发现这会产生大量开销（如果没有其他情况的话）。
如果非托管资源的创建和销毁成本非常昂贵，那么您也许可以考虑在应用程序的生命周期内维护一个公共实例或实例池。
I think you'd want to look hard at the time to dispose of your unmanaged resource compared with that of initiating the background thread. If it's a heavily used process you could find this generating a significant overhead, if nothing else.
If the unmanaged resource is very expensive to create and destroy then perhaps you could look at maintaining a common instance or pool of instances for the life of your app.
使用异步清理替换
IDisposable中的Dispose()违反了 里氏替换原则，因为人们期望资源在调用后立即再次可用。我认为由于频繁的分配/释放，这是需要进行一些优化的，这意味着最终您可能只是将问题转移到后台线程中待处理的对象数量不断增加。这将导致较长时间内内存短缺，并且需要一些同步来确保这些对象的数量不会增长到天上。
正如 Lazarus 所说，更合适的解决方案可能是拥有一个可重用对象池。
Replacing the
Dispose()from theIDisposablewith an asynchronous cleanup violates the Liskov Subsitution Principle as one would expect the resources to be available again immediately after the call.I suppose this is some optimization needed because of frequent allocation/deallocation, which would mean that in the end you might just shift the problem to an increasing amount of objects pending to be disposed in the background thread. That will lead to memory shortage over a longer time and need some synchronization to make sure the amount of these objects doesn't grow to the sky.
Like Lazarus said, a more adequate solution could be to have a pool of reusable objects.
您不想这样做的一个地方是，如果您的对象持有其他线程可能正在等待使用的某些有限资源。
我很想看到其他答案，因为我认为这是一个有趣的想法，并且在某些情况下可能是更快地将数据返回给用户的好方法。
One place you wouldn't want to do this is if your object to holding some limited resources that other threads might be waiting to use.
I'm very interested to see other answers, as I think this is an interesting idea, and might be a nice way in some cases to return data to the user faster.
在其他代码可能依赖的所有预期效果完成之前，Dispose 方法不应返回。 Dispose 推迟清理任务是合理的，因为这样做不会破坏其他代码的期望。例如，连接池类的 Dispose 方法可能会立即将 Dispose 连接添加到池中而不关闭它们，并让后台线程关闭一段时间未使用的连接。如果可以打开的不同连接数有限制，并且由于池中充满了不适合当前请求的缓存（但目前未使用）连接而无法满足请求，则“Open”方法必须能够加快泳池的清理速度。
A Dispose method should not return until all expected effects that other code may rely upon have been completed. It is reasonable for Dispose to defer cleanup tasks when doing so will not break other code's expectations. For example, the Dispose method for a connection pooling class might immediately add Disposed connections to a pool without closing them, and have a background thread close connections that haven't been used for awhile. If there is a limit to how many different connections may be open, and a request can't be satisfied because the pool is full of cached (but presently unused) connections which aren't suitable for the present request, the "Open" method must be able to expedite the cleanup of the pool.