Tag Archives: WeakReference

Practical uses of WeakReference

In Part 1, I discussed the basics of WeakReference and WeakReference<T>. Part 2 introduced short and long weak references as well as the concept of resurrection. I also covered how to use the debugger to inspect your memory for the presence of weak references. This article will complete this miniseries with a discussion of when to use weak references at all and a small, practical example.

When to Use

Short answer: rarely. Most applications won’t require this.

Long answer: If all of the following criteria are met, then you may want to consider it:

  1. Memory use needs to be tightly restricted – this probably means mobile devices these days. If you’re running on Windows RT or Windows Phone, then your memory is restricted.
  2. Object lifetime is highly variable – if you can predict the lifetime of your objects well, then using WeakReference doesn’t really make sense. In that case, you should just control their lifetime directly.
  3. Objects are relatively large, but easy to create – WeakReference is really ideal for that large object that would be nice to have around, but if not, you could easily regenerate it as needed (or just do without).
  4. The object’s size is significantly more than the overhead of using WeakReference<T> – Using WeakReference<T> adds an additional object, which means more memory pressure, an extra dereference step. It would be a complete waste of time and memory to use WeakReference<T> to store an object that’s barely larger than WeakReference<T> itself. However, there are some caveats to this, below.

There is another scenario in which WeakReference may make sense. I call this the “secondary index” feature. Suppose you have an in-memory cache of objects, all indexed by some key. This could be as simple as Dictionary<string, Person>, for example. This is the primary index, and represents the most common lookup pattern, the master table, if you will.

However, you also want to look up these objects with another key, say a last name. Maybe you want a dozen other indexes. Using standard strong references, you could have additional indexes, such as Dictionary<DateTime, Person> for birthdays, etc. When it comes time to update the cache, you then have to modify all of these indexes to ensure that the Person object gets garbage collected when no longer needed.

This might be a pretty big performance hit to do this every time there is an update. Instead, you could spread that cost around by having all of the secondary indexes use WeakReference instead: Dictionary<DateTime, WeakReference<Person>>, or, if the index has non-unique keys (likely), Dictionary<DateTime, List<WeakReference<Person>>>.

By doing this, the cleanup process becomes much easier: you just update the master cache, which removes the only strong reference to the object. The next time a garbage collection runs (of the appropriate generation), the Person object will be cleaned up. If you ever access a secondary index looking for those objects, you’ll discover the object has been cleaned up, and you can clean up those indexes right then. This spreads out the cost of cleanup of the index overhead, while allowing the expensive cached objects to be cleaned up earlier.

Other Uses

This Stack Overflow thread has some additional thoughts, with some variations of the example below and other uses.

A rather famous and involved example is using WeakReferences to prevent the dangling event handler problem (where failure to unregister an event handler keeps objects in memory, despite them having no explicit references anywhere in your code).

Practical Example

I had mentioned in Chapter 2 (Garbage Collection) of Writing High-Performance .NET Code that WeakReference could be used in a multilevel caching system to allow objects to gracefully fall out of memory when pressure increases. You can start with strong references and then demote them to weak references according to some criteria you choose.

That is the example I’ll show here. Note that this not production-quality code. It’s only about 5% of the code you would actually need, even assuming this algorithm makes sense in your scenario. At a minimum, you probably want to implement IDictionary<TKey, TValue> on it, perhaps tighten up some of the temporary memory allocations, and more.

This is a very simple implementation. When you add items to the cache, it adds them as strong references (removing any existing weak references for that key). When you attempt to read a value from the cache, it tries the strong references first, before attempting the weak references.

Objects are demoted from strong to weak references based simply on a maximum age. This is admittedly rather simplistic, but it gets the point across.

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Diagnostics;

namespace WeakReferenceCache
{
    sealed class HybridCache<TKey, TValue> 
        where TValue:class
    {
        class ValueContainer<T>
        {
            public T value;
            public long additionTime;
            public long demoteTime;
        }

        private readonly TimeSpan maxAgeBeforeDemotion;

        private readonly ConcurrentDictionary<TKey, ValueContainer<TValue>> strongReferences = 
            new ConcurrentDictionary<TKey, ValueContainer<TValue>>();
        private readonly ConcurrentDictionary<TKey, WeakReference<ValueContainer<TValue>>> weakReferences = 
            new ConcurrentDictionary<TKey, WeakReference<ValueContainer<TValue>>>();
                
        public int Count
        {
            get { return this.strongReferences.Count; }
        }

        public int WeakCount 
        { 
            get 
            { 
                return this.weakReferences.Count; 
            } 
        }

        public HybridCache(TimeSpan maxAgeBeforeDemotion)
        {
            this.maxAgeBeforeDemotion = maxAgeBeforeDemotion;
        }

        public void Add(TKey key, TValue value)
        {
            RemoveFromWeak(key);
            var container = new ValueContainer<TValue>();
            container.value = value;
            container.additionTime = Stopwatch.GetTimestamp();
            container.demoteTime = 0;
            this.strongReferences.AddOrUpdate(key, container, (k, existingValue) => container);
        }

        private void RemoveFromWeak(TKey key)
        {
            WeakReference<ValueContainer<TValue>> oldValue;
            weakReferences.TryRemove(key, out oldValue);
        }

        public bool TryGetValue(TKey key, out TValue value)
        {
            value = null;
            ValueContainer<TValue> container;
            if (this.strongReferences.TryGetValue(key, out container))
            {
                AttemptDemotion(key, container);
                value = container.value;
                return true;
            }

            WeakReference<ValueContainer<TValue>> weakRef;
            if (this.weakReferences.TryGetValue(key, out weakRef))
            {
                if (weakRef.TryGetTarget(out container))
                {
                    value = container.value; 
                    return true;
                }
                else
                {
                    RemoveFromWeak(key);
                }
            }
            return false;
        }

        public void DemoteOldObjects()
        {
            var demotionList = new List<KeyValuePair<TKey, ValueContainer<TValue>>>();
            long now = Stopwatch.GetTimestamp();

            foreach(var kvp in this.strongReferences)
            {
                var age = CalculateTimeSpan(kvp.Value.additionTime, now);
                if (age > this.maxAgeBeforeDemotion)
                {
                    demotionList.Add(kvp);
                }
            }

            foreach(var kvp in demotionList)
            {
                Demote(kvp.Key, kvp.Value);
            }
        }

        private void AttemptDemotion(TKey key, ValueContainer<TValue> container)
        {
            long now = Stopwatch.GetTimestamp();
            var age = CalculateTimeSpan(container.additionTime, now);
            if (age > this.maxAgeBeforeDemotion)
            {
                Demote(key, container);
            }           
        }

        private void Demote(TKey key, ValueContainer<TValue> container)
        {
            ValueContainer<TValue> oldContainer;
            this.strongReferences.TryRemove(key, out oldContainer);
            container.demoteTime = Stopwatch.GetTimestamp();
            var weakRef = new WeakReference<ValueContainer<TValue>>(container);
            this.weakReferences.AddOrUpdate(key, weakRef, (k, oldRef) => weakRef);
        }

        private TimeSpan CalculateTimeSpan(long offsetA, long offsetB)
        {
            long diff = offsetB - offsetA;
            double seconds = (double)diff / Stopwatch.Frequency;
            return TimeSpan.FromSeconds(seconds);
        }        
    }
}

That’s it for the series on Weak References–I hope you enjoyed it! You may never need them, but when you do, you should understand how they work in detail to make the smartest decisions.

Prefer WeakReference<T> to WeakReference

In Writing High-Performance .NET Code, I mention the WeakReference type briefly in Chapter 2 (Garbage Collection), but I don’t go into it too much. However, for the blog, I want to start a small series of posts going into some more detail about WeakReference, how it works, and when to use it, with some example implementations. In this first post, I’ll just cover what it is, what options there are, and how to use it.

A WeakReference is a reference to an object, but one that still allows the garbage collector to destroy the object and reclaim its memory. This is in contrast to a strong (i.e., normal) reference that does prevent the GC from cleaning up the object.

There are two versions of WeakReference:

First, let’s take a look a WeakReference, which has been around since .NET 1.1.

You allocate a weak reference like this:

var weakRef = new WeakReference(myObj);
myObj = null;

myObj is an existing object of your choice. Once you assign it to the weakRef variable, you should set the original strong reference to null (otherwise, what’s the point?). Now, whenever there is a garbage collection the object weakRef is referring to may be collected. To access this object, you may be tempted to make use WeakReference’s IsAlive property, as in this example:

WeakReference ref1 = new WeakReference(new MyObject());
if (ref1.IsAlive)
{
    // wrong!
    DoSomething(ref1.Target as MyObject);
}

IsAlive is a rather silly property. If it returns false, it’s fine–you know the object has been collected. However, if it returns true, then you don’t actually know anything useful because the object could still be garbage collected before you get a chance to make a strong reference to it!

The correct way to use this is to ignore the IsAlive property completely and just attempt to make a strong reference from Target:

MyObject obj = ref1.Target as MyObject;
if (obj != null)
{
    // correct
    DoSomething(obj);
}

Now there is no race. If obj ends up being non-null, then you’ve got a strong reference that is guaranteed to not be garbage collected (until your own strong reference goes out of scope).

Recognizing some of the silliness and umm…weakness of WeakReference, WeakReference<T> was introduced in .NET 4.5 and it formalizes the above procedure by removing both the Target and IsAlive properties from the class and providing you with these two methods:

  • SetTarget – Set a new target object
  • TryGetTarget – Attempt to retrieve the object and assign it to a strong reference

This example demonstrates the usage, which is essentially the same as the correct way to use WeakReference from above:

WeakReference<MyObject> ref2 = new WeakReference<MyObject>(new MyObject());
MyObject obj2;
if (ref2.TryGetTarget(out obj2))
{
    DoSomething(obj2);
}

You could also ask yourself: Why is there a SetTarget method at all? After all, you could just allocate a new WeakReference<T>.

If you are using WeakReference<T> at all, it likely means you are somewhat memory conscious . In this case, allocating new WeakReference<T> objects will contribute extra, unnecessary memory pressure, potentially worsening the overall performance. Why do this, when you can just reuse the WeakReference<T> object for new targets as needed?

Next time, more details on weak references, particularly the differences between short and long weak references, and taking a peek at them in the debugger. We’ll also cover when you should actually use WeakReference<T> at all.

Part 2, Short vs. Long Weak References and Object Resurrection, is up.

Part 3, Practical Uses, is up.