上一篇文章里，我谈到对于某些场景中的缓存容器，其写操作非常少，到了程序后期甚至为零，而对它的读操作却几乎是密集连续且无穷无尽的。对于这样的容器，如果使用ReaderWriterLockSlim去进行保护每个“读”操作，这开销是在有些多余。因此我提出了“不可变”的哈希表，目的是在保持读操作的时间复杂度为O(1)的情况下，尽可能避免多余的开销。现在我们便将它和其他几种时间进行一个性能的对比。
需要强调一点的是，我们这里讨论的仅仅是符合我提出的特定场景的缓存容器，而不是一个“线程安全的字典”。或者说，其实我这里更强调的是“并发环境下”的“读”性能，而不涉及IDictionary<TKey, TValue>的其他操作（如Count），更不会关心如CopyTo、Remove这类功能的性能。
上一篇文章结束时，我给出了两个缓存容器的基类，可用于此类容器的实现。其中ReadWriteCache类基于ReaderWriterLockSlim，而ReadFreeCache类则基于不可变的字典。不过这两种做法不太适合进行性能测试，因此我这里的实验使用了这样的接口：
public interface IConcurrentCache<TKey, TValue>
{
TValue Get(TKey key);
void Set(TKey key, TValue value);
}
我为这个接口提供了几种最基本实现，无论是“读”还是“写”，都是最直接的，并不对任何特殊的情况（如key缺失，key重复）进行处理。例如ImmutableMapCache：
public class ImmutableMapCache<TKey, TValue> : IConcurrentCache<TKey, TValue>
{
private object m_writeLock = new object();
private FSharpMap<TKey, TValue> m_map = FSharpMap<TKey, TValue>.Empty;
public TValue Get(TKey key)
{
return this.m_map[key];
}
public void Set(TKey key, TValue value)
{
lock (this.m_writeLock)
{
this.m_map = this.m_map.Add(key, value);
}
}
}
ImmutableMapCache是基于F#中的Map而实现的读写操作。由于是Immutable的集合，因此对它的读操作不需要任何并发方面的保护——而写操作理论上也是线程安全的，但是我这里还是使用了lock。这是因为如果没有lock的话，在实际并发的场景中容易出现“摇摆”的情况出现。试想，同时有2个线程正在添加元素，它们同时读取了集合的当前状态，但是在写回的时候只后一个线程的操作生效，先写回的线程的修改丢失了。当并发程度高的情况下，“摇摆”会更加严重。因此，无论是ImmutableMapCache，还是基于Immutable Dictionary的实现，在Set操作中都使用lock进行保护。
测试代码如下：
static void CacheBenchmark<TCache>()
where TCache : IConcurrentCache<int, int>, new()
{
var typeName = typeof(TCache).Name;
var index = typeName.IndexOf('`');
var cacheName = typeName.Substring(0, index);
// warm up
TCache cache = new TCache();
cache.Set(1, 1);
cache.Get(1);
for (int n = 100; n <= 1000; n += 100)
{
cache = new TCache();
CodeTimer.Time(cacheName + " (Set " + n + " elements)", 100, () =>
{
for (var i = 0; i < n; i++)
{
cache.Set(i, i);
}
});
CodeTimer.Time(cacheName + " (Get from " + n + " elements)", 1, () =>
{
var key = 0;
for (int i = 0; i < 1000 * 1000 * 5; i++)
{
cache.Get(key);
key = (key + 1) % n;
}
});
}
}
请注意，这里的测试都是在单线程环境下的。严格来说，这并不表示每种容器在多线程环境下的表现。事实上，即便是多线程环境下，不同实现随并发程度的高低也会有所变化。因此，除了进行实验和观察结果之外，也必须结合实际情况进行思考，而不能简单的“采纳”这次实验的结果。在这里我们总共测试5种不同的实现：
CacheBenchmark<RwLockSlimDictionaryCache<int, int>>();
CacheBenchmark<RwLockDictionaryCache<int, int>>();
CacheBenchmark<ImmutableMapCache<int, int>>();
CacheBenchmark<ImmutableDictionaryCache<int, int>>();
CacheBenchmark<ConcurrentDictionaryCache<int, int>>();
它们分别是：
- RwLockSlimDictionary：基于Dictionary，使用ReaderWriterLockSlim进行保护的缓存容器。
- RwLockDictionary：基于Dictionary，使用ReaderWriterLock进行保护的缓存容器。
- Immutable Map：基于F#中Map实现的缓存容器。
- Immutable Dictionary：基于不可变的哈希表实现的缓存容器。
- Concurrent Dictionary：基于.NET 4.0中提供的Concurrent Dictionary实现的缓存容器。
运行环境是.NET 4.0 Beta 2，实验进行三次。我们首先关注“写”操作的结果，如下：
取平均值作为最后结果，并绘制成图表：
在这结果里我并没有包含基于Immutable Dictionary的实现，因为它的结果实在太惨，如果一并放入的话，其他实现方式就几乎看不出来了。我们在来看一下我们的测试代码，它是统计向一个空容器内添加n个元素所花的时间（n等于100、200、...、1000）。对于基于字典的实现来说，添加1个元素的时间复杂度是O(1)，因此添加n个元素的时间复杂度是O(n)。而基于Immutable Map的实现，其添加1个元素的时间复杂度是O(log(n))，于是添加n个元素的时间复杂度是O(n * log(n))。这两种时间复杂度都可以从图表中表现出来——当然，这个表现形式是“趋势”也就是“形状”，同样的时间复杂度的常数还是不一样的。
那么Immutable Dictionary又是什么样的呢？我们为其单独进行一番实验，减小实验粒度，希望可以得到更清晰的结果：
for (int n = 100; n <= 10000; n += 100)
{
CodeTimer.Time(String.Format("add {0} elements", n), 1, () =>
{
var cache = new ImmutableDictionaryCache<int, int>();
for (int i = 0; i < n; i++)
{
cache.Set(i, i);
}
});
}
将其结果绘制成图表：
向Immutable Dictionary中添加1个元素的时间复杂度是O(n)，于是添加n个元素的时间复杂度则是O(n2)，从图表上看，这趋势也是相当明显的。而且，与基于Dictionary的实现方式不同，由于Immutable Dictionary每次都要重新复制元素，它对于GC的压力也是非常可观的，如下：
从图中可以看到一个有趣的结果，那就是GC的频率在n为8000到9000的某一个时刻的收集频率突然开始加快了，莫非这就是传说中GC的自我调节能力吗？不过这并非是本次实验的关键，我们只需要发现说，Immutable Dictionary与Dictionary相比，前者对GC的消耗较大，而后者则几乎没有GC方面的压力。
在写方面，Immutable Dictionary的表现可谓残不忍睹，但如果是“读”的话，一切就都不一样了：
将结果绘制成图表：
与“写”操作的测试方式不同，“读”操作测试的是“从包含n个元素的容器中读取元素”所需要的时间。除了Immutable Map是O(logN)的时间复杂度外，其余4种容器都是基于Get操作时间复杂度为O(1)的哈希表。换句话说，基于Immutable Map的容器会随着元素数量而耗时增加，而其他4种容器，它们“读”操作的耗时和其中有多少元素并没有关系。
从结果上我们可以得出一些有趣的结论。首先，ReaderWriterLockSlim似乎会进行“自我调节”，一开始它的Write Lock开销较大，但是随着实验的进行，它的开销变小了很多。其次，基于Immutable Dictionary的实现自然因为其“Read Free”而表现最好，但是.NET中Concurrent Dictionary的表现也相当出色，可谓遥遥领先于基于ReaderWriterLockSlim的实现。而在“写”操作测试时，它的表现也可圈可点，仅次于RwLockSlimDictionary。我并不清楚Concurrent Dictionary的实现方式，有人说是Lock Free，也有人说是小粒度的锁。这点可以通过阅读代码来得知，在这里就不多作展开了。
相关文章