범위 기반 메모리 관리의 단점

C ++ 커뮤니티에서 더 일반적으로 (혼란스럽게?) 참조하는 범위 기반 메모리 관리 (SBMM) 또는 RAII를 정말 좋아 합니다. 내가 아는 한, C ++ (및 C)을 제외하고는 오늘날 SBMM / RAII를 주요 메모리 관리 메커니즘으로 만드는 다른 주류 언어는 없으며 대신 가비지 수집 (GC)을 선호합니다.

다소 혼란 스럽습니다.

1. SBMM은 프로그램을보다 결정 론적으로 만듭니다 (객체가 언제 파괴되는지 정확히 알 수 있습니다).
2. GC를 사용하는 언어에서는 종종 수동 리소스 관리 (예 : Java에서 파일 닫기 참조)를 수행해야합니다. 이는 GC의 목적을 부분적으로 상실하고 오류가 발생하기 쉽습니다.
3. 힙 메모리는 (매우 우아하게도 imo) 범위에 바운드 될 수 있습니다 ( std::shared_ptrC ++ 참조 ).

SBMM이 더 널리 사용되지 않는 이유는 무엇입니까? 단점은 무엇입니까?

메모리가 다른 모든 리소스보다 훨씬 더 일반적이라고 가정합니다 (수십, 수백 또는 수천 시간). 모든 단일 변수, 객체, 객체 멤버에는 할당 된 메모리가 필요하며 나중에 해제됩니다. 열려있는 모든 파일에 대해 파일에서 가져온 데이터를 저장하기 위해 수십에서 수백만 개의 개체를 만듭니다. 모든 TCP 스트림은 스트림에 쓰도록 작성된 무제한의 임시 바이트 문자열과 함께 사용됩니다. 우리는 같은 페이지에 있습니까? 큰.

RAII가 작동하려면 (햇빛 아래에서 모든 사용 사례에 대해 기성품 스마트 포인터가 있더라도) 소유권 을 가져야합니다 . 이 객체 또는 그 객체를 소유 한 사람, 소유하지 않아야하는 대상 및 A에서 B로 소유권을 이전해야하는시기를 분석해야합니다. 물론 모든 것에 대해 공유 소유권을 사용할 수 있지만 스마트 포인터를 통해 GC를 에뮬레이션합니다. 그 시점에서 훨씬 쉬워집니다 및 언어로 GC를 구축하는 것이 더 빠릅니다.

가비지 콜렉션은 가장 일반적으로 사용되는 리소스, 메모리에 대한 이러한 문제를 해결합니다. 물론, 다른 자원에 대해서도 동일한 결정을 내려야하지만, 자원은 훨씬 덜 일반적이며 (위 참조), 복잡한 (예 : 공유) 소유권도 덜 일반적입니다. 정신적 부담이 크게 줄어 듭니다.

이제 모든 값을 가비지 수집 하도록 단점을 지정 합니다. 그러나 메모리 안전 GC 및 값 유형을 RAII와 함께 하나의 언어로 통합하는 것은 매우 어렵 기 때문에 다른 수단을 통해 이러한 절충을 완화하는 것이 더 낫습니까?

결정 론적 손실은 실제로 결정 론적 객체 수명 에만 영향을 미치기 때문에 그다지 나쁘지 않은 것으로 판명되었습니다 . 다음 단락에서 설명하는 것처럼, 대부분의 리소스 (메모리는 많고 다소 느리게 재활용 할 수있는 메모리 제외)는 이러한 언어의 개체 수명에 바인딩 되지 않습니다 . 몇 가지 다른 유스 케이스가 있지만 내 경험으로는 드 rare니다.

두 번째 요점 인 수동 자원 관리는 현재 범위 기반 정리를 수행하지만 오브젝트 정리 시간에이를 정리하지 않는 (GC 및 메모리 안전과 상호 작용하지 않는) 명령문을 통해 해결됩니다. 이것은 최신 Java 버전의 usingC #, withPython의 try-with-resources에 있습니다.

RAII는 또한 예를 들어 Perl에 의해 사용되는 자동 참조 카운팅 메모리 관리에 따른다. 참조 카운팅은 구현하기 쉽고 결정 론적이며 성능이 뛰어나지 만 순환 참조를 처리 할 수 ​​없으며 (누수가 발생하여) 일반적으로 사용되지 않습니다.

가비지 수집 언어 는 RAII를 직접 사용할 수 없지만 종종 동등한 효과를 가진 구문을 제공합니다. Java에는 try-with-resource 문이 있습니다

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

.close()블록 종료시 리소스 를 자동으로 호출 합니다. C #에는 명령문을 떠날 때 호출 할 IDisposable수 있는 인터페이스 .Dispose()가 있습니다 using (...) { ... }. 파이썬에는 다음과 같은 with진술이 있습니다.

with open(filename) as f:
    ...

비슷한 방식으로 작동합니다. 이것에 대한 흥미로운 스핀에서 Ruby의 파일 열기 메소드는 콜백을 얻습니다. 콜백이 실행 된 후 파일이 닫힙니다.

File.open(name, mode) do |f|
    ...
end

Node.js는 동일한 전략을 사용한다고 생각합니다.

내 의견으로는 가비지 수집의 가장 설득력있는 장점은 컴포지션이 가능 하다는 것 입니다. 메모리 관리의 정확성은 가비지 수집 환경의 로컬 속성입니다. 각 부분을 개별적으로보고 메모리 누수 여부를 결정할 수 있습니다. 메모리를 수정 한 부품을 원하는만큼 조합하면 제대로 유지됩니다.

참조 횟수를 사용하면 해당 속성이 손실됩니다. 응용 프로그램에서 메모리 누수 여부는 참조 횟수를 사용하여 전체 응용 프로그램의 전역 속성이됩니다. 부품 간의 모든 새로운 상호 작용은 잘못된 소유권을 사용하고 메모리 관리를 중단 할 가능성이 있습니다.

다른 언어로 된 프로그램 디자인에 매우 눈에 띄는 효과가 있습니다. GC 언어의 프로그램은 상호 작용이 많은 객체의 수프보다 더 많은 경향이 있지만 GC가없는 언어에서는 엄격하게 제어되고 상호 작용이 제한된 구조적 부분을 선호하는 경향이 있습니다.

폐쇄는 거의 모든 현대 언어의 필수 기능입니다. GC로 구현하기가 쉽고 RAII를 사용하기가 매우 어렵습니다 (불가능하지는 않지만). 주요 특징 중 하나는 변수의 수명 동안 추상화 할 수 있기 때문입니다!

C ++은 다른 사람들이 40 년 만에 얻을 수 있었으며 많은 똑똑한 사람들이 제대로하기 위해 많은 노력을 기울였습니다. 대조적으로, 프로그래밍 언어의 설계 및 구현에 대한 지식이없는 사람들에 의해 설계되고 구현 된 많은 스크립팅 언어에는 그것들이 있습니다.

1. SBMM은 프로그램을보다 결정 론적으로 만듭니다 (객체가 언제 파괴되는지 정확히 알 수 있습니다).

대부분의 프로그래머에게 OS는 비결정론 적이며, 메모리 할당자는 비결정론 적이며, 그들이 작성한 대부분의 프로그램은 동시 적이므로 본질적으로 비결정론 적입니다. 소멸자가 스코프의 끝에서 약간 앞뒤로가 아니라 정확하게 호출되어야한다는 제약을 추가하는 것은 대다수의 프로그래머에게 실질적인 이점이 아닙니다.

2. GC를 사용하는 언어에서는 종종 수동 리소스 관리 (예 : Java에서 파일 닫기 참조)를 수행해야합니다. 이는 GC의 목적을 부분적으로 상실하고 오류가 발생하기 쉽습니다.

usingC # 및 useF #을 참조하십시오 .

3. 힙 메모리는 (매우 우아하게도 imo) 범위에 바운드 될 수 있습니다 (C ++의 std :: shared_ptr 참조).

다시 말해, 범용 솔루션 인 힙을 가져 와서 심각하게 제한하는 특정 경우에만 작동하도록 변경할 수 있습니다. 물론 그것은 사실이지만 쓸모가 없습니다.

SBMM이 더 널리 사용되지 않는 이유는 무엇입니까? 단점은 무엇입니까?

SBMM은 수행 할 수있는 작업을 제한합니다.

1. SBMM은 일류 어휘 클로저로 상향 기능 문제 를 일으 킵니다. 이것이 클로저가 C #과 같은 언어에서는 사용하기 쉽고 C ++에서는 드물고 까다로운 이유입니다. 프로그래밍에서 기능적 구문을 사용하는 일반적인 경향이 있습니다.

2. SBMM은 소멸자를 필요로하며 함수가 리턴되기 전에 더 많은 작업을 추가하여 테일 호출을 방해합니다. 테일 호출은 확장 가능한 상태 시스템에 유용하며 .NET과 같은 것들에 의해 제공됩니다.

3. 일부 데이터 구조 및 알고리즘은 SBMM을 사용하여 구현하기가 매우 어렵다. 기본적으로 사이클이 자연스럽게 발생하는 모든 곳. 가장 주목할만한 그래프 알고리즘. 효과적으로 자신의 GC를 작성하게됩니다.

4. 제어 흐름과 따라서 객체 수명이 본질적으로 결정적이지 않기 때문에 동시 프로그래밍이 더 어렵습니다. 메시지 전달 시스템의 실용적인 솔루션은 메시지를 깊게 복사하고 지나치게 긴 수명을 사용하는 경향이 있습니다.

5. SBMM은 소스 코드에서 범위가 끝날 때까지 객체를 유지하여 종종 필요 이상으로 길고 필요 이상으로 더 길어질 수 있습니다. 이로 인해 부유 쓰레기의 양이 증가합니다 (연결할 수없는 물체는 재활용 대기 중). 반대로 가비지 콜렉션 추적은 오브젝트에 대한 마지막 참조가 사라진 직후 오브젝트를 해제하는 경향이 있으며, 이는 훨씬 빠릅니다. 메모리 관리 신화 : 신속성을 참조하십시오 .

SBMM은 너무 제한적이므로 프로그래머는 수명을 중첩 할 수없는 상황에서 탈출 경로가 필요합니다. C ++에서는 shared_ptr이스케이프 경로를 제공하지만 가비지 수집 추적보다 ~ 10 배 느릴 수 있습니다 . 따라서 GC 대신 SBMM을 사용하면 대부분의 사람들이 발을 잘못 밟을 수 있습니다. 그러나 그것이 쓸모 없다는 것은 아닙니다. SBMM은 리소스가 제한적인 시스템 및 임베디드 프로그래밍의 맥락에서 여전히 가치가 있습니다.

FWIW에서는 Forth와 Ada를 확인하고 Nicolas Wirth의 작업을 읽어보십시오.

TIOBE와 같은 인기 지수 (물론 논쟁의 여지가 있지만 사용하기에 귀하의 질문에 대해 추측 할 것입니다)를 보면 상위 20 개 중 ~ 50 %가 "스크립트 언어"또는 "SQL 언어" "사용 편의성"과 추상화 수단이 결정 론적 행동보다 훨씬 더 중요합니다. 남은 "컴파일 된"언어 중에서 SBMM을 사용하는 언어의 약 50 %가 있고 그렇지 않은 경우 ~ 50 %가 있습니다. 따라서 스크립팅 언어를 계산에서 제외하면 가정이 잘못되었다고 생각합니다. 컴파일 된 언어 중에서 SBMM이있는 언어는 그렇지 않은 언어만큼 인기가 있습니다.

아직 언급하지 않은 GC 시스템의 주요 장점 중 하나는 GC 시스템 의 참조가 존재하는 한 ID를 유지한다는 것 입니다. 참조 사본이 존재하는 동안 오브젝트에서 IDisposable.Dispose(.NET) 또는 AutoCloseable.Close(Java)를 호출하면 해당 사본은 계속 동일한 오브젝트를 참조합니다. 객체는 더 이상 아무 것도 유용하지 않지만, 객체를 사용하려고하면 객체 자체에 의해 예측 가능한 동작이 제어됩니다. 대조적으로, C ++에서 코드가 delete객체를 호출 하고 나중에이를 사용하려고하면 시스템의 전체 상태가 완전히 정의되지 않습니다.

주목해야 할 또 다른 중요한 사항은 범위 기반 메모리 관리가 명확하게 정의 된 소유권을 가진 객체에 매우 효과적이라는 것입니다. 소유권이 정의되지 않은 객체에서는 훨씬 잘 작동하지 않으며 때로는 완전히 나쁘게 작동합니다. 일반적으로 가변 객체에는 소유자가 있어야하지만 불변 객체에는 필요하지 않지만 주름이 있습니다. 코드가 가변 유형의 인스턴스를 사용하여 불변 데이터를 보유하는 경우가 일반적입니다. 인스턴스를 변경시킬 수있는 코드. 이러한 시나리오에서 가변 클래스의 인스턴스는 여러 개의 불변 개체간에 공유 될 수 있으므로 명확한 소유권이 없습니다.

우선, RAII를 SBMM과 동일시하는 것을 인식하는 것이 매우 중요합니다. 또는 심지어 SBRM. RAII의 가장 필수적인 (그리고 가장 잘 알려지지 않은 또는 가장 잘 알려지지 않은) 자질 중 하나는 '자원이되는 것'을 구성에 전이되지 않는 속성으로 만든다는 사실입니다.

다음 블로그 게시물에서는 RAII의이 중요한 측면에 대해 설명하고 비 결정적 GC를 사용하는 GCed 언어의 리소스 변경과 대조합니다.

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

RAII는 대부분 C ++에서 사용되지만 Python (VM 기반이 아닌 버전)에는 Python이 RAII를 GC와 함께 사용할 수있는 소멸자 및 결정적 GC가 있습니다. 그렇다면 두 세계의 최고.