Hurray for Reflector!
Expired cache items are actually removed (and callbacks called) when either:
1) Something tries to access the cache item.
2) The ExpiresBucket.FlushExpiredItems
method runs and gets to item. This method is hard-coded to execute every 20 seconds (the accepted answer to the StackOverflow question Changing frequency of ASP.NET cache item expiration corroborates my read of this code via Reflector). However, this has needs additional qualification (for which read on).
Asp.Net maintains one cache for each CPU on the server (I'm not sure if it these represent logical or physical CPUs); each of these maintains a CacheExpires
instance that has a corresponding Timer
that calls its FlushExpiredItems
method every twenty seconds.
This method iterates over another collection of 'buckets' of cache expiration data (an array of ExpiresBucket
instances) serially, calling each bucket's FlushExpiredItems
method in turn.
This method (ExpiresBucket.FlushExpiredItems
) first iterates all the cache items in the bucket and if an item is expired, marks it expired. Then (I'm grossly simplifying here) it iterates the items it has marked expired and removes them, executing the CacheItemRemovedCallback
(actually, it calls CacheSingle.Remove
, which calls CacheInternal.DoRemove
, then CacheSingle.UpdateCache
, then CacheEntry.Close
, which actually calls the callback).
All of that happens serially, so there's a chance something could block the entire process and hold things up (and push the cache item's expiration back from its specified expiration time).
However, at this temporal resolution, with a minimum expiration interval of twenty seconds, the only part of the process that could block for a significant length of time is the execution of the CacheItemRemovedCallbacks
. Any one of these could conceivably block a given Timer
's FlushExpiredItems
thread indefinitely. (Though twenty seconds later, the Timer
would spawn another FlushExpiredItems
thread.)
To summarize, Asp.Net does not guarantee that it will execute callbacks at the specified time, but it will do so under some conditions. As long as the expiration intervals are more than twenty seconds apart, and as long as the cache doesn't have to execute time-consuming CacheItemRemovedCallbacks
(globally - any callbacks could potentially interfere with any others), it can execute expiration callbacks on schedule. That will be good enough for some applications, but fall short for others.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…