메모리 누수가 괜찮습니까? [닫은]

C 또는 C ++ 응용 프로그램에서 메모리 누수가 발생 하는 것이 허용 됩니까?

메모리의 일부를 할당하고 응용 프로그램의 마지막 코드 줄 (예 : 전역 객체의 소멸자)까지 사용하면 어떻게 되나요? 메모리 소비가 시간이 지남에 따라 증가하지 않는 한, 응용 프로그램이 종료 될 때 (Windows, Mac 및 Linux에서) 메모리를 확보하기 위해 OS를 신뢰해도 괜찮습니까? 메모리가 OS에 의해 해제 될 때까지 메모리를 계속 사용했다면 이것을 실제 메모리 누수로 간주하겠습니까?

만약 제 3 자 도서관이 당신에게 이런 상황을 강요한다면? 아무리 크든 상관없이 해당 타사 라이브러리를 사용하지 않겠습니까?

하나의 실질적인 단점 만 보았습니다. 즉, 이러한 양성 누출은 메모리 누출 탐지 도구와 함께 오탐 (false positive)으로 표시됩니다.

아니.

전문가로서 우리 자신에게 묻지 말아야 할 질문은 "이 작업을해도 괜찮습니까?"입니다. 그러나 오히려 "이것이 좋은 이유가 있습니까?" "메모리 누수를 찾아내는 것은 고통스러운 일"이라고해서 좋은 이유는 아닙니다.

나는 일을 단순하게 유지하고 싶다. 그리고 간단한 규칙은 내 프로그램에 메모리 누수가 없어야한다는 것입니다.

그것은 내 인생도 단순하게 만듭니다. 메모리 누수를 감지하면 "허용 가능한"메모리 누수인지 확인하기 위해 정교한 의사 결정 트리 구조를 실행하는 대신이를 제거합니다.

컴파일러 경고와 비슷합니다. 경고가 특정 응용 프로그램에 치명적입니까? 아마.

그러나 그것은 궁극적으로 전문적인 훈련의 문제입니다. 컴파일러 경고를 허용하고 메모리 누수를 허용하는 것은 나쁜 습관입니다.

극단적 인 일을하기 위해 외과 의사가 환자에게 수술 장비를 남겨 두는 것이 허용 될 수 있습니까?

해당 장비를 제거하는 비용 / 위험이 장비를 떠나는 비용 / 위험을 초과하는 상황이 발생할 수 있지만 SurgeonOverflow.com에 게시 된이 질문을 보면 무해한 환경이있을 수 있습니다. "아니오"이외의 대답을 보았을 때, 그것은 의료계에 대한 나의 확신을 심각하게 약화시킬 것입니다.

–

제 3 자 도서관이 저 에게이 상황을 강요하면 문제의 도서관의 전반적인 품질을 심각하게 의심하게됩니다. 마치 테스트를 통해 차를 몰고 컵 홀더 중 하나에서 느슨한 와셔와 너트를 발견 한 것처럼 보일 것입니다. 그 자체로는 큰 문제는 아니지만 품질에 대한 헌신이 부족한 것으로 보아 대안을 고려할 것입니다.

"사용중인"메모리 양이 계속 증가하지 않는 한 메모리 누수로 간주하지 않습니다. 필요한 메모리 양이 계속 증가하지 않는 한, 릴리스되지 않은 메모리가 이상적이지는 않지만 큰 문제는 아닙니다.

먼저 우리의 정의를 올바르게 해봅시다. 메모리 누수 는 메모리가 예를 들어 with로 동적으로 할당 malloc()되고 해당 여유 공간없이 메모리에 대한 모든 참조가 손실되는 경우입니다. 하나를 만드는 쉬운 방법은 다음과 같습니다.

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

while (1) 루프를 돌 때마다 1024 (+ overhead) 바이트가 할당되고 새 주소가 vp에 할당됩니다. 이전 malloc'ed 블록에 대한 나머지 포인터가 없습니다. 이 프로그램은 힙이 다 떨어질 때까지 실행되며 malloc의 메모리를 복구 할 방법이 없습니다. 메모리가 힙에서 "누설"되어 다시는 볼 수 없습니다.

하지만 당신이 묘사하는 것은

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

프로그램을 종료 할 때까지 메모리를 할당하고 작업하십시오. 이것은 메모리 누수 가 아닙니다 . 프로그램을 손상시키지 않으며 프로그램이 종료 될 때 모든 메모리가 자동으로 청소됩니다.

일반적으로 메모리 누수를 피해야합니다. 첫째, 당신보다 높은 곳에서 격납고에 연료를 공급하기 때문에 누출되어 복구 할 수없는 메모리는 쓸모가 없습니다. 둘째, 메모리 누수를 시작하지 않고 나중에 메모리 누수를 찾는 것보다 올바르게 코딩하는 것이 훨씬 쉽습니다.

이론적으로 아니, 실제로 그것은 달려있다 .

그것은 실제로 프로그램이 작업하는 데이터의 양, 프로그램이 얼마나 자주 실행되는지 그리고 지속적으로 실행되는지에 달려 있습니다.

적은 양의 데이터를 읽는 빠른 프로그램이 계산을 끝내고 종료되면 작은 메모리 누수가 발견되지 않습니다. 프로그램이 오래 실행되지 않고 적은 양의 메모리 만 사용하기 때문에 프로그램이 존재할 때 누수가 작고 해제됩니다.

반면에 수백만 개의 레코드를 처리하고 오랫동안 실행되는 프로그램이 있으면 작은 메모리 누출로 인해 충분한 시간이 주어지면 시스템이 다운 될 수 있습니다.

누출이있는 타사 라이브러리의 경우 문제가 발생하면 라이브러리를 수정하거나 더 나은 대안을 찾으십시오. 문제가되지 않으면 실제로 문제가됩니까?

많은 사람들이 일단 메모리를 확보하면 즉시 운영 체제로 돌아와 다른 프로그램에서 사용할 수 있다는 인상을 받고있는 것 같습니다.

사실이 아닙니다. 운영 체제는 일반적으로 4KiB 페이지에서 메모리를 관리합니다. malloc다른 종류의 메모리 관리는 OS에서 페이지를 가져오고 적절하다고 생각되면 하위 관리합니다. 그것은 아주 가능성이 있음을의 free()것 없는 프로그램이 나중에 더 많은 메모리를 malloc을 것이라는 가정하에, 운영 체제에 페이지를 반환합니다.

나는 free()결코 운영 체제에 메모리를 반환 하지 않는다고 말하지 않습니다 . 특히 많은 양의 메모리를 비우는 경우에 발생할 수 있습니다. 그러나 보장 할 수 없습니다.

중요한 사실 : 더 이상 필요하지 않은 메모리를 확보하지 않으면 추가 malloc이 더 많은 메모리 를 소비 하게 됩니다. 그러나 먼저 해제하면 malloc이 해제 된 메모리를 대신 재사용 할 수 있습니다.

이것이 실제로 무엇을 의미합니까? 즉, 프로그램에 더 이상 메모리가 필요하지 않다는 것을 알고 있다면 (예 : 정리 단계에 있음) 메모리를 해제하는 것은 그리 중요하지 않습니다. 그러나 프로그램이 나중에 더 많은 메모리를 할당 할 수 있으면 메모리 누수, 특히 반복적으로 발생할 수있는 메모리 누수를 피해야합니다.

또한 종료 직전에 메모리를 해제하는 것이 나쁜 이유에 대한 자세한 내용 은 이 주석 을 참조하십시오.

주석가는 호출 free()이 다른 프로그램이 해제 된 메모리를 자동으로 사용하도록 허용하지 않는다는 것을 이해하지 못하는 것 같습니다 . 그러나 이것이이 답변의 요점입니다!

따라서 사람들을 설득하기 위해 free ()가 거의 수행하지 않는 예를 보여 드리겠습니다. 수학을 쉽게 따르기 위해 OS가 4000 바이트 페이지에서 메모리를 관리하는 것처럼 가장합니다.

10,000 개의 100 바이트 블록을 할당한다고 가정합니다 (간단하게하기 위해 이러한 할당을 관리하는 데 필요한 추가 메모리는 무시합니다). 1MB 또는 250 페이지를 소비합니다. 그런 다음이 블록 중 9000 개를 임의로 해제하면 1000 개의 블록 만 남게됩니다. 통계적으로 약 5 페이지의 페이지가 비어 있습니다. 다른 245는 각각 적어도 하나의 할당 된 블록을 가질 것이다. 100KB 만 할당하더라도 운영 체제에서 회수 할 수없는 메모리는 980KB입니다.

한편, 프로그램이 묶는 메모리의 양을 늘리지 않고도 malloc () 9000 블록을 더 만들 수 있습니다.

기술적 으로 메모리를 OS에 반환 할 free()수있는 경우에도 그렇지 않을 수 있습니다. 빠른 운영과 메모리 절약 사이의 균형을 유지해야합니다. 또한 이미 많은 메모리를 할당 한 다음 해제 한 프로그램은 다시 그렇게 할 가능성이 있습니다. 웹 서버는 요청 후 요청 후 요청을 처리해야합니다. 일부 "느슨한"메모리를 사용 가능한 상태로 유지하면 OS에 항상 메모리를 요청할 필요가 없습니다.free()

응용 프로그램을 실행 한 후 OS를 정리하는 데 개념적으로 잘못된 것은 없습니다.

실제로 응용 프로그램과 실행 방법에 따라 다릅니다. 몇 주 동안 실행해야하는 응용 프로그램에서 지속적으로 발생하는 누수를 처리해야하지만 너무 많은 메모리 필요없이 결과를 계산하는 작은 도구는 문제가되지 않습니다.

많은 스크립팅 언어가 주기적 참조를 가비지 수집하지 않는 이유가 있습니다. 사용 패턴의 경우 실제 문제가 아니므로 낭비되는 메모리만큼 많은 자원을 낭비하게됩니다.

나는 대답이 아니오라고 생각하고, 메모리 누수를 허용하지 않으며, 명시 적으로 언급하지 않은 몇 가지 이유가 있습니다. 여기에는 훌륭한 기술 답변이 있지만 실제 답변은 더 사회적 / 인간적인 이유에 달려 있다고 생각합니다.

(먼저 언급했듯이, 진정한 누출은 프로그램이 어느 시점에서 할당 한 메모리 리소스를 잃어 버릴 때입니다. C에서 이것은 malloc()포인터를 가리키고 포인터가 범위를 벗어나지 않도록합니다. free()먼저.)

여기서 결정의 중요한 요지는 습관입니다. 포인터를 사용하는 언어로 코드를 작성하면 포인터 를 많이 사용하게 됩니다. 그리고 포인터는 위험합니다. 코드에 심각한 방식의 모든 문제를 추가하는 가장 쉬운 방법입니다.

코딩 할 때 때로는 공을 들고 때로는 피곤하거나 화를 내거나 걱정할 수도 있습니다. 다소 혼란스러운 시간에는 자동 조종 장치에서 더 많은 코딩 작업을 수행합니다. 자동 조종 장치 효과는 대규모 프로젝트에서 일회용 코드와 모듈을 구분하지 않습니다. 그 시간 동안, 당신이 설정하는 습관은 코드베이스에서 끝나는 것입니다.

따라서 현재 도로상에서 유일한 차 일지라도 차선을 변경할 때 사각 지대를 확인해야하는 것과 같은 이유로 메모리 누수를 허용하지 마십시오. 당신의 활동적인 두뇌가 산만해질 때, 좋은 습관이 당신을 재앙적인 실수로부터 구할 수있는 전부입니다.

"습관"문제 외에도 포인터는 복잡하며 정신적으로 추적하기 위해 많은 두뇌 능력이 필요합니다. 포인터를 사용할 때, 특히 프로그래밍을 처음 접할 때 "물을 진흙탕으로 치지"않는 것이 가장 좋습니다.

더 사회적 측면도 있습니다. 의 적절한 사용으로 malloc()하고 free(), 당신의 코드를 보이는 사람이 편안하게 될 것입니다; 당신은 당신의 자원을 관리하고 있습니다. 그러나 그렇지 않으면 즉시 문제가 의심됩니다.

어쩌면 메모리 누수로 인해이 컨텍스트에서 아무런 문제가되지는 않았지만 코드의 모든 관리자는 코드를 읽을 때도 머리에서 문제를 해결해야합니다. 를 사용 free()하면 문제를 고려해야 할 필요성도 제거됩니다.

마지막으로, 프로그래밍은 프로세스의 정신 모델을 모호하지 않은 언어로 작성하여 사람과 컴퓨터가 해당 프로세스를 완벽하게 이해할 수 있도록합니다. 좋은 프로그래밍 실습의 중요한 부분은 불필요한 모호함을 유발하지 않습니다.

스마트 프로그래밍은 유연하고 일반적입니다. 나쁜 프로그래밍은 모호합니다.

나는 당신의 상황에서 대답은 괜찮다고 생각할 것입니다. 그러나 메모리 누수가 의식적인 결정임을 분명히 문서화해야합니다. 유지 보수 프로그래머가 와서 코드를 함수 안에 넣고 백만 번 호출하는 것을 원하지 않습니다. 따라서 누출이 괜찮다고 결정하면 향후 프로그램에서 작업해야 할 사람을 위해 누출을 문서화해야합니다.

이것이 타사 라이브러리 인 경우 갇힐 수 있습니다. 그러나이 누출이 발생했음을 분명히 문서화하십시오.

그러나 기본적으로 메모리 누수가 512KB 버퍼 또는 알려진 것과 같은 알려진 양이면 문제가되지 않습니다. 라이브러리 호출을 호출 할 때마다 메모리 누수가 계속 증가하면 메모리가 512KB 증가하고 해제되지 않으면 문제가있을 수 있습니다. 문서를 작성하고 통화 실행 횟수를 제어하면 관리가 용이 ​​할 수 있습니다. 그러나 512가 많지는 않지만 512 만 건이 넘는 512가 많기 때문에 문서가 실제로 필요합니다.

또한 운영 체제 설명서를 확인해야합니다. 이것이 임베디드 장치 인 경우 종료되는 프로그램에서 모든 메모리를 해제하지 않는 운영 체제가있을 수 있습니다. 잘 모르겠습니다. 어쩌면 이것이 사실이 아닐 수도 있습니다. 그러나 살펴볼 가치가 있습니다.

나는 메모리를 확보하는 것이 프로그램의 메모리 사용량을 줄이지 않는 한 항상 메모리를 확보 하는 것이 항상 틀렸다는 대중적이지 않지만 실용적인 대답을 줄 것 입니다. 예를 들어 전체 수명 동안 사용할 데이터 세트를로드하기 위해 단일 할당 또는 일련의 할당을 수행하는 프로그램은 아무것도 해제 할 필요가 없습니다. 매우 동적 인 메모리 요구 사항 (웹 브라우저 생각)이있는 큰 프로그램의 경우 탭 / 문서 등을 닫는 등 더 이상 사용하지 않는 메모리를 확보해야합니다. 하지만 사용자가 '종료'클릭을 선택할 때 아무것도 해제 할 이유가 없으며 그렇게하면 실제로 사용자 경험에 해가됩니다.

왜? 메모리를 비우려면 메모리를 터치해야합니다. 시스템의 malloc 구현이 할당 된 메모리 블록에 인접한 메타 데이터를 저장하지 않더라도 해제 해야하는 모든 포인터를 찾기 위해 재귀 구조를 걷고있을 것입니다.

이제 프로그램이 많은 양의 데이터를 처리했지만 한동안 대부분의 데이터를 건드리지 않았다고 가정합니다 (다시 말해 웹 브라우저가 좋은 예입니다). 사용자가 많은 앱을 실행중인 경우 해당 데이터의 상당 부분이 디스크로 교체되었을 수 있습니다. 방금 종료 (0)하거나 main에서 돌아 오면 즉시 종료됩니다. 훌륭한 사용자 경험. 모든 것을 해제하는 데 어려움을 겪으면 5 초 이상 모든 데이터를 다시 스와핑하여 그 직후에 버릴 수 있습니다. 사용자 시간 낭비. 랩탑 배터리 수명 낭비. 하드 디스크의 마모 폐기물.

이것은 단지 이론적 인 것이 아닙니다. 너무 많은 앱이로드되어 디스크가 스 래싱을 시작할 때마다 "종료"를 클릭하는 것을 고려하지도 않습니다. 나는 가능한 한 빨리 터미널에 도착하고 killall -9를 입력한다. "exit"가 단지 더 나빠질 것이라는 것을 알고 있기 때문이다.

나는 누군가가 그렇다고 말할 이유를 생각 해낼 수 있다고 확신하지만 그것은 나에게 해당되지 않습니다. '아니요'라고 말하는 대신에 '그렇다'라는 질문이 있어서는 안된다고 말할 것입니다. 메모리 누수를 관리하거나 포함하는 방법이 있으며 많은 시스템에 메모리 누수가 있습니다.

이를 위해 지구를 떠나는 장치에는 NASA 시스템이 있습니다. 시스템은 자주 자동으로 재부팅되므로 메모리 누수가 전체 작업에 치명적이지 않습니다. 봉쇄의 예일뿐입니다.

메모리를 할당하고 프로그램의 마지막 줄까지 사용하면 누출이 아닙니다. 메모리를 할당하고 잊어 버린 경우 메모리 양이 늘어나지 않아도 문제가됩니다. 할당되었지만 사용되지 않은 메모리로 인해 다른 프로그램이 느리게 실행되거나 전혀 실행되지 않을 수 있습니다.

한 손으로 시간이 지남에 따라 본 "양성"누출의 수를 셀 수 있습니다.

따라서 대답은 매우 자격이 있습니다.

예입니다. 순환 큐 또는 큐를 저장하기 위해 버퍼가 필요하지만 버퍼가 얼마나 큰지 알지 못하고 잠금 또는 모든 독자의 오버 헤드를 감당할 수없는 단일 톤 리소스가있는 경우 지수 적으로 배가되는 버퍼를 할당하지만 이전 것들을 해제하지 않으면 대기열 / 대기열 당 제한된 양의 메모리가 누출됩니다. 이것의 장점은 모든 액세스 속도를 극적으로 향상시키고 잠금 경합을 위험에 빠뜨리지 않으면 서 다중 프로세서 솔루션의 증상을 바꿀 수 있다는 것입니다.

이 접근 방식은 CPU 당 작업 스태킹 대기열과 같이 매우 명확하게 고정 된 수를 가진 것들과 /proc/self/mapsC의 Hans Boehm의 보수 가비지 수집기에서 싱글 톤 상태 를 유지하는 데 사용되는 버퍼의 수준이 훨씬 적은 것들에 큰 이점이 있음을 보았습니다 / C ++는 루트 세트 등을 감지하는 데 사용됩니다.

기술적으로 누출이 발생하는 경우,이 두 경우 모두 크기가 제한적이며 확장 가능한 순환 작업 도용 deque 경우에는 큐 의 메모리 사용량이 2 배 증가하는 대가로 성능 이 크게 향상됩니다.

프로그램 시작 부분에 많은 힙을 할당하고 종료 할 때 여유 공간을 확보하지 않으면 메모리 누출 자체가 아닙니다. 메모리 누수는 프로그램이 코드 섹션을 반복 할 때 발생하며 해당 코드는 힙을 할당 한 다음 해제하지 않고 힙을 "추적"합니다.

실제로 종료하기 직전에 free ()를 호출하거나 삭제할 필요가 없습니다. 프로세스가 종료되면 모든 메모리가 OS에 의해 재생됩니다 (이것은 POSIX의 경우입니다. 다른 OS (특히 임베디드 OS)-YMMV).

종료시 메모리를 비우지 않는 유일한주의 사항은 프로그램을 리팩토링하면 입력을 기다리는 서비스가되고 프로그램이 무엇이든 수행 한 다음 반복하기를 반복한다는 것입니다. 다른 서비스 호출을하면 코딩 한 내용이 메모리 누수로 바뀔 수 있습니다 .

이것은 도메인에 따라 다르기 때문에 대답 할 가치가 거의 없습니다. 당신의 괴물 머리를 사용하십시오.

• 우주 왕복선 운영 체제 : 아니요, 메모리 누수가 허용되지 않습니다
• 신속한 개발 개념 증명 코드 : 모든 메모리 누수를 수정하는 것은 시간 낭비입니다.

중간 상황의 스펙트럼이 있습니다.

최악의 메모리 누수를 제외하고 제품 릴리스를 지연시키는 데 드는 기회 비용 ($$$)은 일반적으로 "느슨하거나 전문가가 아닌"느낌을 줄입니다. 상사는 따뜻하고 애매한 감정을 느끼지 않기 위해 돈을 벌 수 있도록 돈을 지불합니다.

먼저 인식 된 메모리 누수와 실제 메모리 누수간에 큰 차이가 있음을 알아야합니다. 매우 자주 분석 도구는 많은 붉은 청어를보고하고 실제로 유출되지 않은 곳 (손잡이 등의 메모리 또는 리소스)에 누출이있는 것으로 표시합니다. 종종 이것은 분석 도구의 아키텍처 때문입니다. 예를 들어, 특정 분석 도구는 런타임 개체를 메모리 누수로보고합니다. 개체가 해제 된 것을 보지 못하기 때문입니다. 그러나 분석 도구가 볼 수없는 런타임 종료 코드에서 할당 해제가 발생합니다.

그러나 실제 메모리 누수가 발견되기 어렵거나 수정하기가 어려운 경우가 여전히 있습니다. 이제 문제는 코드에 그대로 두는 것입니까?

이상적인 대답은 "아니요."입니다. 좀 더 실용적인 대답은 "아니오, 거의 없다"일 수 있습니다. 실생활에서 종종 해결해야 할 자원과 시간이 제한되어 있으며 끝없는 작업 목록이 있습니다. 작업 중 하나가 메모리 누수를 제거하는 경우 수익 감소 법칙이 종종 등장합니다. 일주일 내에 애플리케이션에서 모든 메모리 누수의 98 %를 제거 할 수 있지만 나머지 2 %는 몇 달이 걸릴 수 있습니다. 경우에 따라 주요 코드 리팩터링없이 애플리케이션 아키텍처로 인해 특정 누수를 제거하는 것이 불가능할 수도 있습니다. 나머지 2 %를 제거하는 비용과 이점을 고려해야합니다.

이런 종류의 질문 문맥에는 모든 것이 있습니다. 개인적으로 누출을 견딜 수 없으며 코드에서 자르면 문제를 해결하기 위해 많은 시간을 할애하지만 누출을 해결하는 것이 항상 가치가있는 것은 아니며 사람들이 내가 한 시간 내로 돈을 지불 할 때 그들에게 코드에서 누수를 고치는 것은 내 비용이 들지 않는다고 말했다. 예를 들어 보겠습니다.

나는 프로젝트를 심사하고 일부 성능 작업을 수행하고 많은 버그를 수정했습니다. 응용 프로그램 초기화 중에 추적하여 누출을 완전히 이해했습니다. 제대로 수정하려면 하루 정도의 기능이 필요했을 것입니다. 나는 해킹 된 것을 할 수 있었지만 (글로벌에 가치를 채우고 더 이상 무료로 사용하지 않는다는 것을 알았습니다), 코드를 만져야했던 다음 사람에게 더 혼란 스러울 것입니다.

개인적으로 나는 처음에는 그런 식으로 코드를 작성하지 않았지만 우리 대부분은 항상 잘 설계된 코드베이스에서 작업하지 않아도되며 때로는 이러한 것들을 실용적으로 봐야합니다. 150 바이트 누출이 메가 바이트의 램을 제거하는 알고리즘 개선에 소요되는 시간을 수정하는 데 걸린 시간입니다.

궁극적으로, 나는 램 공연을 중심으로 사용하고 전용 컴퓨터에서 실행되는 응용 프로그램에 대해 150 바이트 누출이 그것을 고칠 가치가 없다고 결정했기 때문에 유출되었다는 의견을 작성했습니다. 그 당시에는 왜 가치가 없었습니까?

대부분의 답변은 실제 메모리 누수 (조잡한 코딩의 표시이기 때문에 괜찮지는 않지만)에 집중하지만 질문 의이 부분은 나에게 더 흥미로워 보입니다.

메모리의 일부를 할당하여 응용 프로그램의 마지막 코드 줄 (예 : 전역 객체의 소멸자)까지 사용할 수 있습니까? 메모리 소비가 시간이 지남에 따라 증가하지 않는 한, 응용 프로그램이 종료 될 때 (Windows, Mac 및 Linux에서) 메모리를 확보하기 위해 OS를 신뢰해도 괜찮습니까? 메모리가 OS에 의해 해제 될 때까지 메모리를 계속 사용했다면 실제 메모리 누수로 간주하겠습니까?

연관된 메모리가 사용되면 프로그램이 종료되기 전에 해제 할 수 없습니다. 프로그램 종료 또는 OS에 의한 사용 가능 여부는 중요하지 않습니다. 이것이 문서화되어 있으면 변경으로 인해 실제 메모리 누수가 발생하지 않으며 그림과 관련된 C ++ 소멸자 또는 C 정리 기능이없는 한. 닫히지 않은 파일은 누출 된 FILE객체를 통해 드러날 수 있지만 누락 된 fclose ()로 인해 버퍼가 플러시되지 않을 수도 있습니다.

따라서 원래 사례로 돌아 가면 IMHO 자체로는 완벽하게 확인되므로 가장 강력한 누출 탐지기 중 하나 인 Valgrind는 요청 된 경우에만 이러한 누출을 처리 할 수 ​​있습니다. Valgrind에서는 미리 포인터를 해제하지 않고 포인터를 덮어 쓰면 다시 발생할 가능성이 높고 힙이 끝없이 커질 수 있으므로 메모리 누수로 간주됩니다.

그런 다음 여전히 도달 가능한 nfreed 메모리 블록이 없습니다. 출구에서 모든 것을 자유롭게 할 수는 있지만 그것은 시간 낭비입니다. 요점은 그들이 전에 풀 수 있었는지 입니다. 메모리 소비를 줄이는 것은 모든 경우에 유용합니다.

나는 vfilby에 동의합니다 – 그것은 다릅니다. Windows에서는 메모리 누수를 상대적으로 장황한 버그로 취급합니다. 그러나 구성 요소에 따라 크게 다릅니다.

예를 들어, 메모리 누수는 드물게 실행되는 구성 요소 및 제한된 시간 동안 심각하지 않습니다. 이러한 구성 요소가 실행되고 작동 한 다음 종료됩니다. 그들이 모든 메모리를 종료하면 내재적으로 해제됩니다.

그러나 서비스 또는 셸과 같은 기타 장기 구성 요소의 메모리 누출은 매우 심각합니다. 그 이유는 이러한 버그가 시간이 지남에 따라 메모리를 '훔치는'것입니다. 이를 복구하는 유일한 방법은 구성 요소를 다시 시작하는 것입니다. 대부분의 사람들은 서비스 나 셸을 다시 시작하는 방법을 모릅니다. 따라서 시스템 성능이 저하되면 재부팅 만하면됩니다.

따라서 누출이있는 경우 두 가지 영향을 평가하십시오.

1. 소프트웨어와 사용자 경험에.
2. 시스템 자원에 대한 절약 측면에서 시스템 (및 사용자)에게.
3. 유지 관리 및 안정성에 대한 수정의 영향
4. 다른 곳에서 회귀를 일으킬 가능성.

포 데커

'알려진'메모리 누출이 혼란을 유발하지 않는다고 확신하더라도 그렇게하지 마십시오. 기껏해야 다른 시간과 장소에서 비슷하고 더 중요한 실수를 할 수있는 길을 열어 줄 것입니다.

나에게 이것은 "아무도 없을 때 오전 3시에 붉은 빛을 깰 수 있습니까?"라는 질문과 같습니다. 물론, 그 당시에는 아무런 문제가 발생하지 않지만 출근 시간에도 같은 일을 할 수있는 레버를 제공합니다!

아니요, OS에서 청소할 수있는 누수가 없어야합니다. 그 이유는 (내가 확인할 수있는 한 위의 답변에 언급되지 않은) main ()이 다른 프로그램에서 함수 / 모듈로 재사용 될 때 를 결코 알지 못하기 때문 입니다. main ()이 다른 사람의 소프트웨어에서 자주 호출되는 함수 인 경우,이 소프트웨어는 시간이 지남에 따라 메모리를 소모하는 메모리 누수를 갖게됩니다.

KIV

메모리 누수를위한 프로그램을 작성하는 것이 좋습니다 (즉, 메모리 누수가 시스템 성능에 미치는 영향을 테스트하는 것).

메모리 누수가 실제로 무엇인지에 대한 잘못된 정의가 너무 많다는 것이 놀랍습니다. 구체적인 정의가 없다면, 나쁜 일인지 아닌지에 대한 토론은 아무데도 갈 수 없습니다.

일부 주석 작성자가 올바르게 지적했듯이 프로세스에서 할당 한 메모리가 프로세스가 더 이상 참조하거나 삭제할 수없는 범위를 벗어나면 메모리 누수가 발생합니다.

점점 더 많은 메모리를 확보하는 프로세스가 반드시 누출되는 것은 아닙니다. 해당 메모리를 참조하고 할당을 해제 할 수있는 한, 프로세스를 명시 적으로 제어하고 누출되지 않습니다. 프로세스는 메모리가 제한된 시스템의 상황에서 제대로 설계되지 않았지만 누출과 동일하지 않습니다. 반대로, 유출되는 메모리의 양이 적더라도 32 바이트 버퍼의 범위를 잃는 것은 여전히 ​​누출입니다. 이것이 중요하지 않다고 생각되면 누군가가 라이브러리 호출 주위의 알고리즘을 랩핑하고 10,000 번 호출 할 때까지 기다리십시오.

나는 당신 자신의 코드에서 누출을 허용 할 이유가 전혀 없지만 작습니다. C 및 C ++와 같은 최신 프로그래밍 언어는 프로그래머가 이러한 누수를 방지하는 데 도움을주기 위해 많은 노력을 기울이고 있으며, 특히 특정 언어 기능과 결합하여 누수를 방지하기 위해 좋은 프로그래밍 기술을 채택하지 않는 것이 좋은 주장은 아닙니다.

누출의 심각성에 따라 품질 또는 변경 능력에 대한 통제력이 크게 제한 될 수있는 기존 또는 타사 코드와 관련하여 정기적으로 프로세스를 다시 시작하여 축소하는 등의 조치를 취하거나 완화해야 할 수 있습니다. 누출의 영향.

기존 (누출) 코드를 변경하거나 교체 할 수 없으므로 코드를 수락해야합니다. 그러나 이것은 정상이라고 선언하는 것과 다릅니다.

의도적이며 큰 메모리 양이 아니면 큰 메모리 양이 될 수 없다면 문제가되지 않으면 누출이 아닙니다. 프로그램 수명 동안 전역 할당을 정리하지 않는 것이 일반적입니다. 누수가 서버 또는 오래 실행되는 앱에서 발생하면 시간이 지남에 따라 커지고 문제가됩니다.

나는 당신이 당신의 자신의 질문에 대답했다고 생각합니다. 가장 큰 단점은 메모리 누수 감지 도구를 방해하는 방법이지만, 특정 유형의 응용 프로그램에는 큰 단점이라고 생각합니다.

나는 견고한 서버 레거시 서버 응용 프로그램을 사용하지만 누출이 있고 전역이 메모리 감지 도구를 방해합니다. 큰 문제입니다.

Jared Diamond의 "Collapse"라는 책에서 저자는 이스터 섬에서 마지막 나무를 자른 사람이 섬에서 내리기 위해 카누를 짓기 위해 필요한 나무를 잘라낸 사람에 대해 궁금해합니다. 몇 년 전 첫 글로벌이 코드베이스에 추가 된 날이 궁금합니다. 그것이 잡히는 날이었다.

나는 다음과 같은 모든 시나리오 질문과 같은 문제를 봅니다. 프로그램이 변경되고 갑자기 메모리 누수가 거의 천만 번 호출되고 프로그램 끝이 다른 장소에 있기 때문에 문제가 발생합니까? 그것이 라이브러리에 있다면 라이브러리 관리자와 버그를 기록하고, 자신의 코드에 누출을 두지 마십시오.

나는 대답하지 않을 것이다.

이론적으로, 혼란을 주면 운영 체제가 정리됩니다 (지금은 무례하지만 컴퓨터에 감정이 없기 때문에 받아 들일 수 있습니다). 그러나 프로그램이 실행될 때 발생할 수있는 모든 상황을 예상 할 수는 없습니다. 따라서 (어떤 행동에 대한 공식적인 증거를 제시 할 수 없다면), 메모리 누수를 만드는 것은 전문적인 관점에서 무책임하고 조잡합니다.

타사 구성 요소가 메모리를 누수하는 경우 이는 임박한 효과 때문일뿐만 아니라 프로그래머가 느리게 작동하고 다른 메트릭에도 영향을 줄 수 있음을 보여주기 때문에 메모리 사용에 대한 매우 강력한 주장입니다. 이제 레거시 시스템을 고려할 때 이것은 어렵습니다 (웹 탐색 구성 요소를 고려하십시오 : 내 지식으로는 모두 메모리 누수가 있음).

역사적으로 일부 운영 체제에서는 일부 경우에 문제가있었습니다. 이러한 최첨단 사례는 미래에도 존재할 수 있습니다.

예를 들어, Sun 3 시대의 SunOS에서 프로세스가 exec (또는 전통적으로 포크와 exec)를 사용하면 후속 새 프로세스가 부모와 동일한 메모리 풋 프린트를 상속하고 축소 할 수없는 경우 문제가 발생했습니다 . 부모 프로세스가 1/2 gig의 메모리를 할당하고 exec를 호출하기 전에 메모리를 해제하지 않으면 자식 프로세스는 동일한 1/2 gig를 사용하기 시작합니다 (할당되지 않은 경우에도). 이 동작은 메모리 호그 인 SunTools (기본 윈도우 시스템)에서 가장 잘 나타납니다. 스폰 된 모든 응용 프로그램은 포크 / 실행을 통해 생성되었으며 SunTools 풋 프린트를 상속하여 스왑 공간을 빠르게 채 웁니다.

이것은 이미 광고 구역에 대해 논의되었습니다 . 결론은 메모리 누수가 버그이며 수정해야한다는 것입니다. 타사 라이브러리에서 메모리가 누출되면 다른 문제가 있는지 궁금해합니다. 자동차를 만드는 경우 가끔 오일이 새는 엔진을 사용 하시겠습니까? 결국, 다른 누군가가 엔진을 만들었으므로 고장이 아니기 때문에 해결할 수 없습니다.

일반적으로 독립형 응용 프로그램에서 메모리 누출은 프로그램이 종료 될 때 정리되므로 치명적이지 않습니다.

종료되지 않도록 설계된 서버 프로그램에 대해 무엇을합니까?

리소스가 올바르게 할당되고 릴리스 된 코드를 설계하고 구현하지 않는 프로그래머라면 귀하 또는 귀하의 코드와 관련이 없습니다. 누출 된 메모리를 정리하지 않으려면 잠금은 어떻습니까? 그들도 거기에 놀고 있습니까? 다양한 디렉토리에 임시 파일이 거의 남지 않습니까?

그 기억을 새고 프로그램을 정리하게 하시겠습니까? 아뇨. 나쁜 습관이어서 버그, 버그 및 더 많은 버그가 발생합니다.

자신을 정리하십시오. Yo momma는 더 이상 여기서 일하지 않습니다.

일반적으로 피할 수 없다고 생각되는 메모리 누수가 발생하면 객체 소유권에 대해 더 열심히 생각해야합니다.

그러나 귀하의 질문에, 간단히 말해서 내 대답은 프로덕션 코드입니다. 개발 중에는 없습니다 . 이것은 거꾸로 보일지 모르지만 여기에 내 추론이 있습니다.

프로그램이 끝날 때까지 메모리가 유지되는 위치에서 메모리를 해제하지 않는 것이 좋습니다. 프로세스가 종료되면 OS가 정리됩니다. 실제로, 그것은 사용자의 경험을 향상시킬 수 있습니다. 내가 작업 한 게임에서, 프로그래머들은 종료하기 전에 모든 메모리를 비워서 프로그램을 종료하는 데 최대 30 분이 걸릴 것이라고 생각했습니다! 방금 exit ()라는 빠른 변경으로 인해 프로세스가 즉시 사라지고 사용자가 원하는 데스크탑으로 돌아갑니다.

그러나 디버깅 도구에 대해서는 맞습니다. 맞춤법을 사용하면 모든 오 탐지로 실제 메모리 누수를 찾는 데 어려움을 겪을 수 있습니다. 이 때문에 항상 메모리를 비우는 디버깅 코드를 작성하고 배송 할 때 비활성화하십시오.