>백엔드 개발 >Golang >Go의 `map[string]string`에서 문자열 길이가 메모리 사용량에 영향을 미치지 않는 것처럼 보이는 이유는 무엇입니까?

Go의 `map[string]string`에서 문자열 길이가 메모리 사용량에 영향을 미치지 않는 것처럼 보이는 이유는 무엇입니까?

Susan Sarandon
Susan Sarandon원래의
2024-12-26 12:24:11536검색

Why Does String Length Seem to Have No Impact on Memory Usage in Go's `map[string]string`?

Golang의 문자열 메모리 사용량

두 가지 가능한 값("A" 또는 "B")만 있는 map[string]string을 사용하여 코드를 최적화할 때 이를 줄입니다. map[string]bool을 사용하면 성능이 확실히 향상되는 것 같습니다. 그러나 테스트 결과 놀라운 사실이 드러났습니다. 긴 문자열("a2")의 메모리 사용량은 단일 문자 문자열("a")과 다르지 않습니다.

설명

이해하려면 이 동작에서는 unsafe.Sizeof()가 참조된 데이터 구조의 크기를 고려하지 않는다는 점에 유의하는 것이 중요합니다. 대신 전달된 값의 "얕은" 크기만 보고합니다.

Go에서 맵은 데이터 구조에 대한 포인터입니다. unsafe.Sizeof(somemap)을 호출하면 맵 내의 요소가 사용하는 실제 메모리가 아닌 이 포인터의 크기가 반환됩니다.

마찬가지로 Go의 문자열은 포인터와 길이가 포함된 헤더로 표시됩니다. unsafe.Sizeof(somestring)을 호출하면 문자열 길이와 관계없이 이 헤더의 크기가 반환됩니다.

문자열의 메모리 요구 사항

문자열 값을 메모리에 저장하는 데 필요한 실제 메모리 UTF-8로 인코딩된 바이트 시퀀스의 길이에 헤더의 크기를 더한 것과 같습니다. 이를 계산하려면 다음 공식을 사용할 수 있습니다.

stringSize = len(str) + int(unsafe.Sizeof(str))

문자열 슬라이싱 및 메모리 사용량

문자열 슬라이싱은 문자열의 백업 배열을 가리키는 새 헤더를 생성한다는 점을 기억하는 것도 중요합니다. 원래 문자열. 이는 슬라이스된 문자열(s2)이 작더라도 원래 문자열(s)의 전체 백업 배열이 여전히 메모리에 유지된다는 것을 의미합니다.

위 내용은 Go의 `map[string]string`에서 문자열 길이가 메모리 사용량에 영향을 미치지 않는 것처럼 보이는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.