答え。

Goにおいて、string と []byte の変換は通常、新しいメモリ（アロケーション）が割り当てられます。これは、文字列が不変（immutable）であり、バイトスライスが可変（mutable）であるためです。コンパイラの内部最適化（エスケープ分析）による例外もありますが、これは保証されておらず、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))
}

特別な場合を除き、これらの手法を使用しない方が良いでしょう — これはデータの安全性を損なうことになります（共通のスライスを介して文字列の内容を変更でき、エラーを引き起こす可能性があります）。

ひっかけ問題。

「文字列を[]byteに変換する場合、文字列が小さいまたは定数であればアロケーションは発生しませんか？」とよく尋ねられます。

正しい答え: いいえ。文字列のサイズに関係なく、コンパイラは常に新しいバイトスライスを作成し、その内容をコピーします。例外はunsafe最適化のみで、安全性を保証せず、Goの公式ドキュメントによってサポートされていません。

このテーマの細かい知識の欠如から生じた実際のエラーの例。

ストーリー

チームは、高負荷なログ解析サービスを記述しており、処理のために受信した文字列を常にバイトスライスに変換していました。ピーク時には、ガベージコレクターが短命なコピーの集計に最大30%のCPU時間を費やしていました。プロファイリングの結果、各string↔[]byteの変換がそれぞれ個別のメモリ領域をアロケートしていることが判明しました。プールとAPIの再設計を導入することで、大部分の変換を削減し、GCの負荷を半分に減らしました。

ストーリー

開発者の一人が、アロケーションを回避するためにbytes→stringのunsafe変換を使用してJSON処理を最適化しました。最初はパフォーマンスの向上が見られましたが、1ヶ月後にクラッシュが発生しました：あるバイトバッファが再利用され、文字列が古い変更されたデータを指していました。標準のコピーに戻し、プロセス間APIを再設計することで修正できました。

ストーリー

大きなバイナリデータをネットワークで送信する際にシリアライゼーションを「最適化」し、BytesToString（コピーなし）を使用しました。ある時、送信した文字列が公開され、バイトスライスの内容が即座に上書きされ、ガーベジとともにプライベートなデータ部分がエラーログに漏えいしました。結果としてメモリの重複排除がプライベートデータの漏えいを招くことになりました！