메모리 누수는 얼마나 멀리 갈 수 있습니까?

메모리 누수가 여러 번 발생했습니다. 보통 내가 malloc내일이없는 것처럼, 또는 FILE *더러운 빨래처럼 매달릴 때 . 나는 일반적으로 적어도 프로그램이 종료 될 때 모든 메모리가 정리된다고 가정합니다 (필사적으로 희망합니다). 프로그램이 종료되거나 충돌 할 때 누수 된 메모리가 수집되지 않는 상황이 있습니까?

대답이 언어마다 크게 다르면 C (++)에 중점을 둡니다.

'내일이없는 것처럼', '매달려 ... 더러운 세탁물처럼'이라는 문구의 쌍곡선 사용에 유의하십시오. 안전하지 않은 * malloc* ing은 사랑하는 사람을 해칠 수 있습니다. 또한 세탁물이 더러워지면 조심해서 사용하십시오.

아니요. 운영 체제는 프로세스가 종료 될 때 보유한 모든 리소스를 해제합니다.

이것은 운영 체제가 유지하는 모든 리소스에 적용됩니다 : 메모리, 열린 파일, 네트워크 연결, 창 핸들 ...

즉, 프로그램이 운영 체제가없는 임베디드 시스템에서 실행되거나 매우 단순하거나 버그가있는 운영 체제가있는 경우 재부팅 할 때까지 메모리를 사용하지 못할 수 있습니다. 그러나 그 상황에 있었다면 아마도이 질문을하지 않을 것입니다.

운영 체제에서 특정 리소스를 해제하는 데 시간이 오래 걸릴 수 있습니다. 예를 들어, 네트워크 서버가 연결을 수락하는 데 사용하는 TCP 포트는 프로그램에 의해 제대로 닫혀 있어도 몇 분이 걸릴 수 있습니다. 네트워크 프로그램은 데이터베이스 개체와 같은 원격 리소스를 보유 할 수도 있습니다. 원격 시스템은 네트워크 연결이 끊어지면 해당 리소스를 해제해야하지만 로컬 운영 체제보다 더 오래 걸릴 수 있습니다.

C 표준은 malloc프로그램이 종료 될 때 할당 된 메모리 가 해제 되도록 지정하지 않습니다 . 이것은 운영 체제에 의해 수행되며 모든 OS (일반적으로 이들은 임베디드 세계에 있음)가 프로그램이 종료 될 때 메모리를 해제하지 않습니다.

모든 답변이 최신 OS에 대한 질문의 대부분의 측면을 다루었으므로 역사적으로 DOS 세계에서 프로그래밍 한 적이 있다면 언급 할 가치가있는 것이 있습니다. Terminant and Stay Resident (TSR) 프로그램은 일반적으로 시스템에 제어권을 반환하지만 소프트웨어 / 하드웨어 인터럽트에 의해 회복 될 수있는 메모리에 상주합니다. 이러한 OS에서 작업 할 때 "메모리 부족! 일부 TSR을 언로드 해보십시오" 와 같은 메시지가 나타나는 것은 정상이었습니다 .

따라서 기술적으로 프로그램은 종료 되지만 여전히 메모리에 있기 때문에 프로그램을 언로드하지 않으면 메모리 누수가 해제되지 않습니다.

따라서 버그가 있거나 임베디드 OS가 그렇게하도록 설계 되었기 때문에 메모리를 회수하지 않는 OS와는 다른 또 다른 경우라고 생각할 수 있습니다.

예를 하나 더 기억합니다. 주로 IBM 메인 프레임에서 실행되는 트랜잭션 서버 인 CICS ( Customer Information Control System )는 의사 대화 형입니다. 실행되면 사용자가 입력 한 데이터를 처리하고 사용자를위한 또 다른 데이터 세트를 생성하여 사용자 터미널 노드로 전송하고 종료합니다. 주의 키를 활성화하면 다시 활성화되어 다른 데이터 세트를 처리합니다. 작동 방식은 기술적으로 다시 말하지만 CICS 트랜잭션 서버를 재활용하지 않는 한 종료 된 CICS 프로그램에서 메모리를 회수하지 않습니다.

다른 사람들이 말했듯이 대부분의 운영 체제는 프로세스 종료시 할당 된 메모리를 회수합니다 (네트워크 소켓, 파일 핸들 등과 같은 기타 리소스).

그렇긴하지만 (원시 malloc / free 대신) new / delete를 처리 할 때 메모리 만 걱정할 필요가 없습니다. new에 할당 된 메모리는 회수 될 수 있지만 객체의 소멸자에서 수행 될 수있는 일은 발생하지 않습니다. 아마도 일부 클래스의 소멸자는 소멸시 센티넬 값을 파일에 씁니다. 프로세스가 막 종료되면 파일 핸들이 플러시되고 메모리가 회수 될 수 있지만 해당 센티넬 값은 기록되지 않습니다.

이야기의 도덕, 항상 자신을 정리하십시오. 물건을 매달리지 마십시오. 나중에 OS 정리에 의존하지 마십시오. 스스로 청소하십시오.

이것은 언어보다 운영 체제에 더 많이 의존합니다. 궁극적으로 모든 언어의 모든 프로그램은 운영 체제에서 메모리를 가져옵니다.

프로그램이 종료 / 충돌 할 때 메모리를 재활용하지 않는 운영 체제에 대해 들어 본 적이 없습니다. 따라서 프로그램이 할당해야하는 메모리에 상한선이있는 경우 할당하고 해제하지 않는 것이 완벽하게 합리적입니다.

프로그램이 다른 프로그램의 주소 공간에로드되는 동적 구성 요소 ( "플러그인")로 바뀌면 메모리 관리가 깔끔한 운영 체제에서도 문제가됩니다. 성능이 떨어지는 시스템으로 이식되는 코드에 대해 생각할 필요조차 없습니다.

반면에 모든 메모리를 해제 하면 프로그램 정리 성능에 영향을 미칠 수 있습니다 .

내가 작업하고 있던 한 프로그램은 프로그램이 종료되는 데 30 초 이상이 소요되는 특정 테스트 케이스입니다. 모든 동적 메모리의 그래프를 반복하여 하나씩 해제했기 때문입니다.

합리적인 해결책은 해당 기능을 가지고 테스트 케이스로 덮지 만 프로덕션 코드에서는 꺼서 애플리케이션이 빠르게 종료되는 것입니다.

제목에 해당하는 모든 운영 체제는 종료 후 프로세스가 엉망이 된 것을 정리합니다. 그러나 항상 예상치 못한 이벤트가 있습니다. 어떻게 든 액세스가 거부되고 일부 가난한 프로그래머가 가능성을 예견하지 못하여 나중에 다시 시도하지 않으면 어떻게됩니까? 메모리 누수가 미션 크리티컬 한 경우에는 항상 자신을 정리하는 것이 더 안전합니다. 그렇지 않으면 그 노력이 비용이 많이 든다면 IMO에 실제로 노력할 가치가 없습니다.

편집 : 루프와 같이 누적 될 위치에있는 경우 메모리 누수를 정리해야합니다. 내가 말한 메모리 누수는 프로그램 과정 내내 일정한 시간에 쌓이는 것입니다. 만약 당신이 다른 종류의 누수가 있다면 조만간 심각한 문제가 될 가능성이 높습니다.

기술적 인 측면에서 메모리 '복잡성'O (1)의 경우 대부분의 경우 괜찮습니다. O (logn)는 이미 불쾌하고 (경우에 따라 치명적) O (N) +는 견딜 수 없습니다.

POSIX 호환 시스템의 공유 메모리는 shm_unlink가 호출되거나 시스템이 재부팅 될 때까지 지속됩니다.

프로세스 간 통신이있는 경우 프로토콜에 따라 다른 프로세스가 완료되지 않고 리소스를 소비하지 않게 될 수 있습니다.

예를 들어, 저는 한때 프린터 작업 중에 JVM을 종료 할 때 Java에서 PDF 프린터로 인쇄하는 실험을하고 있었는데, PDF 스풀링 프로세스가 활성 상태로 남아 있었으며 작업 관리자에서이를 종료해야했습니다. 다시 인쇄 해보십시오.