Garbage Collection: Microsoft .NET Framework의 자동 메모리 관리

응용 프로그램에 리소스 관리를 적합하게 이행하는 것은 어렵고도 힘든 작업입니다. 이 때문에, 계속하여 해결하고자 노력하고 있는 진짜 문제가 등한시될 수 있습니다. 따라서, 개발자에게 있어서 기계적인 메모리 관리 작업을 단순하게 처리해 주는 메커니즘이 제공된다면 상당히 흥미로운 일일 것입니다. 놀랍게도 .NET 안에는 Garbage Collection(GC)이라는 메커니즘이 있습니다.
잠시 생각해 봅시다. 모든 프로그램은 한두 가지의 메모리 버퍼와 스크린 공간, 네트워크 연결, 데이터베이스 리소스 등을 사용합니다. 사실, 개체 지향 환경에서는 각 유형마다 여러분의 프로그램에서 사용할 수 있는 몇 가지 리소스를 구별합니다. 이러한 리소스를 사용하기 위해서는 각 유형에 맞게 메모리가 할당되어 있어야 합니다. 리소스를 액세스하기 위해 필요한 단계로서, 다음을 들 수 있습니다.

1. 리소스를 나타내는 유형에 대해 메모리를 할당합니다.
   
2. 리소스의 초기 상태를 설정하고 리소스의 재사용이 가능하도록 메모리를 초기화합니다.
   
3. 해당 유형의 인스턴스 구성원을 액세스하여 리소스를 사용합니다. (필요한 경우 반복하십시오.)
   
4. 리소스 상태를 해체하여 정리합니다.
   
5. 메모리를 늘립니다.
   

public class BaseObj {
    public BaseObj() {
    }

    protected override void Finalize() {
        // Perform resource cleanup code here... 
        // Example: Close file/Close network connection
        Console.WriteLine("In Finalize."); 
    }
}

BaseObj bo = new BaseObj();

• 실행 마무리가 가능한 개체는 구세대로 수준이 올라가게 되는데, 이로써 메모리 압력이 늘어나고 가비지 수집기가 개체의 가비지 여부를 결정할 때 개체의 메모리가 수집되는 것을 막게 됩니다. 또한, 이 개체에 의해 직접 또는 간접으로 참조된 모든 개체도 함께 수준이 올라갑니다.
  
• 실행 마무리가 가능한 개체는 할당에 시간이 걸립니다.
  
• Garbage Collection기에 Finalize 메서드 실행을 강제로 하게 하면 심각한 성능 문제가 발생합니다. 각 개체는 마무리되어 있음을 기억하십시오. 따라서 10,000 개의 개체 배열이 있을 경우에는 각 개체가 모두 각자의 Finalize 메서드를 호출해야 합니다.
  
• 실행 마무리가 가능한 개체는 다른(실행 마무리가 가능하지 않은) 개체를 참조할 수 있고, 이에 따라 수명 주기가 불필요하게 늘어나게 됩니다. 실제로 여러분은 하나의 유형을 두 개의 서로 다른 유형으로 분할하는 문제를 생각해 볼 수 있을 것입니다. 즉, 다른 개체를 참조하지 않도록 Finalize 메서드를 가진 가벼운 유형과 다른 개체를 참조하도록 Finalize 메서드가 없는 별도의 유형 두 가지를 말합니다.
  
• Finalize 메서드가 실행될 시기에 대해 제어할 수 없습니다. 가비지 수집기가 실행되는 다음 시간까지 리소스에 개체가 유보되어 있습니다.
  
• 응용 프로그램이 종결될 때, 일부 개체에 접근할 수 있어 이들의 Finalize 메서드가 호출되지 않게 됩니다. 이는 백그라운드 스레드에서 개체를 사용하거나 응용 프로그램 종료 또는 AppDomain 언로드시 개체가 만들어지는 경우에 발생합니다. 기본적으로, Finalize 메서드는 응용 프로그램이 종료될 때 접근할 수 없는 개체에 대해서는 호출되지 않으며, 이는 응용 프로그램이 빨리 종료되도록 하기 위해서입니다. 물론, 모든 운영 체제 리소스는 재사용이 가능하지만, 관리 힙의 개체는 자연스럽게 정리되기가 힘듭니다. 이러한 기본적인 작동은 System.GC 유형의 RequestFinalizeOnShutdown 메서드를 호출함으로써 바꿀 수 있습니다. 그러나, 이 메서드를 사용할 때는 조심해야 하는데, 이는 여러분의 유형이 전체 응용 프로그램에 대한 정책을 제어하기 때문입니다.
  
• 런타임은 어떤 Finalize 메서드가 호출되는가 하는 순서의 문제에 관해서는 아무 보증도 하지 않습니다. 예를 들어, 내부 개체에 대한 포인터를 보유한 개체가 있다고 합시다. 가비지 수집기에서는 두 개체가 모두 가비지라는 사실을 파악했습니다. 덧붙여, 내부 개체의 Finalize 메서드가 먼저 호출됩니다. 이제, 외부 개체의 Finalize 메서드는 내부 개체를 액세스하고 그 위에 메서드를 호출하도록 되어 있으나, 내부 개체는 마무리되었고 그 결과는 예측할 수 없는 상태입니다. 따라서, Finalize 메서드는 내부 구성원 개체를 액세스하지 않는 것이 좋습니다.
  

public class BaseObj {
    public BaseObj() {
    }

    protected override void Finalize() {
        Console.WriteLine("In Finalize."); 
        base.Finalize();    // Call base type's Finalize
    }
}

class MyObject {
    ~MyObject() {
        ???
    }
}

class MyObject {
    protected override void Finalize() {
        ???
        base.Finalize();
    }
}

public class BaseObj {

    protected override void Finalize() {
        Application.ObjHolder = this; 
    }
}

class Application {
    static public Object ObjHolder;    // Defaults to null
???
}

public class BaseObj {

    protected override void Finalize() {
        Application.ObjHolder = this; 
        GC.ReRegisterForFinalize(this);
    }
}

FileStream fs = new FileStream("C:\\SomeFile.txt", 
    FileMode.Open, FileAccess.Write, FileShare.Read);
StreamWriter sw = new StreamWriter(fs);
sw.Write ("Hi there");

// The call to Close below is what you should do
sw.Close();   
// NOTE: StreamWriter.Close closes the FileStream. The FileStream
//       should not be explicitly closed in this scenario