Microsoft MVP성태의 닷넷 이야기
.NET Framework: 742. windbg로 확인하는 Finalizer를 가진 객체의 GC 과정 [링크 복사], [링크+제목 복사]
조회: 14810
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
[gc_dtor.zip]    
(연관된 글이 2개 있습니다.)

windbg로 확인하는 Finalizer를 가진 객체의 GC 과정

객체가 GC되었는지 확인하는 방법을 알아봤는데요.

windbg로 확인하는 객체의 GC 여부
; https://www.sysnet.pe.kr/2/0/11509

그럼, Finalizer를 가진 객체로도 테스트를 해보겠습니다. 이를 위해 지난 예제의 Program 클래스에 Finalizer를 추가한 후,

using System;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            Instance();

            Console.ReadLine();    // .NET 4 + x64 + Release 모드로 실행 후,
                                   // 이 시점에 Dump를 뜨고,

            GC.Collect(2, GCCollectionMode.Forced);     // 엔터를 치면 GC가 수행되고,
                                                        // 이 시점에 다시 Dump를 뜸
            Console.ReadLine();
        }

        private static void Instance()
        {
            Program pg = new Program();
        }

        ~Program()
        {
            Console.WriteLine("GCed");
        }
    }
}

GC.Collect 수행 전/후에 따라 덤프를 뜹니다. 우선 GC.Collect를 수행하기 전의 덤프를 분석하면 지난 글에서 설명한 데로 Program 객체는 0 세대 힙에 놓인 것을 확인할 수 있습니다.

0:000> .loadby sos clr

0:000> !dumpheap -type ConsoleApp2.Program
         Address               MT     Size
0000018414812df0 00007ff8a7185a28       24     

Statistics:
              MT    Count    TotalSize Class Name
00007ff8a7185a28        1           24 ConsoleApp2.Program
Total 1 objects

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000018414811030
generation 1 starts at 0x0000018414811018
generation 2 starts at 0x0000018414811000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000018414810000  0000018414811000  0000018414817fe8  0x6fe8(28648)
Large object heap starts at 0x0000018424811000
         segment             begin         allocated              size
0000018424810000  0000018424811000  00000184248199e8  0x89e8(35304)
Total Size:              Size: 0xf9d0 (63952) bytes.
------------------------------
GC Heap Size:            Size: 0xf9d0 (63952) bytes.

이 상태에서 finalizequeue 명령을 실행하면 다음과 같은 결과를 얻을 수 있습니다.

0:000> !finalizequeue
SyncBlocks to be cleaned up: 0
Free-Threaded Interfaces to be released: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
generation 0 has 9 finalizable objects (0000018412b5a610->0000018412b5a658)
generation 1 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
generation 2 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
Ready for finalization 0 objects (0000018412b5a658->0000018412b5a658)
Statistics for all finalizable objects (including all objects ready for finalization):
              MT    Count    TotalSize Class Name
00007ff902a13f60        1           24 System.WeakReference
00007ff8a7185a28        1           24 ConsoleApp2.Program
00007ff902a31a38        1           32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
00007ff902a319a8        1           32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle
00007ff9029fc3e0        1           32 Microsoft.Win32.SafeHandles.SafePEFileHandle
00007ff9029fd680        1           64 System.Threading.ReaderWriterLock
00007ff9029fa3f0        2           64 Microsoft.Win32.SafeHandles.SafeFileHandle
00007ff9029f7f28        1           96 System.Threading.Thread
Total 9 objects

이 출력 결과에서 아래의 세 라인이 바로 소멸자 큐(Finalization queue)의 내용이고,

generation 0 has 9 finalizable objects (0000018412b5a610->0000018412b5a658)
generation 1 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
generation 2 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)

그다음 라인의 내용이 FReachable Queue입니다.

Ready for finalization 0 objects (0000018412b5a658->0000018412b5a658)

즉, 현재 소멸자를 가진 클래스의 인스턴스가 9개 생성된 상태이고 해당 객체들은 모두 0 세대 힙에 있습니다.

참고로, dumpheap으로 구한 객체의 주소로 gcroot 명령어를 이용하면 Finalization queue에도 root 참조가 있는지 곧바로 확인할 수 있습니다.

0:000> !gcroot 0000018414812df0
Finalizer Queue:
    0000018414812df0
    -> 0000018414812df0 ConsoleApp2.Program




그다음 GC.Collect를 수행한 후의 덤프를 분석하면, 이번에는 Program 객체가 GC되지 않고 1 세대 힙에 놓인 것을 볼 수 있습니다.

0:000> !dumpheap -type ConsoleApp2.Program
         Address               MT     Size
0000018414812df0 00007ff8a7185a28       24     

Statistics:
              MT    Count    TotalSize Class Name
00007ff8a7185a28        1           24 ConsoleApp2.Program
Total 1 objects

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000018414816c88
generation 1 starts at 0x0000018414811018
generation 2 starts at 0x0000018414811000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000018414810000  0000018414811000  0000018414818ca0  0x7ca0(31904)
Large object heap starts at 0x0000018424811000
         segment             begin         allocated              size
0000018424810000  0000018424811000  00000184248199e8  0x89e8(35304)
Total Size:              Size: 0x10688 (67208) bytes.
------------------------------
GC Heap Size:            Size: 0x10688 (67208) bytes.

즉, Finalizer를 구현한 객체는 소멸자 큐에 등록된 것으로 인해 여전히 root 참조가 살아 있으므로 GC.Collect 이후 곧바로 GC되지 않고 1 세대 힙으로 승격하게 됩니다. (물론 일반적인 객체였다면 이 과정에서 root 참조가 없기 때문에 정리가 됩니다.)

또한 1 세대 힙으로 승격함과 동시에 소멸자 큐의 root 참조가 없어지고 FReachable Queue로 이동하게 됩니다. 그래서 첫 번째 GC.Collect 이후에는 다음과 같이 소멸자 큐의 등록이 없어진 것을 확인할 수 있습니다.

0:000> !gcroot 0000018414812df0
Found 0 unique roots (run '!GCRoot -all' to see all roots).




소멸자의 동작과 관련해 "소멸자 큐(finalization queue)"와 "FReachable Queue"가 있습니다. 제 책에서도 설명했지만, GC.Collect 시에 소멸자 큐에서 나온 객체는 FReachable Queue로 이동하고 이 시점에 대기하고 있던 소멸자 스레드가 FReachable Queue에 있는 항목을 곧바로 꺼내 소멸자 메서드를 호출합니다.

그래서 FReachable Queue에 객체가 있는 경우를 확인하기가 (일반적인 응용 프로그램의 경우) 쉽지 않습니다.

물론 억지로 ^^ 재현하면 쉽게 확인할 수 있습니다. 가령, 다음과 같이 소멸자를 갖는 객체를 하나 더 추가하는 것입니다.

using System;
using System.Threading;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            Instance();
            Console.ReadLine();

            GC.Collect(2, GCCollectionMode.Forced);
            Console.ReadLine();
        }

        private static void Instance()
        {
            Program pg = new Program();
            LongDtor ld = new LongDtor();
        }

        ~Program()
        {
            Thread.Sleep(1000 * 60);
            Console.WriteLine("Program.GCed");
        }
    }

    class LongDtor
    {
        ~LongDtor()
        {
            Thread.Sleep(1000 * 60);
            Console.WriteLine("LongDtor.GCed");
        }
    }
}

위와 같이 하면, GC.Collect 이후 2개의 객체(pg, ld)가 소멸자 큐에서 FReachable 큐로 이동할 것입니다. 이동하자마자 소멸자 스레드에 의해 꺼내져 dtor를 실행하게 될 텐데, 어느 쪽의 객체를 먼저 꺼내든 60초의 시간 동안 그다음 객체를 꺼낼 수 없으므로 적어도 1개의 객체가 FReachable 큐에 (60초 동안은) 머물게 됩니다.

따라서 첫 번째 GC.Collect 호출 후 덤프를 떠서 finalizequeue 명령으로 확인하면,

0:000> !finalizequeue
SyncBlocks to be cleaned up: 0
Free-Threaded Interfaces to be released: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
generation 0 has 0 finalizable objects (000001f15f1bc4d0->000001f15f1bc4d0)
generation 1 has 8 finalizable objects (000001f15f1bc490->000001f15f1bc4d0)
generation 2 has 0 finalizable objects (000001f15f1bc490->000001f15f1bc490)
Ready for finalization 1 objects (000001f15f1bc4d0->000001f15f1bc4d8)
Statistics for all finalizable objects (including all objects ready for finalization):
              MT    Count    TotalSize Class Name
00007ff902a13f60        1           24 System.WeakReference
00007ff8a7175a30        1           24 ConsoleApp2.Program
00007ff902a31a38        1           32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
00007ff902a319a8        1           32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle
00007ff9029fc3e0        1           32 Microsoft.Win32.SafeHandles.SafePEFileHandle
00007ff9029fd680        1           64 System.Threading.ReaderWriterLock
00007ff9029fa3f0        2           64 Microsoft.Win32.SafeHandles.SafeFileHandle
00007ff9029f7f28        1           96 System.Threading.Thread
Total 9 objects

GC.Collect로 인해 0 세대 힙에 있던 소멸자를 가진 10개의 객체 중 8개가 소멸자 큐(Finalization queue)에 머물러 있고,

generation 0 has 0 finalizable objects (000001f15f1bc4d0->000001f15f1bc4d0)
generation 1 has 8 finalizable objects (000001f15f1bc490->000001f15f1bc4d0)
generation 2 has 0 finalizable objects (000001f15f1bc490->000001f15f1bc490)

2개의 객체는 Finalization queue에서 꺼내져 Freachable Queue에 들어갔습니다.

Ready for finalization 1 objects (000001f15f1bc4d0->000001f15f1bc4d8) 

만약 소멸자 스레드에 의해 꺼내지지 않았다면 위의 출력 결과는 "2 objects"로 나오겠지만, 거의 곧바로 실행되기 때문에 Freachable Queue에 들어간 2개의 객체 중 한 개는 꺼내져서 소멸자 스레드에 의해 dtor가 호출 중이며 나머지 한 개는 아직 Freachable Queue에 머물러 있는 것입니다.

실제로 Freachable Queue에서 남아 있는 1개의 객체를 다음과 같이 덤프할 수 있습니다.

0:000> dq 000001f15f1bc4d0 L1
000001f1`5f1bc4d0  00000184`14812df0

0:000> !do 00000184`14812df0
Name:        ConsoleApp2.Program
MethodTable: 00007ff8a7185a28
EEClass:     00007ff8a71824f8
Size:        24(0x18) bytes
File:        E:\ConsoleApp2\bin\Release\ConsoleApp2.exe
Fields:
None

따라서 현재 소멸자 스레드에 의해 꺼내져 실행되고 있는 객체는 ConsoleApp2.LongDtor 클래스의 인스턴스임을 예상할 수 있습니다.




이번 테스트를 통해 제가 그동안 잘못 알고 있던 것을 바로잡을 수 있게 되었습니다. 예전에는 다음과 같은 절차로 소멸자를 가진 객체가 없어진다고 알고 있었는데,

1. dtor를 가진 객체 생성
    1.1 GC Heap 0 세대에 객체가 등록됨
[객체가 scope을 벗어남]
2. 첫 번째 GC 수행 시 root 참조들이 없지만 dtor를 가지므로 GC heap에서 Finalization queue로 이동
3. 두 번째 GC 수행 시 Finalization queue에서 Freachable Queue로 이동하고, 그 순간 소멸자 스레드에 의해 실행

실제로 테스트해본 결과 다음과 같이 진행되고 있었습니다.

1. dtor를 가진 객체 생성
    1.1 GC Heap 0 세대에 객체가 등록됨
    1.2 소멸자 큐(Finalization queue)에도 객체가 등록됨
[객체가 scope을 벗어남]
2. 첫 번째 GC 수행 시
    2.1 소멸자 큐에 root 참조가 있으므로 1 세대로 승격
    2.2 소멸자 큐의 root 참조를 비우고 Freachable Queue로 이동
    2.3 Freachable Queue로 이동하자마자 소멸자 스레드가 꺼내 실행
[따라서 이 시점에는 GC Heap 1 세대에만 참조가 있음]
3. 두 번째 GC 수행 시 GC Heap 1 세대의 객체가 정리됨

음... 책 내용을 수정해야겠군요. ^^




그렇다면 WeakReference는 Finalizer를 가진 객체에 대해 언제 IsAlive 값이 False가 될까요? 얼핏 생각해 보면, 첫 번째 GC 수행 후에도 여전히 GC Heap 1 세대에 살아있으므로 그 시점까지는 IsAlive 값이 True로 유지될 듯싶었는데요. 테스트 결과 GC Heap 1 세대에 있음에도 불구하고 무조건 IsAlive = False로 되는 것을 확인할 수 있습니다.

이러한 시점 상의 문제로 WeakReference는 해당 객체가 실제로 GC되지 않아도 참조를 잃어버리게 됩니다. 예를 들어 (권장되지 않지만) 소멸자에서 해당 객체를 다시 부활(resurrection) 시키는 경우도 있을 텐데, WeakReference는 이런 상황을 고려하지 않습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 4/30/2018]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  [35]  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
12753정성태8/5/20218352오류 유형: 749. PyCharm - Error: Django is not importable in this environment
12752정성태8/4/20216430개발 환경 구성: 592. JetBrains의 IDE(예를 들어, PyCharm)에서 Visual Studio 키보드 매핑 적용
12751정성태8/4/20219502개발 환경 구성: 591. Windows 10 WSL2 환경에서 docker-compose 빌드하는 방법
12750정성태8/3/20216291디버깅 기술: 181. windbg - 콜 스택의 "Call Site" 오프셋 값이 가리키는 위치
12749정성태8/2/20215704개발 환경 구성: 590. Visual Studio 2017부터 단위 테스트에 DataRow 특성 지원
12748정성태8/2/20216310개발 환경 구성: 589. Azure Active Directory - tenant의 관리자(admin) 계정 로그인 방법
12747정성태8/1/20216907오류 유형: 748. 오류 기록 - MICROSOFT GRAPH – HOW TO IMPLEMENT IAUTHENTICATIONPROVIDER파일 다운로드1
12746정성태7/31/20218929개발 환경 구성: 588. 네트워크 장비 환경을 시뮬레이션하는 Packet Tracer 프로그램 소개
12745정성태7/31/20216766개발 환경 구성: 587. Azure Active Directory - tenant의 관리자 계정 로그인 방법
12744정성태7/30/20217374개발 환경 구성: 586. Azure Active Directory에 연결된 App 목록을 확인하는 방법?
12743정성태7/30/20218050.NET Framework: 1083. Azure Active Directory - 외부 Token Cache 저장소를 사용하는 방법파일 다운로드1
12742정성태7/30/20217316개발 환경 구성: 585. Azure AD 인증을 위한 사용자 인증 유형
12741정성태7/29/20218523.NET Framework: 1082. Azure Active Directory - Microsoft Graph API 호출 방법파일 다운로드1
12740정성태7/29/20217205오류 유형: 747. SharePoint - InvalidOperationException 0x80131509
12739정성태7/28/20217162오류 유형: 746. Azure Active Directory - IDW10106: The 'ClientId' option must be provided.
12738정성태7/28/20217739오류 유형: 745. Azure Active Directory - Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI).
12737정성태7/28/20216708오류 유형: 744. Azure Active Directory - The resource principal named api://...[client_id]... was not found in the tenant
12736정성태7/28/20217209오류 유형: 743. Active Azure Directory에서 "API permissions"의 권한 설정이 "Not granted for ..."로 나오는 문제
12735정성태7/27/20217738.NET Framework: 1081. C# - Azure AD 인증을 지원하는 데스크톱 애플리케이션 예제(Windows Forms) [2]파일 다운로드1
12734정성태7/26/202123744스크립트: 20. 특정 단어로 시작하거나/끝나는 문자열을 포함/제외하는 정규 표현식 - Look-around
12733정성태7/23/202111076.NET Framework: 1081. Self-Contained/SingleFile 유형의 .NET Core/5+ 실행 파일을 임베딩한다면? [1]파일 다운로드2
12732정성태7/23/20216367오류 유형: 742. SharePoint - The super user account utilized by the cache is not configured.
12731정성태7/23/20217479개발 환경 구성: 584. Add Internal URLs 화면에서 "Save" 버튼이 비활성화 된 경우
12730정성태7/23/20219036개발 환경 구성: 583. Visual Studio Code - Go 코드에서 입력을 받는 경우
12729정성태7/22/20217983.NET Framework: 1080. xUnit 단위 테스트에 메서드/클래스 수준의 문맥 제공 - Fixture
12728정성태7/22/20217461.NET Framework: 1079. MSTestv2 단위 테스트에 메서드/클래스/어셈블리 수준의 문맥 제공
... 31  32  33  34  [35]  36  37  38  39  40  41  42  43  44  45  ...