답변.

Go에서 string과 []byte 간의 변환은 일반적으로 새 메모리를 할당하며(할당), 문자열은 변경 불가능하고(immutable), 바이트 슬라이스는 변경 가능하기 때문입니다(mutable). 예외로는 일부 내부 컴파일러 최적화(escape analysis)가 있지만, 이는 보장되지 않으며 Go의 버전에 따라 다를 수 있습니다.

직접 변환:

[]byte(s string): 항상 새 바이트 배열을 할당하고 데이터를 복사합니다.
string(b []byte): 또한 항상 바이트 배열의 데이터를 새 문자열로 복사합니다.

제로 할당은 불필요한 할당을 피하는 방법입니다. Go의 표준 라이브러리에는 unsafe 패키지를 통한 안전하지 않은 변환이 있어, 복사 없이 동일한 데이터에 참조할 수 있습니다. 이는 리스크를 완전히 이해한 경우에만 사용할 수 있습니다.

import (
    "reflect"
    "unsafe"
)

func BytesToString(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))
}

func StringToBytes(s string) []byte {
    sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
    bh := reflect.SliceHeader{
        Data: sh.Data,
        Len:  sh.Len,
        Cap:  sh.Len,
    }
    return *(*[]byte)(unsafe.Pointer(&bh))
}

특별한 경우를 제외하고는 이러한 기법을 사용하지 않는 것이 좋습니다 — 이는 데이터 안전성에 악영향을 미치기 때문입니다(공유 슬라이스를 통해 문자열 내용을 변경할 수 있어 오류를 초래할 수 있습니다).

호의적인 질문.

“문자열을 small하거나 constant 할 경우 string에서 []byte로의 변환 시 할당이 발생하지 않는다는 것이 사실인가요?”라는 질문을 자주 받습니다.

올바른 답변: 아닙니다. 문자열의 크기와 관계없이 컴파일러는 항상 새 바이트 슬라이스를 생성하고 내용을 복사합니다. 예외는 안전성을 보장하지 않으며 Go의 공식 문서에 의해 지원되지 않는 unsafe 최적화뿐입니다.

이 주제의 미세한 차이에 대한 실제 오류 사례.

이야기

팀은 로그 파싱을 위한 고부하 서비스를 작성했으며, 항상 수신 문자열을 바이트 슬라이스로 변환하고 다시 처리하는 작업을 했습니다. 피크 상황에서 가비지 컬렉터는 짧게 살아있는 복사본 수집에 대해 CPU 시간을 최대 30%까지 소모했습니다. 프로파일링 후 string↔[]byte 변환이 각각 별도의 메모리 영역을 할당한다는 사실이 밝혀졌습니다. 풀을 도입하고 API를 재설계한 후 상당 부분의 변환을 제거하여 GC의 부하를 절반으로 줄일 수 있었습니다.

이야기

한 개발자는 JSON 작업을 최적화하기 위해 바이트에서 문자열로의 unsafe 변환을 사용하여 할당을 피했습니다. 처음에는 성능 향상이 뚜렷했지만 한 달 후 크래시가 발생했습니다: 어떤 바이트 버퍼가 재사용되었고 문자열이 이전의 변경된 데이터에 가리키고 있었습니다. 표준 복사본으로 복귀하고 프로세스 간 API를 다시 설계하여 문제를 해결할 수 있었습니다.

이야기

네트워크를 통해 대량의 이진 데이터를 전송할 때 복사를 피하기 위해 BytesToString을 사용하여 직렬화를 "최적화"하였습니다. 보낸 문자열이 공개적으로 노출되고 바이트 슬라이스의 내용이 즉시 덮어쓰여져 쓰레기를 전송하고 개인 데이터의 일부가 오류 패킷 로그에 유출되었습니다. 메모리 중복 제거가 개인 데이터 유출로 이어졌습니다!

제로 할당은 Go에서 문자열과 바이트 슬라이스를 다룰 때 어떻게 작동합니까? string ↔ []byte 변환 시 새 메모리가 выдел되는 경우와 할당을 피할 수 있는 경우는 언제입니까?

답변.

호의적인 질문.

이 주제의 미세한 차이에 대한 실제 오류 사례.