この記事の途中に、以下の記事の引用を含んでいます。
How to Avoid Thread-Safety Cost for Functions’ Static Variables
【導入】ローカルstatic変数、その便利さと隠れた落とし穴
C++でよく利用される「関数内のstatic変数」。
これは「初回呼び出し時のみ初期化され、その後も値が保持される」という特徴があり、シングルトンやキャッシュ、状態保存など様々な用途で重宝します。
しかし、C++11以降はこのローカルstatic変数の初期化がスレッドセーフになりました。
裏を返せば、そのための「コスト」が常に発生している、ということでもあります。
今回紹介する記事は「そのコストとは何か？」また「不要な場合、このコストを回避するための現実的なテクニック」について、非常に具体的かつ実践的な観点から掘り下げています。
ただ便利に使うだけでなく、パフォーマンスクリティカルなコードを書く人が知っておくべき知見が詰まっています。
【主張紹介】スレッドセーフ初期化のコストは本当に問題か？
この記事の主張の骨子は２つです。
- 「C++11以降の関数スコープstatic変数は、スレッドセーフな初期化が保証されている」
- 「実際のコストは驚くほど小さいが、“確実にゼロ”ではない。特にホットパス（非常に頻繁に呼ばれる部分）では注意が必要」
例えば、対象記事では次のように言及されています。
“Function-local statics in C++11+ are initialized exactly once, thread-safely.
After initialization, calls incur only a very small, predictable guard check (~1–3 ns in tight loops).
In most real-world code, the difference is negligible; choose the style that best fits your design.”(How to Avoid Thread-Safety Cost for Functions’ Static Variables)
「1〜3ナノ秒」という数字、たしかに無視できると感じる方が多数派でしょう。
しかし「無視できる理由」と「本当にゼロコスト設計が求められる領域」両方が現実には存在します。
記事はこの両者に対応した設計・最適化手法についてもメスを入れています。
【徹底解説】staticローカル変数の内部挙動とパフォーマンス事情
なぜstaticローカル変数にはスレッドセーフな初期化が必要なのか？
C++11より前、関数内static変数の初期化は明示的な排他制御なしにはマルチスレッド環境で危険でした。
複数のスレッドが同時にその関数に入り、初期化直前で競合すると、正しく初期化されない・複数回初期化される・未定義動作……などの問題が発生しうるからです。
C++11からは、言語レベルで「関数スコープのstaticローカル変数を、最初の一度だけ安全に初期化する」ことが保障されました。
これは裏で「ガード変数」（例えば__cxa_guard_acquireという関数）を使ったロック処理が挟まることで実現されています。
コストの正体──具体的な数値で知る
記事は実際に、下記のようなベンチマーク（筆者はStack Overflowの有名スレッドを引用しています）で、
「関数内static」と「グローバルstatic（namespaceスコープ）」の性能差を測定しています。
“Results (first benchmark, indirect function calls):
Clang : local = 4618 ms, global = 4392 ms → local slower by ~0.45 ns per call.
GCC : local = 4181 ms, global = 4418 ms → local faster by ~0.47 ns per call.”(How to Avoid Thread-Safety Cost for Functions’ Static Variables)
この例では1コールあたりサブナノ秒レベルという恐るべき小ささです（しかも一部GCCでは逆転現象まで）。
つまり、普通の利用ではほぼ“気にしなくても良い”のです。
とはいえ、
“If absolute lowest per-call overhead is needed in a very hot path, a namespace-scope constexpr / constinit global removes even that guard.”
(How to Avoid Thread-Safety Cost for Functions’ Static Variables)
ともあるように、「どうしてもゼロコストを追求したい場合には『ガード変数』すら使わない設計も可能」という話です。
【実践解説】どう“ガードコスト”を回避すべきか？ 具体的な改善手法
１．constな初期化データは動的初期化をやめよう
もしstatic変数が不変（const）であり、constexprにできる場合は、
「動的初期化」ではなく「コンパイル時初期化（constant initialization）」で済ませるべきです。
例えば、記事の「ブロックされたIDリスト」をstatic const vector
cpp
bool is_blocked_id(int id) {
static const std::vector<int> blocked_ids{101, 202, 303, 404, 505};
return std::find(blocked_ids.begin(), blocked_ids.end(), id) != blocked_ids.end();
}
しかし、そのvector自体が変化しないなら、むしろグローバルスコープで宣言すれば良いのです。
２．std::vectorは避け、std::arrayへ
さらに「動的メモリ確保すら不要」であれば、std::array<int, N>など固定長配列（しかもconstexpr対応）を使えば、初期化も全てコンパイル時に済みます。
ここではstatic constでなく、C++20以降はconstinitもしくはconstexprの利用が推奨されます。
cpp
static constinit std::array<int, 5> blocked_ids{101, 202, 303, 404, 505};
この「コンパイル時に全てが決まる」設計は、実行時オーバーヘッドをゼロにできます。
３．複雑な型もconstexpr/constinit化の努力を
整数だけでなく、自作structやstring_viewなどもconstinit/constexprを活用すれば、同じ恩恵が受けられる例が紹介されています。
この最適化は「値が事前に定義できるものに限る」ものの、現実の用途でも頻繁に現れます。
【考察＆批評】「性能最適化」vs「設計の明快さ」どちらを取るべき？
いったい何を優先すべきか？
「たかだか1〜3ナノ秒のコストを気にしすぎるのは、時として“最適化病”に陥る罠」
多くの現場では、関数内static変数の「ローカル性・カプセル化」の恩恵の方が圧倒的に大きいケースがほとんどです。
事実、上記記事も「設計上そのスタイルが最適なら、微差は気にするな」という姿勢です（現実的！）。
ただ、例えばリアルタイム系・パケットフィルタ・物理演算cycle・AIエンジンのようなミリ秒単位どころか、ナノ秒単位でレイテンシを削る必要がある領域もあります。
また、関数スコープstaticによる初回呼び出し時の「意図せぬ遅延」や、「予測不能なメモリ確保」がバグやパフォーマンス低下につながる事態もあります（大規模サービスや基盤系では一度はトラブルシュート経験のある話でしょう）。
そこではローカルstaticの「グローバルな存在と局所性の両立」という便利さを潔くあきらめ、明示的グローバル定数で設計する潔さも必要です。
他の視点から
他方、あまり知られていないが、gccなどの「-fno-threadsafe-statics」やMSVCの「/Zc:threadSafeInit」などで明示的にスレッドセーフ初期化を無効化できるケースや、static変数の初期化で予期しない副作用（例えば破棄順序の問題）が起こるケースでは、慎重な設計が求められます。
【まとめ】「測る」こと、そして「設計意図に忠実である」ことの重要性
結局のところ、C++のstaticローカル変数のスレッドセーフ化によるコストは「ほとんど気にしなくて良い」レベルです。
しかし、“本当に気にしなくて良いかどうか”は、実際に測定（ベンチマーク）して確かめることが唯一の正解です。
また設計段階で「何をもって『設計上の正しさ』・『将来の安全性・拡張性』とみなすか」は、エンジニアやチームやプロジェクトごとに異なる場合があることも、忘れてはいけません。
static変数を関数内に閉じ込め。
本質的に不変のデータをconstexpr/constinitでグローバル化。
複雑な型もコンパイル時イニシャライズ……。
「局所性」「安全性」「グローバル性」「性能」それぞれの要件を明確にして、ベストバランスを探る。
これが本記事で学べる最大の教訓です。
パフォーマンスを本当に詰めたければ――“測定”と“シンプルな設計”にこそ、技術の極意は宿る
categories:[technology]
コメント