GO의 가비지 수집기
go 언어 가비지 수집은 일반적으로 고전적인 표시 및 스윕을 사용합니다. 연산. #推荐#(추천 학습:GO)#🎜🎜 ## 🎜🎜#1.3 버전 이전에는 Golang의 가비지 재활용 알고리즘이 매우 간단했지만 성능도 비판을 받았습니다. Go Runtime이 Under에 속했습니다. 특정 조건(메모리가 임계값을 초과하거나 주기적으로(예: 2분)) 모든 작업의 실행이 일시 중지되고 mark&sweep 작업이 수행되며 작업이 완료된 후 모든 작업의 실행이 시작됩니다.
많은 메모리가 사용되는 시나리오에서 go 프로그램은 가비지 수집을 수행할 때 매우 명백한 멈춤 현상(Stop The World)을 나타냅니다. 높은 응답 속도를 요구하는 백그라운드 서비스 프로세스에서 이러한 지연은 도저히 용납할 수 없습니다! 이 기간 동안 프로덕션 환경에서 Go 언어를 연습하던 국내외 많은 팀은 어느 정도 GC의 함정을 밟았습니다. 당시 이 문제를 해결하는 일반적인 방법은 자동으로 할당되는 메모리 양을 최대한 빨리 조절하여 gc 부하를 줄이는 동시에 수동적인 메모리 관리 방법을 사용하여 처리하는 것이었습니다. 많은 양의 메모리와 높은 빈도 할당이 필요한 시나리오. Go 팀은 버전 1.3부터 지속적으로 GC 성능을 개선하고 최적화하기 시작했습니다. Go의 새로운 버전이 출시될 때마다 GC 개선은 모두의 관심의 초점이 되었습니다. 버전 1.3에서는 go 런타임이 마크와 스윕 작업을 분리합니다. 이전과 마찬가지로 모든 작업 실행이 먼저 일시 중지되고 마크가 완료되면 일시 중지된 작업이 즉시 다시 시작됩니다. 작업은 일반 코루틴 작업과 같은 다른 작업과 병렬로 실행됩니다. 멀티 코어 프로세서에서 실행 중인 경우 go는 비즈니스 코드 실행에 영향을 주지 않고 별도의 코어에서 gc 작업을 실행하려고 시도합니다. Go 팀 자체 설명에 따르면 일시정지 시간이 50%-70% 감소했다고 합니다. 버전 1.4(최신 안정 버전)에서는 GC에 대한 성능 변경 사항이 많지 않습니다. 버전 1.4에서는 많은 런타임 코드가 기본 C 언어 구현을 Go 언어 구현으로 대체했습니다. gc에 가져온 주요 변경 사항은 정확한 gc를 달성할 수 있다는 것입니다. C 언어 구현은 gc 중에 메모리의 개체 정보를 얻을 수 없으므로 일반 변수와 포인터를 정확하게 구분할 수 없습니다. 우연히 다른 개체가 있는 경우에만 포인터로 처리할 수 있습니다. 이 일반 변수가 가리키는 공간에서는 이 개체가 재활용되지 않습니다. Go 언어 구현은 객체의 유형 정보를 완전히 알고 있으며 표시 시 포인터가 가리키는 객체만 순회하므로 C 구현에서 힙 메모리 낭비를 방지합니다(약 10- 30%) . 버전 1.5에서 go 팀은 GC를 크게 개선했습니다. 공식적인 주요 목표는 지연을 줄이는 것입니다.go 1.5에 구현된 가비지 수집기는 "비세대, 이동하지 않는 동시 3색 표시 및 청소 가비지 수집기"입니다.
세대 알고리즘은 위에서 언급되었으며 더 나은 가비지 수집 관리 전략이지만 버전 1.5에서는 해당 단계를 수행할 수 없기 때문에 구현되지 않았습니다. Go 관계자도 이를 버전 1.6의 GC 최적화에서 고려할 것이라고 밝혔습니다.
동시에 위에서 소개한 3색 마킹 방식이 도입되었습니다. 이 방식의 마킹 작업은 매번 전체 메모리 공간을 스캔하지 않고 점진적으로 실행될 수 있어 중지 시간을 줄일 수 있습니다. 세계. Go의 가비지 수집 성능은 1.5 버전까지 계속해서 향상되고 있는 것을 볼 수 있지만, 상대적으로 성숙한 가비지 수집 시스템(Java JVM, Javascript v8 등)의 경우 Go의 최적화가 필요합니다. . 갈 길은 아직 멀다(하지만 미래는 밝을 거라 믿는다~).위 내용은 golang에는 GC가 있나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!