异步添加到缓存

Question

我目前正在实现一个自定义c＃缓存提供程序，我可以插入到我的站点，它将执行基本的缓存操作，例如添加，检索，从缓存中删除。

我一直在考虑这个并且想知道提高性能，我实现了异步添加到缓存。因此，当一段数据，无论是自定义对象还是我想要插入缓存的任何内容时，我都会通过启动一个新线程并让它在后台运行来实现。

这种方法有利有弊吗？这是一个坏主意还是好主意？我想就这个问题提出一些看法。当然，在插入pesudo示例的.new缓存时需要实现如下所示的正确锁定：

1. 检查是否在缓存中，如果没有继续
2. 启动异步线程
3. 再次检查是否在缓存中
4. 锁定缓存
5. 再次检查是否在缓存中
6. 添加到缓存

Answer 1

在决定为这样的设计添加异步之前，您应该考虑进行一些性能评估和调优。向流程添加线程并不总能使其表现更好......在某些情况下实际上可以让事情变得更糟。异步还会使代码更复杂，更难维护并验证正确性 - 必须有一个显着的好处来克服这些成本。

异步设计的一个缺点是调用代码没有机会响应尝试添加到缓存所导致的任何问题。通常这不是问题，但有时候允许调用者参与确定如何处理缓存冲突或其他冲突。

也就是说，如果您最终确定异步操作实际上会提高性能，那么您应该考虑使用线程池，而不是使用专用线程来添加项目。使用线程池更有效率启动专用线程，结果通常更具可伸缩性。这可以使用异步委托调用在C＃中轻松实现：

// acquire a delegate to the add method
Action<object> addToThreadPool = YourCache.Add; 

// fire and forget, async invoke:
addToThreadPool.BeginInvoke( someItemToAdd, addToThreadPool.EndInvoke, null );

Answer 2

我认为这里真正的问题是，由于过早优化或者因为存在真正的性能需求，您在代码中添加了一些内容。

通常，您只想插入缓存并完成它。产生一个新线程，并处理该线程和相关的交互不仅增加了复杂性，而且增加了进程的开销..

除非我说LBuskin在头上有关使用线程池来处理它的名称。