Java 9 より前は、実行スタックへのプログラム的なアクセスを取得するには、全体のスタックトレースを配列に早期にキャプチャする Throwable をインスタンス化するか、SecurityManager.getClassContext() メソッドを使用する必要がありました（これはセキュリティポリシーによって制限されており、同様にコストが高かった）。これらのアプローチは、開発者が最上位のフレームや特定の呼び出し元のみが必要な場合でもスタックウォーキングの全コストを支払うことを強制し、パフォーマンスクリティカルなコードパスにおける呼び出し元に敏感な API の実行可能性を大きく制限しました。
早期キャプチャの根本的な問題は、スタックの深さに対する O(n) の複雑さと、StackTraceElement 配列の必須の割り当てであり、これはロギングフレームワーク、シリアル化ライブラリ、コールサイトを頻繁に調査するデバッグツールにおいて大きな GC プレッシャーを生じます。また、Throwable.fillInStackTrace はアプリケーションコードが無視したい隠れたフレーム（ネイティブメソッド、リフレクションのインフラストラクチャ）をキャプチャするため、すでにマテリアライズされたデータに対する追加のフィルタリングオーバーヘッドが必要になります。この早期実現は、アプリケーションによって決して調査されないフレームを JVM が最適化することを妨げます。
StackWalker（Java 9 で導入）は、Stream<StackFrame> 抽象化を公開し、JVM はストリームパイプラインの端末操作が要求したときのみフレームを怠惰にマテリアライズし、Object の割り当ての前に VM レベルで動作する述語ベースのフィルタリングを組み合わせています。この実装は内部のフレームウォーキングプリミティブを活用してスタックをフレームごとに走査し、ユーザー提供の Predicate<StackFrame> が false を返した時点で直ちに停止し、スキップされたフレームのための割り当てを回避し、調査されたフレームの数 k に対して O(k) の複雑さを提供します。Throwable が作成時の不変スナップショットを作成するのに対し、StackWalker はストリームの走査時点でスレッドのスタックの正確な状態を反映したライブビューを提供します。
高スループット RPC フレームワークを開発しており、すべての着信リクエストは、引数のデシリアライズ前に呼び出しクラスが承認されたモジュールから発信されているかを検証する必要があります。最初の実装では new Throwable().getStackTrace() を使用して即時呼び出し元を特定しましたが、10,000 の同時リクエストを伴う負荷テスト中に、サービスは深刻なレイテンシースパイクと頻繁な OutOfMemoryError を示しました。これは、トレース配列の大量割り当てによるものでした。プロファイリングの結果、割り当てられたバイトの約 40% がこれらのセキュリティチェックから発生していることが分かり、このアプローチは本番環境への展開には持続不可能であることがわかりました。
チームはまず、文字列パースのオーバーヘッドなしでクラスコンテキスト配列を直接返す SecurityManager.getClassContext() を活用することを検討しました。これによりスタックトレース文字列を埋め込むコストを回避できますが、やはり SecurityManager を高度な権限でインストールする必要があり、厳格なセキュリティポリシーのある環境での展開が複雑になります。また、このアプローチは必要に関係なく全体のクラス配列をキャプチャするため、O(n) の複雑さの問題を解決できません。さらに、このアプローチは現代の Java バージョンで廃止予定であり、コードベースにとって長期的な投資には適しません。
別の代替案は、アプリケーション起動時にクラスパススキャンを通じて populating された静的な Map<Class<?>, Boolean> を維持することでした。これにより、ランタイムでのインストラクションを完全に回避できます。この戦略は、リクエストごとの割り当てを排除し O(1) のルックアップ性能を提供しますが、ブートストラップ時に未知の正当な呼び出し元クラスを生成する Proxy や MethodHandle による動的コード生成を考慮していないため、間違ったセキュリティ拒否を引き起こし、複雑なキャッシュの無効化ロジックを必要とします。さらに、すべての可能性のある呼び出し元クラスをキャッシュするメモリフットプリントは、大きなアプリケーションで数千のクラスが読み込まれる場合には困難になります。
エンジニアたちは最終的に StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).walk(stream -> stream.skip(2).findFirst().map(StackFrame::getDeclaringClass).orElse(null)) を選択し、最初の 2 つのフレームのみを怠惰に評価し、中間配列を割り当てることなくクラスリファレンスを返しました。このアプローチは、動的に生成されたクラスを以前に登録することなく適切に処理し、標準 APIs のみで完全に機能し、セキュリティマネージャーの依存関係をなくすことで今後の Java の進化に対する互換性を確保しているため、最適なパフォーマンスと最小限のコード複雑性のバランスがとれています。
デプロイ後、呼び出し元検証のリクエストごとのオーバーヘッドは、約 450 バイトの割り当てと 2 マイクロ秒から、ほぼゼロ割り当てと 20 ナノ秒に減少し、セキュリティホットパスからの GC プレッシャーを効果的に排除しました。負荷テストは、サービスが遅延スパイク無しで 10,000 の同時リクエスト負荷を維持できることを確認し、ヒープダンプは StackTraceElement 配列の蓄積がないことを確認しました。このソリューションは、適切なフィルタリング述語によって構成された場合、リフレクティブおよび MethodHandle ベースの呼び出しを含む様々なコールスタックを越えてロバストであることが証明されました。
なぜ StackWalker は walk メソッド内で一度だけ横断できる Stream を返し、複数の呼び出し間でこのストリームをキャッシュして再利用しようとするとどのような競合ハザードが生じるのか？
StackWalker.walk が返す Stream は、現在のスレッドのスタックのライブでミュータブルなビューに基づいており、walk コールバックの実行中のみ有効です。コールバックが戻ると、JVM はネイティブフレームバッファを解放し、キャッシュされたストリーム参照が無効になり、後続のアクセスで IllegalStateException をスローします。候補者はしばしば StackWalker が Throwable のようにスナップショットを作成すると誤解しますが、実際にはスレッドの現在の実行状態への一時的なビューを提供しているため、ストリームが別のスレッドに渡されたりフィールドに格納された場合、並行してスタックが変更されると不整合なフレーム状態が露出したり、厳しいスコープの強制がなければ VM がクラッシュする可能性があります。
RETAIN_CLASS_REFERENCE オプションが内部フレーム表現をどのように変更し、その欠如がフレーム検査中に Class.forName を使用することを強制し、潜在的なリンクエラーを引き起こす理由は何ですか？
RETAIN_CLASS_REFERENCE がない場合、StackWalker はクラス名、メソッド名、行番号だけを StackFrame に保存することで最適化しており、Class オブジェクトを解決する必要がありません。このため、StackFrame.getDeclaringClass() はサポートされず、呼び出し元は Class.forName(frame.getClassName()) を使用する必要がありますが、もし呼び出したフレームのクラスローダーが呼び出し元のローダーではない場合、ClassNotFoundException または NoClassDefFoundError がスローされる可能性があります。RETAIN_CLASS_REFERENCE が指定されている場合、VM はウォーク中に Class オブジェクトを固定し、それらが到達可能のままとなり、ルックアップコストが排除されますが、これはウォーカー自身がロードできないクラスを参照するリフレクティブフレームをスキップできなくなります。
StackWalker.walk と Thread.getStackTrace の間には、ネイティブメソッドやリフレクションスタブの含まれ方に関する微妙な振る舞いの違いがあり、SHOW_HIDDEN_FRAMES オプションが MethodHandle 呼び出しにどのように相互作用するか？
Thread.getStackTrace と Throwable.getStackTrace は、デフォルトで隠れた実装フレーム（MethodHandle アダプタ、リフレクションブリッジ、ネイティブメソッドスタブなど）をフィルタリングして、クリーンなアプリケーションビューを提示します。デフォルトオプションの StackWalker もまた、これらのフレームを隠しますが、完全な物理スタックを提示するために SHOW_HIDDEN_FRAMES を提供します。これは、MethodHandle や VarHandle の間接呼び出しが関与するコールチェーンで権限を検証するためにスタックをウォークをする際に重要です。候補者はしばしば SHOW_HIDDEN_FRAMES を省略することで、コールチェーンが間接的である場合に実際のセキュリティに敏感な呼び出し元をスキップする可能性があることを認識せず、逆に、これを含めると合成フレームを明示的にフィルタリングする必要があり、呼び出し元を誤認識しないように注意しなければなりません。