수동 메모리 관리

Manual memory management

컴퓨터 과학에서 수동 메모리 관리는 프로그래머가 사용하지 않는 물체, 즉 쓰레기를 식별하고 할당 해제하기 위해 수동 명령을 사용하는 것을 말한다.1990년대 중반까지만 해도 업계에서 사용되는 프로그래밍 언어의 대부분은 수동 메모리 관리를 지원했지만, 쓰레기 수집은 1959년 Lisp과 함께 도입된 이후부터 존재해왔다.그러나 오늘날 자바와 같은 가비지 컬렉션을 가진 언어가 점점 인기를 끌고 있으며, Object-C와 Swift 언어는 Automatic Reference Counting을 통해 유사한 기능을 제공한다.오늘날에도 널리 사용되고 있는 수동 관리 언어의 주요 용어는 C와 C++이다. 자세한 내용은 C 동적 메모리 할당을 참조하십시오.

설명

많은 프로그래밍 언어는 자유 저장소에서 새 개체를 할당할 시기를 결정하기 위해 수동 기법을 사용한다.C는 다음을 사용한다.malloc함수; C++ 및 Java에서 사용new운영자, 그리고 많은 다른 언어들(예: Python)은 프리 스토어에서 모든 객체를 할당한다.물체가 언제 생성되어야 하는지를 결정하는 것(물체 생성)은 비록 물체가 즉시 사용되기 전에 생성될 수 있다는 것을 의미하지만, 일반적으로 사소하고 논란의 여지가 없다.진짜 도전은 물체 파괴 – 물체가 더 이상 필요하지 않은 시점(즉, 쓰레기)의 결정과 그 기초가 되는 저장소가 재사용을 위해 무료 상점에 반환될 수 있도록 하는 것이다.수동 메모리 할당에서, 이것은 또한 프로그래머에 의해 수동으로 지정된다; 다음과 같은 기능을 통해서.free()C, 또는 에서deleteC++ – 이는 C와 C++의 범위 끝에서 파괴되는 기능, 특히 (정전기적이지 않은) 국소 변수에 있는 물체의 자동 파괴와 대비된다.

수동 메모리 관리 기술

예를 들어,


수동 관리 및 정확성

주요 기사:메모리 안전

수동 메모리 관리는 메모리 안전 또는 메모리 누수의 위반을 비롯하여 잘못 사용되었을 때 프로그램에 여러 가지 주요 등급의 버그가 포함될 수 있도록 하는 것으로 알려져 있다.이것들은 보안 버그들의 중요한 원천이다.

  • 사용하지 않는 물체가 다시 프리 스토어에 방출되지 않을 때, 이것을 메모리 누수라고 한다.어떤 경우에는 메모리 누수가 허용 가능할 수 있다. 예를 들어, 수명 기간 동안 한정된 양의 메모리를 "누출"하는 프로그램이나, 종료될 때 리소스를 할당하기 위해 운영 체제에 의존하는 단기 실행 프로그램이다.그러나 장기간 실행되는 프로그램에서 메모리 누수가 발생하는 경우가 많으며, 이 경우 무한히 많은 양의 메모리가 누출된다.이렇게 되면 시간이 지날수록 사용 가능한 프리 스토어의 크기는 계속 줄어들고, 결국 소진되면 프로그램이 다운된다.
  • 동적 메모리 관리 시스템의 치명적인 오류는 개체의 백업 메모리가 두 번 이상 삭제될 때 발생할 수 있으며, 개체는 두 번 이상 명시적으로 파괴될 수 있으며, 포인터를 사용하여 프리 스토어에 할당되지 않은 개체를 조작할 때 프로그래머가 해당 포인터 대상 개체의 ba를 해제하려고 할 때 발생할 수 있다.크킹 메모리, 또는 알 수 없는 외부 작업, 스레드 또는 프로세스에 의해 관리되는 임의의 메모리 영역을 포인터를 통해 개체를 조작하는 동안 프로그래머가 개체의 상태를 손상시키는 경우, 그 범위를 벗어나 쓰기 위한 방식으로 해당 개체의 메모리 관리 데이터를 손상시킬 수 있다.이러한 조치의 결과에는 힙 손상, 중복 삭제된 개체와 동일한 메모리 위치를 차지하게 되는 다른(및 새로 생성된) 개체의 조기 파괴, 분할 결함으로 인한 프로그램 충돌(메모리 보호 위반) 및 정의되지 않은 기타 형태의 동작이 포함될 수 있다.
  • 삭제 후 사용할 경우 삭제된 개체의 포인터는 야생 포인터가 된다. 이러한 포인터를 사용하려고 하면 버그를 진단하기 어려울 수 있다.

쓰레기 수거를 독점적으로 사용하는 언어는 마지막 두 종류의 결함을 피하는 것으로 알려져 있다.메모리 누수는 여전히 발생할 수 있지만(그리고 경계 누수는 세대 또는 보수적인 쓰레기 수거와 함께 자주 발생한다), 일반적으로 수동 시스템의 메모리 누수보다 덜 심각하다.

리소스 획득 초기화 중

주요 기사:리소스 획득 초기화 중

수동 메모리 관리는 RAI(Resource Acquisition Is Initialization) 패러다임을 통한 자동 리소스 관리가 가능하다는 한 가지 정확성 장점이 있다.

이는 객체가 파괴될 때 포기해야 하는 부족한 시스템 리소스(그래픽 리소스, 파일 핸들 또는 데이터베이스 연결 등)를 객체가 소유할 때 발생하며, 이때 자원 소유의 수명은 객체의 수명과 연결되어야 한다.수동관리가 가능한 언어는 객체 초기화(시뮬레이터에서) 중 자원을 획득하고, 정확한 시간에 발생하는 객체 파괴(디스트레이터에서) 중 해제함으로써 이를 정리할 수 있다.이를 리소스 획득 초기화라고 한다.

이는 결정론적 기준 카운트에도 사용할 수 있다.C++에서는 이 기능을 다른 수동 프레임워크 내에서 메모리 할당을 자동화하는 데 추가적으로 사용할 수 있다.shared_ptr언어의 표준 라이브러리에서 메모리 관리를 수행하는 템플릿은 일반적인 패러다임이다. shared_ptr그러나 모든 객체 사용 패턴에는 적합하지 않다.

이 접근법은 최종화가 결정적이지 않고 때로는 전혀 발생하지 않기 때문에 대부분의 쓰레기 수집 언어(특히 쓰레기 수집기 또는 더 고급 참조 카운트 추적)에서는 사용할 수 없다.즉, 언제 또는 언제 최종 결정자 방법이 호출될 수 있는지 정의(또는 판단)하기 어렵다. 이는 일반적으로 결승 결정자 문제로 알려져 있다.Java와 다른 GC'd 언어는 종종 폐기 패턴을 통해 메모리 외에 부족한 시스템 자원에 대해 수동 관리를 사용한다: 자원을 관리하는 모든 개체는 다음을 구현할 것으로 예상된다.dispose()이러한 리소스를 해제하고 개체를 비활성 상태로 표시하는 방법.프로그래머들이 호출할 것으로 예상됨dispose()부족한 그래픽 자원의 "확장"을 방지하기 위해 적절한 수작업.에 따라finalize()그래픽 자원을 방출하는 방법(Java가 파이널라이저를 구현하는 방법)은 Java 프로그래머들 사이에서 프로그래밍 연습이 서툴며, 유사하게 유사한 것으로 널리 인식되고 있다.__del__()파이썬의 방법은 자원 방출에 의존할 수 없다.스택 리소스(단일 코드 블록 내에서 획득 및 릴리스된 리소스)의 경우 Python의 경우와 같은 다양한 언어 구성으로 자동화할 수 있다.with, C#의using또는 자바의try-with-with-contraction.

퍼포먼스

수동 메모리 관리를 옹호하는 많은 사람들은 수동 메모리 관리가 쓰레기 수거와 같은 자동 기술에 비해 우수한 성능을 제공한다고 주장한다.전통적으로 지연이 가장 큰 장점이었지만 이제는 그렇지 않다.수동 할당은 참조의 지역성이 우수할 때가 많다.[citation needed]

메모리 소모가 부족한 시스템에도 수동 할당이 더 적합한 것으로 알려져 있는데, 이는 재생이 더 빨라지기 때문이다.메모리 시스템은 프로그램의 작업 세트 크기가 사용 가능한 메모리의 크기에 근접함에 따라 "쓰레기"를 할 수 있으며, 가비지 수집 시스템에서 사용되지 않는 개체는 즉시 회수되지 않기 때문에 효과적인 작업 세트 크기를 증가시키기 때문에 수동으로 관리되는 시스템보다 오랫동안 할당되지 않은 상태로 유지된다.

수동 관리에는 다음과 같은 여러 가지 성능 단점이 문서화되어 있음:

  • 호출 위치delete그리고 그러한 간접비용은 만들어질 때마다 발생하며, 이러한 간접비용은 쓰레기 수거 주기에 상각될 수 있다.특히 삭제 호출을 동기화해야 하는 멀티스레드 응용프로그램의 경우 더욱 그러하다.
  • 할당 절차는 더 복잡하고 느릴 수 있다.힙 압축을 사용하는 것과 같은 일부 가비지 수집 체계는 (수동 관리 체계에 의해 요구되는 복잡한 구현과는 반대로) 단순한 메모리 배열로 자유 저장소를 유지할 수 있다.

대기 시간은 시간이 지남에 따라 변화한 논쟁점으로, 초기 쓰레기 수집기와 간단한 구현은 수동 메모리 관리에 비해 매우 저조한 성능을 보였지만, 정교한 현대의 쓰레기 수집기는 수동 메모리 관리보다 더 나은 성능을 발휘하는 경우가 많다.

현대의 쓰레기 수집가들은 종종 눈에 띄지 않는 수집 주기를 가지고 있지만 수동 배분은 단순한 세계 쓰레기 수집에서 발생하는 긴 "일시 중지" 시간 때문에 고통받지 않는다.[citation needed]

수동 메모리 관리 및 가비지 수집은 모두 잠재적으로 무한 할당 해제 시간으로 인해 어려움을 겪는다. 즉, 단일 객체의 할당을 해제해야 할 수 있고, 가비지 수집 주기가 길 수 있기 때문에 수동 메모리 관리.이는 일반적으로 무한 수집 주기가 허용되지 않는 실시간 시스템에서 특히 문제가 된다. 가비지 수집기를 일시 중지하여 실시간 가비지 수집이 가능한 반면, 실시간 수동 메모리 관리에서는 대규모 할당을 피하거나 할당 해제를 수동으로 일시 중지해야 한다.

참조

  • Berger, E. D.; Zorn, B. G.; McKinley, K. S. (November 2002). "Reconsidering Custom Memory Allocation". Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. OOPSLA '02. pp. 1–12. CiteSeerX 10.1.1.119.5298. doi:10.1145/582419.582421. ISBN 1-58113-471-1.

외부 링크