Practical use of System.WeakReference

Question

I understand what System.WeakReference does, but what I can\'t seem to grasp is a practical example of what it might be useful for. The class itself seems to me to be, well, a h

Answer 1

I use it to implement a cache where unused entries are automatically garbage collected:

class Cache<TKey,TValue> : IEnumerable<KeyValuePair<TKey,TValue>>
{ Dictionary<TKey,WeakReference> dict = new Dictionary<TKey,WeakReference>();

   public TValue this[TKey key]
    { get {lock(dict){ return getInternal(key);}}
      set {lock(dict){ setInteral(key,value);}}     
    }

   void setInteral(TKey key, TValue val)
    { if (dict.ContainsKey(key)) dict[key].Target = val;
      else dict.Add(key,new WeakReference(val));
    } 


   public void Clear() { dict.Clear(); }

   /// <summary>Removes any dead weak references</summary>
   /// <returns>The number of cleaned-up weak references</returns>
   public int CleanUp()
    { List<TKey> toRemove = new List<TKey>(dict.Count);
      foreach(KeyValuePair<TKey,WeakReference> kv in dict)
       { if (!kv.Value.IsAlive) toRemove.Add(kv.Key);
       }

      foreach (TKey k in toRemove) dict.Remove(k);
      return toRemove.Count;
    }

    public bool Contains(string key) 
     { lock (dict) { return containsInternal(key); }
     }

     bool containsInternal(TKey key)
      { return (dict.ContainsKey(key) && dict[key].IsAlive);
      }

     public bool Exists(Predicate<TValue> match) 
      { if (match==null) throw new ArgumentNullException("match");

        lock (dict)
         { foreach (WeakReference weakref in dict.Values) 
            { if (   weakref.IsAlive 
                  && match((TValue) weakref.Target)) return true;
         }  
      }

       return false;
     }

    /* ... */
   }

Answer 2

There are two reasons why you would use WeakReference.

1. Instead of global objects declared as static: Global objects are declared as static fields and static fields cannot be GC'ed (garbage-collected) until the AppDomain is GC'ed. So you risk out-of-memory exceptions. Instead, we can wrap the global object in a WeakReference. Even though the WeakReference itself is declared static, the object it points to will be GC'ed when memory is low.

   Basically, use wrStaticObject instead of staticObject.

   class ThingsWrapper {
       //private static object staticObject = new object();
       private static WeakReference wrStaticObject 
           = new WeakReference(new object());
   }
   

   Simple app to prove that static object is garbage-collected when AppDomain is.

   class StaticGarbageTest
   {
       public static void Main1()
       {
           var s = new ThingsWrapper();
           s = null;
           GC.Collect();
           GC.WaitForPendingFinalizers();
       }
   }
   class ThingsWrapper
   {
       private static Thing staticThing = new Thing("staticThing");
       private Thing privateThing = new Thing("privateThing");
       ~ThingsWrapper()
       { Console.WriteLine("~ThingsWrapper"); }
   }
   class Thing
   {
       protected string name;
       public Thing(string name) {
           this.name = name;
           Console.WriteLine("Thing() " + name);
       }
       public override string ToString() { return name; }
       ~Thing() { Console.WriteLine("~Thing() " + name); }
   }
   

   Note from the output below staticThing is GC'ed at the very end even after ThingsWrapper is - i.e. GC'ed when AppDomain is GC'ed.

   Thing() staticThing
   Thing() privateThing
   ~Thing() privateThing
   ~ThingsWrapper
   ~Thing() staticThing
   

   Instead we can wrap Thing in a WeakReference. As wrStaticThing can be GC'ed, we'll need a lazy-loaded method which I've left out for brevity.

   class WeakReferenceTest
   {
       public static void Main1()
       {
           var s = new WeakReferenceThing();
           s = null;
           GC.Collect();
           GC.WaitForPendingFinalizers();
           if (WeakReferenceThing.wrStaticThing.IsAlive)
               Console.WriteLine("WeakReference: {0}", 
                   (Thing)WeakReferenceThing.wrStaticThing.Target);
           else 
               Console.WriteLine("WeakReference is dead.");
       }
   }
   class WeakReferenceThing
   {
       public static WeakReference wrStaticThing;
       static WeakReferenceThing()
       { wrStaticThing = new WeakReference(new Thing("wrStaticThing")); }
       ~WeakReferenceThing()
       { Console.WriteLine("~WeakReferenceThing"); }
       //lazy-loaded method to new Thing
   }
   

   Note from output below that wrStaticThing is GC'ed when GC thread is invoked.

   Thing() wrStaticThing
   ~Thing() wrStaticThing
   ~WeakReferenceThing
   WeakReference is dead.
   

2. For objects that are time-consuming to initialize: You do not want objects that are time-consusming to init to be GC'ed. You can either keep a static reference to avoid that (with cons from above point) or use WeakReference.

Answer 3

I use weak reference for state-keeping in mixins. Remember, mixins are static, so when you use a static object to attach state to a non-static one, you never know how long it will be required. So instead of keeping a Dictionary<myobject, myvalue> I keep a Dictionary<WeakReference,myvalue> to prevent the mixin from dragging things for too long.

The only problem is that every time I do an access, I also check for dead references and remove them. Not that they hurt anyone, unless there are thousands, of course.

Answer 4

One useful example is the guys who run DB4O object oriented database. There, WeakReferences are used as a kind of light cache: it will keep your objects in memory only as long as your application does, allowing you to put a real cache on top.

Another use would be in the implementation of weak event handlers. Currently, one big source of memory leaks in .NET applications is forgetting to remove event handlers. E.g.

public MyForm()
{
    MyApplication.Foo += someHandler;
}

See the problem? In the above snippet, MyForm will be kept alive in memory forever as long as MyApplication is alive in memory. Create 10 MyForms, close them all, your 10 MyForms will still be in memory, kept alive by the event handler.

Enter WeakReference. You can build a weak event handler using WeakReferences so that someHandler is a weak event handler to MyApplication.Foo, thus fixing your memory leaks!

This isn't just theory. Dustin Campbell from the DidItWith.NET blog posted an implementation of weak event handlers using System.WeakReference.