Это просто ошибка в вашем коде: финализаторы не должны обращаться к управляемым объектам.

Единственная причина для реализации финализатора — освободить неуправляемые ресурсы. И в этом случае вам следует тщательно реализовать стандартный шаблон IDisposable.

С помощью этого шаблона вы реализуете защищенный метод «защищенное удаление (логическое удаление)». Когда этот метод вызывается из финализатора, он очищает неуправляемые ресурсы, но не пытается очищать управляемые ресурсы.

В вашем примере у вас нет неуправляемых ресурсов, поэтому не следует реализовывать финализатор.

То, что вы видите, совершенно естественно.

Вы не сохраняете ссылку на объект, которому принадлежит массив байтов, поэтому этот объект (не массив байтов) фактически свободен для сборки сборщиком мусора.

Сборщик мусора действительно может быть таким агрессивным.

Поэтому, если вы вызываете метод для своего объекта, который возвращает ссылку на внутреннюю структуру данных, а финализатор для вашего объекта искажает эту структуру данных, вам также необходимо сохранить живую ссылку на объект.

Сборщик мусора видит, что переменная ex больше не используется в этом методе, поэтому он может, и, как вы заметили, будет собирать ее при правильных обстоятельствах (т. е. по времени и необходимости).

Правильный способ сделать это — вызвать GC.KeepAlive на ex, поэтому добавьте эту строку кода в конец вашего метода, и все должно быть хорошо:

GC.KeepAlive(ex);

Я узнал об этом агрессивном поведении, прочитав книгу Applied .NET Framework Programming автора Джеффри Рихтер.

это похоже на состояние гонки между вашим рабочим потоком и потоком(ами) GC; чтобы избежать этого, я думаю, есть два варианта:

(1) измените свой оператор if, чтобы использовать ex.Hash[0] вместо res, чтобы ex не мог быть преждевременно GC'd, или

(2) заблокировать ex на время вызова Hash

это довольно изящный пример - учитель имел в виду, что в JIT-компиляторе может быть ошибка, которая проявляется только в многоядерных системах, или что этот тип кодирования может иметь тонкие условия гонки со сборкой мусора?

Я думаю, что то, что вы видите, является разумным поведением из-за того, что все работает в нескольких потоках. Это причина для метода GC.KeepAlive(), который следует использовать в этом случае, чтобы сообщить сборщику мусора, что объект все еще используется и что он не является кандидатом на очистку.

Глядя на функцию DoWork в вашем ответе "полный код", проблема в том, что сразу после этой строки кода:

byte[] res = ex.Hash;

функция больше не делает никаких ссылок на объект ex, поэтому в этот момент она становится доступной для сборки мусора. Добавление вызова GC.KeepAlive предотвратит это.

Да, это проблема с подходить раньше.

Еще веселее то, что вам нужно запустить релиз, чтобы это произошло, и вы в конечном итоге ломаете голову, говоря: «А как это может быть нулевым?».

Интересный комментарий из блога Криса Брумма

http://blogs.msdn.com/cbrumme/archive/2003/04/19/51365.aspx

class C {<br>
   IntPtr _handle;
   Static void OperateOnHandle(IntPtr h) { ... }
   void m() {
      OperateOnHandle(_handle);
      ...
   }
   ...
}

class Other {
   void work() {
      if (something) {
         C aC = new C();
         aC.m();
         ...  // most guess here
      } else {
         ...
      }
   }
}

Поэтому мы не можем сказать, как долго «aC» может жить в приведенном выше коде. JIT может сообщать об ссылке до тех пор, пока не завершится Other.work(). Он может встроить Other.work() в какой-то другой метод и сообщить о C даже дольше. Даже если вы добавите «aC = null;» после того, как вы его используете, JIT может считать это назначение мертвым кодом и удалить его. Независимо от того, когда JIT перестанет сообщать об эталоне, сборщик мусора может какое-то время не собирать его.

Гораздо интереснее побеспокоиться о самом раннем моменте, когда можно было бы собрать aC. Если вы похожи на большинство людей, вы догадываетесь, что самое раннее время, когда aC получает право на сбор, находится в закрывающей скобке предложения «if» Other.work(), где я добавил комментарий. На самом деле фигурных скобок в IL не существует. Они представляют собой синтаксический контракт между вами и компилятором вашего языка. Other.work() может перестать сообщать об aC, как только он инициирует вызов aC.m().

Это совершенно нормально для вызова финализатора в вашем методе выполнения работы, поскольку после вызова ex.Hash CLR знает, что экземпляр ex больше не понадобится...

Теперь, если вы хотите сохранить экземпляр живым, сделайте следующее:

private static void DoWork()
{
    Example ex = new Example();

    byte[] res = ex.Hash; // [1]

    // If the finalizer runs before the call to the Hash 
    // property completes, the hashValue array might be
    // cleared before the property value is read. The 
    // following test detects that.

    if (res[0] != 2) // NOTE
    {
        // Oops... The finalizer of ex was launched before
        // the Hash method/property completed
    }
  GC.KeepAlive(ex); // keep our instance alive in case we need it.. uh.. we don't
}

GC.KeepAlive... ничего не делает :) это пустой не встраиваемый метод /jittable, единственной целью которого является обмануть GC, заставив его думать, что объект будет использоваться после этого.

ПРЕДУПРЕЖДЕНИЕ. Ваш пример совершенно действителен, если бы метод DoWork был управляемым методом C++... Вы DO должны вручную поддерживать управляемые экземпляры вручную, если вы не хотите, чтобы деструктор вызывался изнутри другая нить. IE. вы передаете ссылку на управляемый объект, который собирается удалить большой двоичный объект неуправляемой памяти после завершения, и метод использует тот же самый большой двоичный объект. Если вы не поддерживаете экземпляр живым, у вас возникнет состояние гонки между сборщиком мусора и потоком вашего метода.

И это закончится слезами. И управлял повреждением кучи...

Полный код

Ниже вы найдете полный код, скопированный/вставленный из файла Visual C++ 2008 .cs. Поскольку сейчас я работаю в Linux и не имею никакого компилятора Mono или знаний о его использовании, сейчас я не могу проводить тесты. Тем не менее, пару часов назад я увидел этот код и его ошибку:

using System;
using System.Threading;

public class Example
{
    private int nValue;
    public int N { get { return nValue; } }

    // The Hash property is slower because it clones an array. When
    // KeepAlive is not used, the finalizer sometimes runs before 
    // the Hash property value is read.

    private byte[] hashValue;
    public byte[] Hash { get { return (byte[])hashValue.Clone(); } }
    public byte[] Hash2 { get { return (byte[])hashValue; } }

    public int returnNothing() { return 25; }

    public Example()
    {
        nValue = 2;
        hashValue = new byte[20];
        hashValue[0] = 2;
    }

    ~Example()
    {
        nValue = 0;

        if (hashValue != null)
        {
            Array.Clear(hashValue, 0, hashValue.Length);
        }
    }
}

public class Test
{
    private static int totalCount = 0;
    private static int finalizerFirstCount = 0;

    // This variable controls the thread that runs the demo.
    private static bool running = true;

    // In order to demonstrate the finalizer running first, the
    // DoWork method must create an Example object and invoke its
    // Hash property. If there are no other calls to members of
    // the Example object in DoWork, garbage collection reclaims
    // the Example object aggressively. Sometimes this means that
    // the finalizer runs before the call to the Hash property
    // completes. 

    private static void DoWork()
    {
        totalCount++;

        // Create an Example object and save the value of the 
        // Hash property. There are no more calls to members of 
        // the object in the DoWork method, so it is available
        // for aggressive garbage collection.

        Example ex = new Example();

        // Normal processing
        byte[] res = ex.Hash;

        // Supposed inlined processing
        //byte[] res2 = ex.Hash2;
        //byte[] res = (byte[])res2.Clone();

        // successful try to keep reference alive
        //ex.returnNothing();

        // Failed try to keep reference alive
        //ex = null;

        // If the finalizer runs before the call to the Hash 
        // property completes, the hashValue array might be
        // cleared before the property value is read. The 
        // following test detects that.

        if (res[0] != 2)
        {
            finalizerFirstCount++;
            Console.WriteLine("The finalizer ran first at {0} iterations.", totalCount);
        }

        //GC.KeepAlive(ex);
    }

    public static void Main(string[] args)
    {
        Console.WriteLine("Test:");

        // Create a thread to run the test.
        Thread t = new Thread(new ThreadStart(ThreadProc));
        t.Start();

        // The thread runs until Enter is pressed.
        Console.WriteLine("Press Enter to stop the program.");
        Console.ReadLine();

        running = false;

        // Wait for the thread to end.
        t.Join();

        Console.WriteLine("{0} iterations total; the finalizer ran first {1} times.", totalCount, finalizerFirstCount);
    }

    private static void ThreadProc()
    {
        while (running) DoWork();
    }
}

Для тех, кто заинтересован, я могу отправить заархивированный проект по электронной почте.