9-3.메모리 관리

9-3-1.가비지 컬렉터의 동작

닷넷은 가비지 컬렉터가 메모리를 자동 관리한다. 여기서는 가비지 컬렉터의 내부 동작에 대해 연구해 보자. 가비지 컬렉터는 백그라운드에서 항상 실행중이며 더 이상 사용되지 않는 메모리, 즉 쓰레기를 찾아 회수한다. 개발자는 new 연산자로 필요한만큼 객체나 메모리를 할당해서 쓰다가 그냥 나가 버리면 된다.

 

void func() {

         int[] ar = new int[10];

         DateTime Now = new DateTime(1970, 6, 29);

         // 객체를 실컷 사용한다.

}

 

정수형 배열과 DateTime 객체를 지역변수로 선언하여 실컷 쓰다가 해제나 파괴할 필요 없이 싸질러 놓고 도망가 버리면 그만이다. delete 키워드는 아예 존재하지 않으며 모든 뒤치닥거리는 가비지 컬렉터가 맡는다. 해제를 위한 복잡한 제어문이 필요 없어 편리할 뿐만 아니라 안정성도 높고 예외나 실수에 의해 메모리가 누출될 위험도 없다.

가비지 컬렉터는 쓰레기 수집 외에도 낮은 번지부터 순서대로 할당하여 힙을 관리하는 중요한 역할을 한다. 객체가 만들어지고 회수되기를 반복하면 힙의 중간 중간이 비는 단편화 현상이 일어난다. 가비지 컬렉터는 남아 있는 메모리를 이동시켜 큰 덩어리를 만드는 컴팩션(Compaction)을 수행한다.

중간의 객체가 해제되면 남은 공간은 많아도 조각난 상태여서 큰 메모리를 할당할 수 없다. 이럴때 남은 객체를 앞쪽으로 이동시켜 단편화를 제거한다. 구획 정리를 통한 일종의 메모리 압축이며 하드디스크의 조각 모음과 비슷하다. 힙은 항상 관리중이어서 객체의 번지는 고정되어 있지 않고 힙의 어딘가를 떠 돌아 다닌다. 그래서 포인터를 쓸 수 없지만 대신 객체와 함께 갱신되는 참조자를 통해 액세스할 수 있다. 응용 프로그램 입장에서 컴팩션은 투명하다.

가비지 컬렉터가 회수할 객체를 선정하는 알고리즘은 정교하다. 객체는 보통 루트 밑에 차일드가 계층적으로 존재하는 트리 구조이다. 폼 아래 자식 컨트롤이 주렁 주렁 달려 있는 경우인데 차일드끼리도 상호 참조 가능해 정확하게는 그래프 구조이다. 가비지 컬렉터는 전역, 정적, 지역 등 각 범주별로 트리를 관리하며 루트부터 순회한 후 도달할 수 없는 객체를 찾는다. 참조 카운트 방법보다 빠르고 신뢰성이 높으며 버려진 객체끼리 상호 참조하는 경우도 잘 적발한다. 루트가 해제되면 그 아래의 모든 객체는 일괄 해제된다.

객체가 많아지면 골라내는 데도 시간이 많이 걸려 세대를 관리하는 방식으로 검색 시간을 단축한다. 최근에 생성된 객체를 0세대라고 하며 1차 수집대상이다. 한 번 수집한 후 살아 남은 객체는 1세대로 옮겨지고 0세대에 비해 가끔씩 점검한다. 0세대를 수집하고도 부족할 때만 1세대를 수집하며 이때 살아남은 객체는 2세대가 되어 오래 유지된다. 세대 알고리즘은 최근 객체가 가비지의 확률이 높고 오래 생존한 객체는 더 오래 유지되는 특성을 활용한 것이다. 털어서 나올만한 놈은 자주 털고 오래 살아 남은 객체는 가급적 제외하여 속도를 높인다. 다음 코드에는 두 개의 객체가 있다.

 

class Some {

         int[] A = new int[10];

         void Method() {

                      int[] B = new int[10];

         }

}

 

A는 필드이고 B는 지역변수다. 클래스 소속의 A가 메서드 소속의 B보다 생명이 더 길 것임을 짐작할 수 있다. B는 메서드 종료시 0세대에서 즉시 회수되지만 A는 객체가 있는 한 회수되지 않고 1, 2 세대가 되어 더 오랫동안 살아 남는다. 내부는 훨씬 더 복잡하고 정교하지만 대충만 봐도 꽤 똑똑하다는 것을 눈치챌 수 있다. 어련히 알아서 잘 만들어 놨을 것이고 믿고 맡겨 두면 되지만 필요하다면 System.GC 클래스를 통해 가비지 컬렉터의 동작을 제어할 수 있다.

 

메서드

설명

Collect

메모리를 즉시 회수한다. 인수로 대상 세대를 지정할 수 있으며 세대를 지정하지 않으면 모든 세대가 회수된다. 그러나 모든 메모리가 즉시 회수된다는 것을 보장할 수는 없다.

GetGeneration

객체의 현재 세대 번호를 조사한다.

GetTotalMemory

현재 할당되어 있는 메모리양을 조사한다.

KeepAlive

지정한 객체가 쓰레기 수집되지 않도록 보장한다. 비관리 코드에서 사용되는 객체는 너무 일찍 회수되지 않도록 잠시 보호해야 한다. 일시적으로 객체의 수명이 연장된다.

SuppressFinalize

지정한 객체의 파괴자를 호출하지 않도록 한다. 이 메서드는 객체 헤더의 특정한 비트를 설정하여 파괴자 호출을 막는다.

ReRegisterForFinalize

파괴자를 다시 호출하도록 한다.

WaitForPendingFinalizers

파괴자 큐를 정리하는 동안 현재 스레드를 잠시 대기시킨다.

 

하지만 이 메서드들은 함부로 호출하지 말아야 한다. 알아서 잘 동작하는데 쓸데없이 훈수를 두면 비효율이 발생한다. 한 번쯤 Collect로 메모리를 확보해 보고 싶은 유혹이 들더라도 응용 프로그램이 메모리 관리에 간섭하는 것은 바람직하지 않다.

메모리를 싹싹 긁어 모아야 할 정도의 상황이 자주 발생한다면 메모리를 늘리는 것이 합리적이고 손쉬운 해결책이다. 개발자답지 못한 망언으로 들릴지 모르겠지만 그게 싫다면 C#이나 자바를 써서는 안되며 C++로 돌아가야 한다. 고수준 프레임워크에서 메모리 부족은 응용 프로그램의 책임이 아니다.

9-3-2.IDisposable

가비지 컬렉터는 관리 자원만 수집한다. 메모리와 무관한 파일이나 하드웨어 환경 변화, 네트웍 접속 등은 객체가 직접 관리해야 한다. 이럴 때는 파괴자를 사용하는데 앞에서 Destructor 예제로 소켓 연결을 관리해 보았다.

문제는 파괴자가 언제 호출될지 예측할 수 없다는 점이다. 가비지 컬렉터는 객체 삭제시 파괴자 큐에 대기시켜 놓고 한가할 때 파괴자를 호출한다. S가 파괴된 후 1234 포트를 사용하는 T 객체를 다시 생성하려면 S가 즉시 1234포트를 해제해야 하는데 파괴자가 실시간으로 호출되지 않아 문제가 된다.

비관리 자원을 즉시 해제하거나 관리 자원이라도 신속하게 해제하려면 별도의 해제 메서드를 만들어야 한다. 해제 메서드는 IDisposable 인터페이스의 Dispose를 쓰도록 약속되어 있다. Dispose는 인수도, 리턴값도 없으며 자원만 해제한다.

 

Destructor2

실행결과

using System;

 

class Socket : IDisposable {

             private int SocketPort;

             public Socket(int port) {

                           SocketPort = port;

                           Console.WriteLine($"{port} 포트로 소켓을 연결한다.");

             }

             public void Dispose() {

                           SocketPort = 0;

                           Console.WriteLine("소켓 연결을 해제한다.");

             }

}

 

class CSTest {

             static void Main() {

                           Socket S = new Socket(1234);

                           Console.WriteLine("주거니 받거니 통신했다 치고...");

                           S.Dispose();

             }

}

1234 포트로 소켓을 연결한다.

주거니 받거니 통신했다 치고...

소켓 연결을 해제한다.

 

파괴자 대신 Dispose에서 명시적으로 자원을 해제하면 호출 즉시 동작하여 불확실성이 제거된다. 그러나 사용자가 깜박 잊고 Dispose 호출을 누락하면 해제되지 않는 잠재적인 문제가 있으며 이 경우 프로그램을 종료해도 미해제 상황이 지속된다.

사용자의 과실이라도 욕은 개발자가 먹기 마련이어서 최소한의 방어가 더 필요하다. 이런 경우는 파괴자와 Dispose를 동시에 구현하여 관리 자원과 비관리 자원을 분담하여 해제하되 이중해제 하지 않도록 주의해야 한다. 다음 예제는 제반의 문제를 해결한 것이다.

 

Dispose

using System;

 

class Socket : IDisposable {

             private int SocketPort;

             private bool Disposed = false;

             public Socket(int port) {

                           SocketPort = port;

                           Console.WriteLine($"{port} 포트로 소켓을 연결한다.");

             }

             public void Dispose() {

                           Dispose(true);

                           GC.SuppressFinalize(this);

             }

             public virtual void Dispose(bool bManage) {

                           if (Disposed) return;

                           Disposed = true;

                           if (bManage) {

                                        // 여기서 관리 자원을 해제한다.

                           }

                           SocketPort = 0;

                           Console.WriteLine("소켓 연결을 해제한다.");

             }

             ~Socket() {

                           Dispose(false);

             }

}

 

class CSTest {

             static void Main() {

                           Socket S = new Socket(1234);

                           Console.WriteLine("주거니 받거니 통신했다 치고...");

                           S.Dispose();

             }

}

 

Dispose 외에 Dispose(bool) 메서드가 하나 더 있어 bManage 인수에 따라 모든 자원 또는 비관리 자원만 해제한다. 코드 중복을 방지하기 위해 실제 자원 해제 코드는 이 메서드에 작성해 놓고 파괴자와 Dispose()에서 호출한다. Disposed 필드는 이중 해제를 방지하기 위한 플래그이다. Disposed가 false일 때만 연결을 끊으며 그 사실을 Disposed에 기록해 둔다.

두 개의 Dispose와 파괴자가 해제를 분담하는데 각 메서드는 호출 경로와 역할이 다르다. 파괴자는 자신이 직접 할당한 비관리 자원만 해제하며 관리 자원은 건드리지 않는다. 파괴자는 호출 시기를 예측할 수 없는데 아직 파괴되지 않은 다른 객체가 이 객체를 참조하고 있을 가능성이 있다. 관리 자원은 가비지 컬렉터에게 일임하여 관련 객체를 같이 해제하도록 내버려 두는 것이 바람직하다.

Dispose()는 Dispose(true)를 호출하여 모든 자원을 해제하며 생성 전의 상태로 복구한다. 모든 자원이 다 해제되었으므로 GC.SupressFinalize 메서드로 파괴자 호출을 금지시킨다. 이 처리를 생략하면 이중 해제의 문제가 발생한다.

통신을 마친 후 연결을 즉시 끊고 싶을 때는 Dispose 메서드를 호출하여 모든 자원을 해제하며 이때 파괴자는 호출할 필요 없다. 즉시 끊을 필요가 없을 때는 가만히 내버려 두면 된다. 관리 자원은 가비지 컬렉터가 해제하고 비관리 자원은 파괴자가 해제한다.

자원 해제 메서드는 직접 호출하는 것이어서 CleanUp이나 Close 또는 ChiARa 같은 이름으로 작성할 수도 있다. 그러나 약속된 IDisposable 인터페이스를 쓰면 using 블록에서 해제 메서드를 자동으로 호출해 주는 이점이 있다. Main 메서드를 다음과 같이 수정해도 결과는 같다.

 

 static void Main() {

          using (Socket S = new Socket(1234)) {

                       Console.WriteLine("주거니 받거니 통신했다 치고...");

          }

 }

 

using은 객체가 블록을 벗어날 때 Dispose를 자동으로 호출하며 이런 동작이 가능하려면 메서드의 이름이 정해져 있어야 한다. 이 약속을 강제하는 장치가 IDisposable 인터페이스이다.

using 블록 대신 finally 예외 처리 구문으로도 똑같은 효과를 볼 수 있으며 실제로 using 블록은 try, finally 블록으로 컴파일된다. 매번 이렇게 블록을 감싸기 귀찮기 때문에 컴파일러가 using 블록을 제공하고 블록이 끝날 때 Dispose를 자동으로 호출한다.

 

try {

         Socket S = new Socket(1234)

         Console.WriteLine("주거니 받거니 통신했다 치고...");

}

finally {

         S.Dispose();

}

 

using 키워드는 네임스페이스를 지정할 때도 쓰고 자원 해제 블록에도 사용하여 중복된 의미를 가진다. 그러나 철자만 같지 의미는 완전히 다르다. 하나의 키워드를 두 가지 이상의 의미로 사용하는 것을 키워드 중복(Keyword overloading)이라고 하는데 일종의 동음 이의어이다.

객체를 생성하는 연산자 new와 부모의 메서드를 숨기는 new도 키워드 중복의 예이다. 키워드의 개수를 최소화하여 사용자에게 명칭 선택의 자유를 준다는 긍정적인 의미가 있지만 문법을 지저분하게 만드는 부정적인 면도 있다. 여러 주체가 관여한 과거의 언어는 어쩔 수 없었다 쳐도 한 회사에서 만든 C#의 키워드 중복은 좀 아쉬운 대목이다.