{"id":13153,"date":"2010-08-13T07:00:00","date_gmt":"2010-08-13T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/08\/13\/when-do-i-need-to-use-gc-keepalive\/"},"modified":"2010-08-13T07:00:00","modified_gmt":"2010-08-13T07:00:00","slug":"when-do-i-need-to-use-gc-keepalive","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20100813-00\/?p=13153","title":{"rendered":"When do I need to use GC.KeepAlive?"},"content":{"rendered":"

\nFinalization is the crazy wildcard in garbage collection.\nIt operates “behind the GC”,\nrunning after the GC has declared an object dead.\nThink about it: Finalizers run on objects that have no active references.\nHow can this<\/code> be a reference to an object that has no references?\nThat’s just crazy-talk!\n<\/p>\n

\nFinalizers are a Ouija board,\npermitting dead objects to operate “from beyond the grave”\nand affect live objects.\nAs a result, when finalizers are involved, there is a lot of\ncreepy spooky juju going on,\nand you need to tread very carefully, or your soul will become\ncursed.\n<\/p>\n

\nLet’s step back and look at a different problem first.\nConsider this class which doesn’t do anything interesting\nbut works well enough for demonstration purposes:\n<\/p>\n

\nclass Sample1 {\n private StreamReader sr;\n public Sample1(string file) : sr(new StreamReader(file)) { }\n public void Close() { sr.Close(); }\n public string NextLine() { return sr.ReadLine(); }\n}\n<\/pre>\n
\nWhat happens if one thread calls Sample1.NextLine()<\/code>\nand another thread calls Sample1.Close()<\/code>?\nIf the NextLine()<\/code> call wins the race,\nthen you have a stream closed while it is in the middle of\nits ReadLine<\/code> method.\nProbably not good.\nIf the Close()<\/code> call wins the race,\nthen when the NextLine()<\/code> call is made,\nyou end up reading from a closed stream.\nDefinitely not good.\nFinally, if the NextLine()<\/code> call runs to\ncompletion before the Close()<\/code>,\nthen the line is successfully read before the stream\nis closed.\n<\/p>\n
\nHaving this race condition is clearly an unwanted state of\naffairs since the result is unpredictable.\n<\/p>\n
\nNow let’s change the Close()<\/code> method to a finalizer.\n<\/p>\n
\nclass Sample2 {\n private StreamReader sr;\n public Sample2(string file) : sr(new StreamReader(file)) { }\n ~Sample2() { sr.Close(); }<\/font>\n public string NextLine() { return sr.ReadLine(); }\n}\n<\/pre>\n
\nRemember that we learned that an object becomes eligible for garbage collection\nwhen there are no active references to it,\nand that it can happen\n\neven while a method on the object is still active<\/a>.\nConsider this function:<\/p>\n
\nstring FirstLine(string fileName) {\n Sample2 s = new Sample2(fileName);\n return s.NextLine();\n}\n<\/pre>\n
\nWe learned that the Sample2<\/code> object becomes eligible\nfor collection during the execution of NextLine()<\/code>.\nSuppose that the garbage collector runs and collects the object\nwhile NextLine<\/code> is still running.\nThis could happen if ReadLine<\/code> takes a long time,\nsay, because the hard drive needs to spin up or there is a network\nhiccup;\nor it could happen just because it’s not your lucky day\nand the garbage collector ran at just the wrong moment.\nSince this object has a finalizer, the finalizer runs\nbefore the memory is discarded, and the finalizer closes the\nStreamReader<\/code>.\n<\/p>\n
\nBoom, we just hit the race condition we considered when\nwe looked at Sample1<\/code>:\nThe stream was closed while it was being read from.\nThe garbage collector is a rogue thread that closes the stream\nat a bad time.\nThe problem occurs because the garbage collector doesn’t know\nthat the finalizer is going to make changes to other objects<\/i>.\n<\/p>\n
\nClassically speaking,\nthere are three conditions which in combination lead to this problem:\n<\/p>\n
    \n
  1. Containment: An entity a<\/code>\n    retains a reference to another entity b<\/code>.\n<\/li>\n
  2. Incomplete encapsulation: The entity b<\/code>\n    is visible to an entity outside a<\/code>.\n<\/li>\n
  3. Propagation of destructive effect:\n    Some operation performed on entity a<\/code>\n    has an effect on entity b<\/code> which alters\n    its proper usage (usually by rendering it useless).\n<\/li>\n<\/ol>\n
    \nThe first condition (containment) is something you do without\na second’s thought.\nIf you look at any class, there’s a very high chance that it has,\namong its fields, a reference to another object.\n<\/p>\n
    \nThe second condition (incomplete encapsulation)\nis also a common pattern.\nIn particular, if b<\/code> is an object with methods,\nit will be visible to itself.\n<\/p>\n
    \nThe third condition (propagation of destructive effect) is the tricky one.\nIf an operation on entity a<\/code> has a damaging\neffect on entity b<\/code>,\nthe code must be careful not to damage it while it’s still being\nused.\nThis is something you usually take care of explicitly,\nsince you’re the one who wrote the code that calls the destructive method.\n<\/p>\n
    \nUnless the destructive method is a finalizer.\n<\/p>\n
    \nIf the destructive method is a finalizer,\nthen\nyou do not have complete control over when it will run<\/i>.\nAnd it is one of the fundamental laws of the universe that events\nwill occur at the worst possible time.\n<\/p>\n
    \nEnter GC.KeepAlive()<\/code>.\nThe purpose of GC.KeepAlive()<\/code> is to force the garbage\ncollector to treat the object as still live,\nthereby preventing it from being collected,\nand thereby preventing the finalizer from running prematurely.\n<\/p>\n
    \n(Here’s the money sentence.)\nYou need to use GC.KeepAlive<\/code> when the finalizer\nfor an object has a destructive effect on a contained object.\n<\/p>\n
    \nThe problem is that it’s not always clear which objects have\nfinalizers which have destructive effect on a contained object.\nThere are some cases where you can suspect this is happening\ndue to the nature of the object itself.\nFor example, if the object manages something external to the CLR,\nthen its finalizer will probably destroy the external object.\nBut there can be other cases where the need for GC.KeepAlive<\/code>\nis not obvious.\n<\/p>\n
    \nA much cleaner solution than using GC.KeepAlive<\/code>\nis to use the IDisposable<\/code> interface,\nformalized by the using<\/code> keyword.\nEverybody knows that the using<\/code> keyword ensures that the\nobject being used is disposed at the end of the block.\nBut it’s also the case (and it is this behavior that is important today)\nthat the using<\/code> keyword also keeps the object alive\nuntil the end of the block<\/i>.\n(Why?\nBecause the object needs to be alive so that we can call Dispose<\/code>\non it!)\n<\/p>\n
    \nThis is one of the reasons I don’t like finalizers.\nSince they operate underneath the GC,\nthey undermine many principles of garbage collected systems.\n(See also\n\nresurrection<\/i><\/a>.)\nAs we saw earlier,\n\na correctly-written program cannot rely on side effects of a finalizer<\/a>,\nso in theory all finalizers could be nop’d out\nwithout affecting correctness.\n<\/p>\n
    \nThe garbage collector purist in me also doesn’t like finalizers\nbecause they prevent the running time of a garbage collector to be\nproportional to the amount of live<\/i> data,\nlike say in a classic two-space collector.\n(There is also a small constant associated with the amount of dead<\/i>\ndata, which means that the overall complexity is proportional to the\namount of total data<\/i>.)\n<\/p>\n
    \nIf I ruled the world, I would decree that the only thing you can do in\na finalizer is perform some tests to ensure that all the associated\nexternal resources have already been explicitly released, and if not, raise\na fatal exception:\nSystem.Exception.Resource­Leak<\/code>.\n<\/p>\n
    \nBonus reading<\/b>\n<\/p>\n