Microsoft MVP성태의 닷넷 이야기
.NET Framework: 660. Shallow Copy와 Deep Copy [링크 복사], [링크+제목 복사]
조회: 14702
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 9개 있습니다.)
.NET Framework: 90. XmlSerializer 생성자의 실행 속도를 올리는 방법
; https://www.sysnet.pe.kr/2/0/511

.NET Framework: 92. XmlSerializer 생성자의 실행 속도를 올리는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/521

.NET Framework: 100. XML Serializer를 이용한 값 복사
; https://www.sysnet.pe.kr/2/0/577

.NET Framework: 122. XML Serializer를 이용한 값 복사: 성능은 어떨까!
; https://www.sysnet.pe.kr/2/0/653

.NET Framework: 648. Dictionary<TKey, TValue>를 deep copy하는 방법
; https://www.sysnet.pe.kr/2/0/11157

.NET Framework: 660. Shallow Copy와 Deep Copy
; https://www.sysnet.pe.kr/2/0/11220

.NET Framework: 1141. XmlSerializer와 Dictionary 타입
; https://www.sysnet.pe.kr/2/0/12942

.NET Framework: 2078. .NET Core/5+를 위한 SGen(Microsoft.XmlSerializer.Generator) 사용법
; https://www.sysnet.pe.kr/2/0/13196

.NET Framework: 2080. C# - Microsoft.XmlSerializer.Generator 처리 없이 XmlSerializer 생성자를 예외 없이 사용하고 싶다면?
; https://www.sysnet.pe.kr/2/0/13198




닷넷 - Shallow Copy와 Deep Copy

아래의 글을 읽고 잠깐 정리해 봅니다. ^^

[.NET] Clone
; http://www.jumptovb.net/397

닷넷의 System.Object 타입에는 MemberwiseClone 메서드가 (protected 접근자로) 기본 포함되어 있습니다.

Object.MemberwiseClone 메서드
; https://learn.microsoft.com/en-us/dotnet/api/system.object.memberwiseclone

도움말에도 나오지만 이 메서드를 수행하면 "shallow copy"를 한 객체를 반환해 줍니다. 따라서, MemberwiseClone 메서드와 동일한 기능을 구현하고 싶다면 다음과 같이 해주면 됩니다.

public class MyItem
{
    public string Name;
    public int Age;

    public MyItem()
    {
    }

    // MemberwiseClone 메서드와 동일한 기능 (shallow copy 수행)
    public object Clone()
    {
        MyItem obj = new MyItem();

        // 필드 수만큼 대입
        obj.Name = this.Name; 
        obj.Age = this.Age;

        return obj;        
    }
}

비교를 위해 Clone을 하지 않고 참조 값만 대입한 경우를 보면,

MyItem a = new MyItem { Name = "AAA", Age = 5 };
MyItem b = a;

이때의 메모리 상황은 다음과 같습니다.

shallow_deep_copy_1.png

하지만, shallow copy를 하게 되면,

MyItem a = new MyItem { Name = "AAA", Age = 5 };
MyItem b = a.Clone() as MyItem;

메모리 상황이 다음과 같이 바뀝니다.

shallow_deep_copy_2.png

위의 그림을 보면, MyItem에 해당하는 인스턴스 a, b는 힙에서 별도의 구역으로 존재하지만 그 내부에서 담고 있는 참조 값들은 여전히 동일한 객체를 가리키는 것을 확인할 수 있습니다. 즉, Name 필드의 참조 값이 0x1800으로 동일하게 "AAA" 객체를 가리키고 있는 것입니다. 반면, Age 필드는 MyItem 객체에 할당된 메모리 내에 값 자체(위의 예에서는 5)로 포함됩니다.




그럼, deep copy는 뭘까요? 아래의 글에 보면,

XML Serializer를 이용한 값 복사
; https://www.sysnet.pe.kr/2/0/577

Dictionary<TKey, TValue>를 deep copy하는 방법
; https://www.sysnet.pe.kr/2/0/11157

deep copy는 해당 객체를 복사할 때, 필드 유형이 참조 타입일지라도 별도의 메모리에 개별 인스턴스로 복사하는 것을 의미합니다.

MyItem a = new MyItem { Name = "AAA", Age = 5 };
MyItem b = CloneData<MyItem>(a);

따라서 위와 같이 객체를 복사하게 되면 메모리 상에 다음과 같은 식으로 표현이 바뀝니다.

shallow_deep_copy_3.png

(주의: 위의 그림은 "Name" 필드의 타입이 string이 아닌 다른 참조 타입일 경우에만 올바릅니다. string 타입은 CLR 내부의 최적화로 인해 같은 문자열은 중복 할당하지 않도록 내부 풀로 관리되기 때문에 2개의 "AAA" 인스턴스가 아닌 1개의 "AAA" 문자열 인스턴스만 생성됩니다.)

차이점이 뭔지 아시겠죠? (MemberwiseClone을 비롯한) shallow copy는 해당 객체의 멤버 중 참조 타입은 공유하지만, deep copy는 참조 타입까지도 별도의 인스턴스로 분리시켜 복사하는 것을 의미합니다.




참조 타입을 공유하는 shallow copy의 특성상 때로는 혼란이 올 수 있습니다. 가령, 다음과 같은 코드를 보면,

MyItem a = new MyItem { Name = "AAA", Age = 5 };
MyItem b = a.Clone() as MyItem;

a.Name = "BBB";
Console.WriteLine(a.ToString()); // Name: BBB, Age: 5
Console.WriteLine(b.ToString()); // Name: AAA, Age: 5

분명히 참조 값 필드가 공유된다고 했음에도 불구하고 결과를 보면 a 객체의 Name 필드 변경이 b 객체의 Name 필드와는 무관하게 동작하고 있습니다. 이것은 shallow copy가 된 2개의 인스턴스에 대한 메모리 상태를 따져보면 그 이유를 알 수 있습니다.

즉, a.Name = "BBB" 코드의 실행 전에는 a, b 인스턴스가 각각 다음과 같은 값을 가지며 힙에 할당된 상태입니다.

// a 객체 8바이트 할당
(4바이트) a.Name: "AAA" 문자열 객체를 가리키는 주솟값
(4바이트) a.Age: 5 (값)

// b 객체 8바이트 할당
(4바이트) b.Name: "AAA" 문자열 객체를 가리키는 주솟값
(4바이트) b.Age: 5 (값)

이후 a.Name = "BBB" 코드가 실행되면 CLR은 "BBB" 문자열 객체를 CLR Heap에 할당한 후 a.Name 변수가 그것을 가리키도록 바꿉니다. 그래서 다음과 같은 상태가 됩니다.

// a 객체 8바이트 할당
(4바이트) a.Name: "BBB" 문자열 객체를 가리키는 주솟값
(4바이트) a.Age: 5 (값)

// b 객체 8바이트 할당
(4바이트) b.Name: "AAA" 문자열 객체를 가리키는 주솟값
(4바이트) b.Age: 5 (값)

정리해 보면, 위와 같은 상황에서는 shallow copy를 했지만 어느 한 쪽의 객체 값을 바꿔도 다른 쪽에 영향을 주지 않습니다. 그런데 이 효과가 마치 deep copy를 했을 때와 유사하므로 자칫 혼동해 버리면 나중에 문제가 발생할 수 있습니다.

위의 예제에서 shallow copy와 deep copy에 대한 차이를 부각시키려면 다음과 같이 참조 객체를 구성해 보면 됩니다.

[Serializable]
public class MyText
{
    public string Address;
}

[Serializable]
public class MyItem
{
    public MyText Text;
    public string Name;
    public int Age;

    public MyItem()
    {
    }

    public object Clone()
    {
        return this.MemberwiseClone();
    }

    public override string ToString()
    {
        return string.Format("Name: {0}, Age: {1}, Address: {2}", Name, Age, Text.Address);
    }
}

이렇게 한 후 다음과 같이 shallow copy를 하고 값을 변경해 보면,

MyItem a = new MyItem { Name = "AAA", Age = 5, Text = new MyText { Address = "KOR" } };
MyItem b = a.Clone() as MyItem;

a.Text.Address = "US";
Console.WriteLine(a.ToString()); // Name: AAA, Age: 5, Address: US
Console.WriteLine(b.ToString()); // Name: AAA, Age: 5, Address: US

a 객체의 Text 변화가 b 객체의 Text 변화에도 영향을 미쳤음을 볼 수 있습니다. 비교를 위해 이것을 deep copy한 것으로 바꿔보면,

MyItem a = new MyItem { Name = "AAA", Age = 5, Text = new MyText { Address = "KOR" } };
MyItem b = CloneData<MyItem>(a);

a.Text.Address = "US";
Console.WriteLine(a.ToString()); // Name: AAA, Age: 5, Address: US
Console.WriteLine(b.ToString()); // Name: AAA, Age: 5, Address: KOR

a와 b 내의 모든 필드들이 값/참조에 상관없이 개별 복사가 되어 있기 때문에 a 객체의 변화가 b 객체의 변화에 전혀 영향을 미치지 않습니다.

이러한 특징이 있기 때문에 shallow copy는 객체 간 복사가 가볍다는 장점이 있는 반면 어느 한 쪽의 변화가 다른 쪽에 영향을 미칠 수 있다는 단점이 있고, deep copy는 서로 영향을 주지 않는 장점이 있는 반면 객체 간 복사가 무거워진다는 단점이 있습니다.




마지막으로, ICloneable 인터페이스에 대한 언급을 해야겠습니다.

ICloneable
; https://learn.microsoft.com/en-us/dotnet/api/system.icloneable

마이크로소프트는 ICloneable 인터페이스에 대해 반드시 shallow copy를 한 객체를 반환해야 한다거나, deep copy를 한 객체를 반환해야 한다는 어떠한 명시도 하고 있지 않습니다. 심지어, 다음과 같이 모든 필드의 값을 복사한다고도 보장할 수 없습니다.

It does not specify whether the cloning operation performs a deep copy, a shallow copy, or something in between. Nor does it require all property values of the original instance to be copied to the new instance.


즉, 이것은 해당 객체를 정의하는 개발자의 판단에 의존합니다. 이로 인해 문서에는 다음과 같은 언급도 있습니다.

Because callers of Clone cannot depend on the method performing a predictable cloning operation, we recommend that ICloneable not be implemented in public APIs.


따라서, ICloneable은 그 객체를 구현한 개발자가 사용할 코드 범위 내에서 편의 상 정의하는 것이 권장될 뿐입니다. 굳이 ICloneable을 공용으로 노출하고 싶다면 문서를 꼼꼼하게 작성해야 하고, 향후 내부 변경을 해야 할 때 기존 구현 코드가 shallow였는지 deep이었는지 잘 살펴보고 구현을 맞춰주어야 할 필요가 있습니다. 또한 사용하는 입장에서도 ICloneable 인터페이스를 구현한 클래스의 객체를 복사할 때는 반드시 관련 문서를 읽어봐야 합니다.

(첨부 파일은 이 글의 예제다이어그램 원본 파일을 포함합니다.)




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







[최초 등록일: ]
[최종 수정일: 11/1/2023]

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

비밀번호

댓글 작성자
 



2020-07-27 10시29분
정성태

... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...
NoWriterDateCnt.TitleFile(s)
12551정성태3/5/20217314오류 유형: 702. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly. (2)
12550정성태3/5/20217021오류 유형: 701. Live Share 1.0.3713.0 버전을 1.0.3884.0으로 업데이트 이후 ContactServiceModelPackage 오류 발생하는 문제
12549정성태3/4/20217479오류 유형: 700. VsixPublisher를 이용한 등록 시 다양한 오류 유형 해결책
12548정성태3/4/20218262개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20218778오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218404개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111119.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111305.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/20219705VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112034개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219287개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219606.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219488Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/20219885.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202110873.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/20219911개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219037개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219646개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219293개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/20219807개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20218786개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202112930개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110050개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219432개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219665개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217518개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...