有关CPU占用和缓存的一些见解

核心提示： 上面的例子我想说明一个问题，缓存多份数据不一定会占用相同的多份内存，有关CPU占用和缓存的一些见解(2)，还有，缓存的数据可以放在那里呢？一般来说有这么几种，其中白白折腾了网络、CPU和内存（虽然会回收，但是GC一直回收100M的数据，static变量，.NET类库提供的HttpRunti

上面的例子我想说明一个问题，缓存多份数据不一定会占用相同的多份内存。

还有，缓存的数据可以放在那里呢？一般来说有这么几种，static变量，.NET类库提供的HttpRuntime.Cache或者就是一些分布式的缓存解决方案，比如memcached。

有一些误解，很多人非常不喜欢static变量，我想有两个原因，一是可能觉得把100M数据存放到一个变量中，这是很可怕的事情，一个变量竟然占用100M内存，其实我们大多时候缓存的是一个引用类型，变量存放的只是一个指针罢了，100M的值类型确实可怕，二是很多做ASP.NET的人会觉得不能乱用static变量，就产生了这个错觉。其实，我觉得static变量的问题在于它没有线程安全的机制，二是它作为缓存方案不能过期，一旦创建后也不能删除，只能把它设置为空引用，等待GC回收。但对于某些情况，静态变量是适合的，比如我们缓存的数据是只读并且永远不需要过期的，静态变量作为缓存的确足够简单，也不用担心“丢失”！

HttpRuntime.Cache之类的方案的优势在于它提供了过期、依赖、线程同步的支持，也是我们用的最多的。

最后说说分布式缓存解决方案，比如memcached。其实我觉得在一般情况下不要去随便使用分布式的缓存方案，除非我们能满足以下的需求：1、缓存的数据非常多，一台机器的内存不够用，确实需要分布。2、需要确保数据不能丢失，在多台机器上做备份。为什么说不要轻易用，因为分布是有代价的，如果应用服务器和缓存服务器分开的话，势必就需要TCP通讯，这是一个消耗，另外一个消耗是缓存的数据需要序列化和反序列化。分布式缓存使用缓存一些直接能绑定到UI的数据，或者说直接用于呈现的数据，对于大块的数据非常不适合存放到memcached中。比如之前提到的List<string>，如果这个数据是100M，它不能直接用需要做一些计算再返回给WEB服务器，那么我们做的事情就是序列化后缓存到memcached中，然后再反序列化从TCP获取，放到内存中计算后返回给WEB服务器，然后内存中的100M数据等待GC回收。其中白白折腾了网络、CPU和内存（虽然会回收，但是GC一直回收100M的数据，谁受得了）。