Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 3개 있습니다.)

C# - 값 형식의 readonly 인스턴스에 대한 메서드 호출 시 defensive copy 발생

readonly 예약어가 기본형 타입에 적용되었을 때에는 명확하게 읽기 전용이 됩니다. 그런데, 클래스나 구조체 타입의 인스턴스에 대해서는 다소 의미가 달라집니다.

예를 들어, 다음의 사용 예를 보겠습니다.

using System;

class Program
{
    readonly StructPerson sarah = new StructPerson() { Name = "Kerrigan", Age = 27 };
    readonly ClassPerson james = new ClassPerson() { Name = "Raynor", Age = 30 };

    static void Main(string[] args)
    {
        Program pg = new Program();
        pg.Test();
    }

    private void Test()
    {
        // sarah.Age = 32; // 컴파일 오류: CS1648 Members of readonly field 'Program.sarah' cannot be modified (except in a constructor or a variable initializer)
        james.Age = 32; // 참조 형식의 경우 readonly 인스턴스의 멤버는 대입 가능

        Console.WriteLine("sarah age: " + sarah.Age);
        Console.WriteLine("james age: " + james.Age); // 출력 결과: james age: 32
    }
}

struct StructPerson
{
    public int Age;
    public string Name;
}

class ClassPerson
{
    public int Age;
    public string Name;
}

보는 바와 같이, readonly는 값 형식에 대해서는 필드의 변경에 대해 컴파일 시 체크를 하지만 참조 형식의 경우에는 허용합니다. (참조 형식의 특성상 readonly에 대한 이러한 동작은 당연하다고도 할 수 있습니다.)

문제는 값 형식의 readonly 인스턴스입니다. 위의 경우 필드에 대해서는 컴파일러가 막을 수 있었지만 다음과 같은 메시지 호출에 대해서는 - 그리고 그 메서드의 내부에서 필드 값을 바꾸는 코드까지 막지는 않습니다.

private void Test()
{
    sarah.IncAge();
    james.IncAge();
    
    Console.WriteLine("sarah age: " + sarah.Age); // 출력 결과: sarah age: 27
    Console.WriteLine("james age: " + james.Age); // 출력 결과: james age: 31
}

struct StructPerson
{
    public int Age;
    public string Name;

    public void IncAge()
    {
        Age++;
    }
}

class ClassPerson
{
    public int Age;
    public string Name;

    public void IncAge()
    {
        Age++;
    }
}

즉, 필드를 변경할 수 없게 만들었던 것과는 달리 위의 소스 코드는 값 형식의 readonly 필드에 대해서도 IncAge 메서드 호출이 잘 됩니다. 그런데 출력 결과를 보면 재미있습니다. 위에서 보다시피 "sarah age: 27: 상태에서 IncAge 메서드를 호출했는데도 불구하고 여전히 27로 출력이 되고 있습니다. 어떻게 이럴 수 있는 걸까요?

그 이면에는 C# 컴파일러의 숨은 노력이 들어 있습니다. 실제로 C# 컴파일러는 readonly 인스턴스가 값 형식일 때 그것의 메서드나 공용 속성을 접근하는 코드에 대해 사전에 임시 변수를 만들어 대신 호출하도록 바꿉니다. 아래는 값 형식인 sarah와 참조 형식인 james의 IncAge 호출 코드를 IL 언어로 나타낸 것입니다.

IL_0001: ldarg.0      // this
IL_0002: ldfld        valuetype readonly_value_ref.StructPerson readonly_value_ref.Program::sarah
IL_0007: stloc.0      // V_0
IL_0008: ldloca.s     V_0
IL_000a: call         instance void readonly_value_ref.StructPerson::IncAge()
IL_000f: nop          

IL_0010: ldarg.0      // this
IL_0011: ldfld        class readonly_value_ref.ClassPerson readonly_value_ref.Program::james
IL_0016: callvirt     instance void readonly_value_ref.ClassPerson::IncAge()
IL_001b: nop          

이것을 평범한 C# 코드로 다시 나타내면 이렇습니다.

StructPerson temp = sarah;
temp.IncAge();

james.IncAge();

sarah가 값 형식의 인스턴스이기 때문에 temp에 대입하게 되면 전체 값 복사가 수행됩니다. 그리고 그렇게 복사된 인스턴스에 대해 IncAge를 호출하는 것이기 때문에 원래의 sarah 인스턴스는 상태가 바뀌지 않고 - 마치 readonly처럼 동작하는 결과를 낳습니다.

이렇게 상태 변경을 방지하기 위해 수행되는 복사를 일컬어 "defensive copy"라고 합니다.




개인적으로 defensive copy에 대해서는... 찬성/반대를 할 수가 없습니다. 값 형식의 readonly를 지킨다는 점에서 일관성을 지니고 있지만, 때로는 그것이 소스 코드에 나타나지 않고 컴파일러에 의해 숨겨진 유형으로 실행되기 때문에 버그가 발생할 여지가 있습니다. 일례로 다음의 글에 나온,

The 'in'-modifier and the readonly structs in C#
; https://blogs.msdn.microsoft.com/seteplia/2018/03/07/the-in-modifier-and-the-readonly-structs-in-c/

예제 코드를 보겠습니다.

internal class ReadOnlyEnumerator
{
    private readonly List<int>.Enumerator _enumerator;
 
    public ReadOnlyEnumerator(List<int> list)
    {
        _enumerator = list.GetEnumerator();
    }
 
    public void PrintTheFirstElement()
    {
        _enumerator.MoveNext();
        Console.WriteLine(_enumerator.Current); // 출력 결과: 0
    }
}

var roe = new ReadOnlyEnumerator(new List<int>{1,2});
roe.PrintTheFirstElement();

충분히 위와 같이 코드를 만들 수 있습니다. 그런데, 왜? 출력 결과로 0이 나오는지 한참을 고민하게 만들 수도 있습니다. 위의 경우 List<int>.Enumerator 타입이 struct입니다. 따라서 그것의 readonly 필드를 정의했기 때문에 PrintTheFirstElement 내의 코드는 MoveNext 메서드와 Current 공용 속성의 접근에 대해 개별적으로 모두 "defensive copy"가 발생합니다. 그래서 IL 코드로는 다음과 같은 코드로 변환되는 것입니다.

public void PrintTheFirstElement_Decompiled()
{
    // 첫 번째 Defensive copy 발생
    var localEnumerator = _enumerator;
    localEnumerator.MoveNext();
 
    // 두 번째 Defensive copy 발생
    localEnumerator = _enumerator;
    Console.WriteLine(localEnumerator.Current);
}

위와 같은 코드 사용을 방지하려면, 애당초 List<int>.Enumerator 타입이 struct라는 정보를 알고 있어야 합니다. 그것만 알았어도 굳이 readonly 필드로 변경할 필요가 없었을 것이고, 만약 readonly로 바꾸고 싶었다면 반드시 "defensive copy"에 대한 사전 정보를 알고 있어야만 저런 식으로 결과가 나왔을 때 문제의 원인을 파악할 수 있게 됩니다.

과연 어느 것이 옳은 것일까요? 일관성이 중요할까요? 일관성을 해치면서 동작하는 코드가 중요할까요? ^^

(첨부 파일은 이에 대한 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 5/15/2018]

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

비밀번호

댓글 작성자
 



2018-05-23 12시59분
한글 도움말에 보면, "defensive copy"를 "방어 복사본"으로 번역했군요. ^^

값 형식과 참조 의미 체계
; https://learn.microsoft.com/ko-kr/dotnet/csharp/reference-semantics-with-value-types
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13570정성태2/29/202498닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/2024146닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/2024290닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/2024273오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/2024277오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/2024619닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20241019Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241043디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/2024993오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20241108닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20241152디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20241619오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20241227닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241095Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241161Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20241222닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241002VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241140닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241081닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20241183닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20241246Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20241524개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20241340개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20241161개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241089Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...