Struct SegmentedCache

pub struct SegmentedCache<K, V, S: BuildHasher = RandomState, W: Weigher<K, V> = One, L: Lifecycle<K, V> = DefaultLifecycle> { /* private fields */ }

Implementations

impl<K, V, S, W, L> SegmentedCache<K, V, S, W, L>

where K: Eq + Hash + Clone, V: Clone, S: BuildHasher + Default, W: Weigher<K, V> + Clone, L: Lifecycle<K, V> + Default,

pub fn new(segments: usize, max_weight: usize) -> Self

impl<K, V, S, W, L> SegmentedCache<K, V, S, W, L>

where K: Eq + Hash + Clone, V: Clone, S: BuildHasher + Default, W: Weigher<K, V> + Clone, L: Lifecycle<K, V> + Clone,

pub fn new_with_lifecycle( segments: usize, max_weight: usize, lifecycle: L, ) -> Self

pub fn put(&self, key: K, value: V)

pub fn remove(&self, key: &K) -> Option<V>

pub fn get<Q>(&self, key: &Q) -> Option<V>

where K: Borrow<Q>, Q: Hash + Eq + ?Sized,

pub fn evict_all(&self)

Clears the cache, via eviction.

If you want to handle the evicted entries, use the Lifecycle trait. The order of eviction is unspecified.

This function does not guarantee that the cache is empty after calling it in the presence of concurrent writes. If you want to empty the cache, you need to stop writes first, and then call this function. If you just want to reset the cache, then you can call this function with concurrent writes. It’s safe, it’s just not going to be empty.

It will block 1/segments of the cache at a time for segment size time, so it’s potentially fairly intrusive with large segments, especially with an expensive on_eviction Lifecycle if you have one.

Trait Implementations

impl<K: Debug, V: Debug, S: Debug + BuildHasher, W: Debug + Weigher<K, V>, L: Debug + Lifecycle<K, V>> Debug for SegmentedCache<K, V, S, W, L>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.