在完成其他代码可能依赖的所有预期效果之前，Dispose方法不应返回。Dispose推迟清理任务是合理的，因为这样做不会破坏其他代码的期望。例如，连接池类的Dispose方法可能会立即将Disposed连接添加到池中而不关闭它们，并让后台线程关闭一段时间未使用的连接。如果可以打开的不同连接的数量有限制，并且由于池中充满了不适合当前请求的缓存（但目前未使用）连接而无法满足请求，则"打开"方法必须能够加快池的清理。
与其在同一个线程上进行清理（或者启动后台线程并阻塞直到它完成），不如在"background"（IsBackground=false，这样它就不会提前终止）线程上启动清理并立即返回。
这个主意什么时候坏？坏到什么程度？这是个好主意吗？
与启动后台线程相比，我认为您应该在处理非托管资源时更加谨慎。如果这是一个使用量很大的过程，你可能会发现这会产生很大的开销。
如果非托管资源的创建和销毁成本非常高，那么也许您可以考虑在应用程序的生命周期中维护一个公共实例或实例池。
用异步清理从IDisposable替换Dispose()违反了Liskov替换原则，因为人们希望资源在调用后立即可用。
我认为这是由于频繁的分配/释放而需要的一些优化，这意味着最终您可能会将问题转移到越来越多的待在后台线程中处理的对象上。这将在更长的时间内导致内存不足，并且需要一些同步来确保这些物体的数量不会长到天上。
正如Lazarus所说，一个更合适的解决方案可能是拥有一个可重复使用的对象池。
如果您的对象持有一些其他线程可能正在等待使用的有限资源，那么您不想这样做。
我很想看看其他答案，因为我认为这是一个有趣的想法，在某些情况下，这可能是一个更快地将数据返回给用户的好方法。