Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
[gc_dtor.zip]    

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@outlook.com

비밀번호

댓글 쓴 사람
 




... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...
NoWriterDateCnt.TitleFile(s)
11541정성태9/14/20182383개발 환경 구성: 380. Azure Web App 확장 배포 방법 [1]
11540정성태6/9/20182632개발 환경 구성: 379. Azure Web App 확장 예제 제작 [2]
11539정성태6/8/20182240.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입파일 다운로드1
11538정성태6/8/20181976.NET Framework: 762. .NET Core 2.1 - 확장 도구(Tools) 관리
11537정성태6/8/20183356.NET Framework: 761. C# - SmtpClient로 SMTP + SSL/TLS 서버를 이용하는 방법 [4]
11536정성태6/8/20183409.NET Framework: 760. Microsoft Build 2018 - The future of C# 동영상 내용 정리 [1]파일 다운로드1
11535정성태6/7/20183271.NET Framework: 759. C# - System.Span<T> 성능 [1]
11534정성태10/7/20194642.NET Framework: 758. C# 7.2 - Span<T> [3]
11533정성태6/8/20186405.NET Framework: 757. 포인터 형 매개 변수를 갖는 C++ DLL의 함수를 C#에서 호출하는 방법파일 다운로드1
11532정성태6/5/20183240.NET Framework: 756. JSON의 escape sequence 문자 처리 방식
11531정성태6/5/20185907오류 유형: 468. JSON.parse가 허용하지 않는 문자 [9]
11530정성태6/10/20184001.NET Framework: 755. C# 7.2 - 스택에만 생성할 수 있는 값 타입 지원 - "ref struct" [2]파일 다운로드1
11529정성태5/23/20183078.NET Framework: 754. 닷넷의 관리 포인터(Managed Pointer)와 System.TypedReference [5]파일 다운로드1
11528정성태6/10/20183084.NET Framework: 753. C# 7.2 - 3항 연산자에 ref 지원(conditional ref operator) [1]
11527정성태5/17/20182785오류 유형: 467. RDP 로그인 에러 - This could be due to CredSSP encryption oracle remediation.
11526정성태6/10/20182550.NET Framework: 752. C# 7.2 - 메서드의 반환값 및 로컬 변수에 ref readonly 기능 추가파일 다운로드1
11525정성태6/10/20182749.NET Framework: 751. C# 7.2 - 메서드의 매개 변수에 in 변경자 추가파일 다운로드1
11524정성태6/10/20183695.NET Framework: 750. C# 7.2 - readonly 구조체 [3]파일 다운로드1
11523정성태5/15/20183092.NET Framework: 749. C# - 값 형식의 readonly 인스턴스에 대한 메서드 호출 시 defensive copy 발생 [1]파일 다운로드1
11522정성태5/15/20181968개발 환경 구성: 378. Azure - VM 진단 설정 화면의 "This subscription is not registered with the Microsoft.Insights resource provider."
11521정성태5/15/20181981개발 환경 구성: 377. Azure - 원하는 성능 데이터로 모니터링 대시보드 구성
11520정성태5/12/20182605.NET Framework: 748. C# 7.1 - 참조 어셈블리(Ref Assemblies)
11519정성태3/13/20192797개발 환경 구성: 376. ASP.NET Web Application 프로젝트의 FileSystem 배포(Publish) 시 Before/After Task 설정 방법 [1]
11518정성태5/11/20182491.NET Framework: 747. C# 7.0에서도 부분적으로 가능해진 "타입 추론을 통한 튜플의 변수명 자동 지정"
11517정성태5/10/20182770.NET Framework: 746. Azure runbook 예제 - 6시간 동안 수행 중인 VM을 중지 [1]파일 다운로드1
11516정성태5/9/20182128.NET Framework: 745. Azure runbook을 PowerShell 또는 C# 코드로 실행하는 방법파일 다운로드1
... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...