Array.Resize 是否删除旧数组？

Question

I want to know if Array.Resize deletes the old allocated Array , and if yes when?

I assumed that it deletes it as soon as the values are copied.
But my teacher says that it only does so at the end of the program, meaning that the memory could be full with the old allocated values.
Is that so?

The old Array is not used in my code after the resize, this should call the GC, shouldn't it?

Answer 1

When objects are garbage-collected is a nondeterministic process and you shouldn't care for that too much.

However what is deterministic is when the array is eligible for GC. This is when it gets out of scope, or more specific, when there are no more references to it. This happens for example when you're outside the method that contains the array. Being marked for GC however won't delete it, there needs to be some memory pressure on the GC which will make the GC clean up resources.

Answer 2

HimBromBeere and erikallen already explained what happens. We can also easily verify this experimentally.

Consider the following code:

static void Main(string[] args)
{
    byte[] a = new byte[] { };
    long total = 0;

    Console.WriteLine("Iteration | curent array size (KB) | total allocations (KB) | private memory size (KB)");

    for (int i = 1; i < Int32.MaxValue; i++ )
    {
        Array.Resize(ref a, i);
        total += i;

        if (i % 10000 == 0)
        {
            Console.WriteLine(i.ToString().PadLeft(9) +
                (i / 1024).ToString().PadLeft(25) +
                (total / 1024).ToString().PadLeft(25) +
                (Process.GetCurrentProcess().PrivateMemorySize64 / 1024).ToString().PadLeft(27));
        }
    }
}

which yields the following result:

Iteration | curent array size (KB) | total allocations (KB) | private memory size (KB)
    10000                        9                    48833                      10560
    20000                       19                   195322                      10924
    30000                       29                   439467                      10976
    40000                       39                   781269                      11040
    50000                       48                  1220727                      11040
    60000                       58                  1757841                      11056
    70000                       68                  2392612                      11080
    80000                       78                  3125039                      11144
    90000                       87                  3955122                      14192
    ...

If all old arrays were kept im memory, we'd need around 4 GB (column total allocations ) after 90000 iterations , but memory usage stays at a low 14 MB (column private memory size ).

Answer 3

旧数组将被 GC 视为无法访问，并将在某个未指定的时间点被释放，就像所有其他对象变得无法访问一样。

Answer 4

An object is elegible for collection when the GC determines that the object is not reachable anymore. Therefore, the original array can be collected if there is no "usable* reference left to reach it.

When the GC decides to collect the object itself is an alltogether different matter and it is up to the GC to decide; it might very well not collect it at all during the whole lifetime of your app simply because there is no memory pressure that requires it.

Example:

private Blah[] Frob()
{
    var someArray = new Blah[] { .... }
    //somework
    return (Blah[])Array.Resive(someArray, size);
}

In this case, the object referenced by someArray will be eligible for collection once Frob returns, because the array is no longer reachable. Its a locally initialized object that can not be reached in any way.

However, in this example:

private Frob[] Foo()
{
    var someArray = GetArrayOfFrobs()
    //somework
    return (Blah[])Array.Resive(someArray, size);
}

The object referenced by someArray will be eligible for collection depending on what GetArrayOfFrobs acutally does. If GetArrayOfFrobs returns an array that is cached somewhere or its part of the state of some other reachable object, then the GC will not mark it as collectible.

In any case, in a managed environment like .NET it's not methods who decide if a managed object is “freed” or not as you seem to believe based on your question; it's the GC and it does a pretty good job, so don't fret about it.