インタビュー: 仮想マシン スタックに関する 5 つの質問それを聞いて嬉しかったです。

[[399686]]

面接に向かう途中

「チン、チン、チン…」マスター、ここはどこですか？まだ面接に急がなければなりません。

「マスター:」 もうすぐです。次の交差点に着きます。私は本当にこの人たちを尊敬しています。彼らは運転できないのに、とにかく車に乗ろうとし続けている。

運転手の苦情を聞いていると、リメリック（韻文）を思い出さずにはいられなかった。赤いテールランプがいたるところに灯り、汽笛の音が耳に響く。長い間の遅延を心配し、頭は雷のように落ち込んでいます。

車を降りるとすぐに、素晴らしいホテルに駆け込みました。いやいや、それはビジネスビルです。ロビーはとても豪華で、ちょっと幻想的な気分になりました。

面接プロセス

「ノック、ノック、ノック」「どうぞお入りください」

「インタビュアー：」あなたはハンサムな若者ですね。若者たちはエネルギーに満ち溢れている。簡単な自己紹介をお願いします。

「阿Q：」こんにちは、インタビュアーさん。私の名前は「シャドウロード」です。私はイオニア出身です。私はリーグ・オブ・レジェンドで最強のミッドレーナーです（異論は受け付けません）。ソロキルに関しては誰も私に勝てません。私のモットーは「見えない刃こそが最も致命的である」です。もちろん、Ah Qと呼んでいただいても結構です。こちらが私の履歴書です。

「インタビュアー：」Ah Q、挨拶はやめて、本題に入りましょう。 JVM に関する知識が最も豊富に書かれているので、まずは仮想マシン スタックに関する理解についてお話しください。

「阿Q:」 心の中で思うこと: この波は自慢する価値がある。咳...咳...仮想マシン スタックは、初期の頃は Java スタックとも呼ばれていました。 JVM のランタイムデータ領域に存在するメモリ領域です。これはスレッドプライベートであり、スレッドの作成時に作成され、スレッドが終了すると終了します。

えーと。 。 。考えるふりをする？？

ご存知のとおり、スタックにはプッシュとポップという 2 つの操作しかないため、ストレージを割り当てる高速かつ効率的な方法です。この場合、ガベージ コレクションの問題はありませんが、サイズが動的または固定されているため、スタック オーバーフローまたはメモリ オーバーフローの問題が発生します...

インタビュアー: すみません、先ほどスタック オーバーフローとメモリ オーバーフローの問題が発生するとおっしゃいましたが、なぜこのような状況が発生するのか説明していただけますか?

「Ah Q:」はい、はい、仮想マシン スタックはスタック フレームで構成されており、各メソッド呼び出しはスタック フレームのプッシュに対応することはわかっています。 -Xss パラメータを使用してスタック サイズを設定できます。設定した仮想マシンのスタック サイズが非常に小さい場合、メソッドの呼び出しが多すぎると、つまりスタック フレームが多すぎると、StackOverflowError が発生し、スタック オーバーフローの問題が発生してしまいます。

スタック フレームが固定されておらず、動的に拡張するように設定されている場合、メモリが不足すると、スタックの拡張をサポートするのに十分なメモリがなくなります。このとき、OOM例外、つまりメモリオーバーフロー問題が発生します。

「インタビュアー：」ふーむ（うなずきながら）、若者は明確な考えを持っていることを示しています。スタック フレームを小さく設定しすぎると、スタック フレームのオーバーフローが発生するとおっしゃいました。もっと大きく設定すればスタックオーバーフローを完全に回避できるのではないでしょうか？

「阿Q:」これは私にとって罠のようです。私たちのような人間は、一般的に中庸の原則を主張する傾向があるため、このような絶対的な質問を聞くと、賢明に答えなければなりません。いいえ、いいえ、いいえ、スタック サイズを調整しても、スタック オーバーフローの時間を「遅らせる」か、スタック オーバーフローのリスクを軽減することしかできません。

例を挙げてみましょう。

ビジネス ロジック メソッドを 5,000 回呼び出す必要があるが、この時点でスタック オーバーフロー エラーがスローされるとします。 -Xss を設定することで、オーバーフローが 7000 回の呼び出し後にのみ発生するようにして、スタック スペースを増やすことができます。この時点で、スタック サイズを調整することは理にかなっています。これにより、ビジネスを正常にサポートできるようになります。

「デッド再帰」状況が発生すると、スタック サイズをどれだけ増やしてもオーバーフローが発生し、意味がなくなります。

インタビュアー: では、この簡単な小さなプログラムを見てみましょう。メモリ内でどのように実行されるのか、大まかに教えていただけますか?

  パブリックボイドテスト（）{
      バイト i = 15;
整数j = 8;
整数k = i + j;
 }

より理解を深めるために写真をご覧ください

「ああQ:」まずコードをコンパイルし、バイトコードファイルを確認します。上図の左側に示すように、実行プロセスは次のようになります。

1. まず、実行する命令アドレス 0 が PC レジスタに格納されます。このとき、ローカル変数テーブルとオペランドスタックのデータは空です。
2. 最初の命令 bipush が実行されると、オペランド 15 がオペランド スタックに配置され、PC レジスタの値は次の命令の実行アドレスである 2 に設定されます。
3. 命令アドレス2の演算命令が実行されると、オペランドスタック内のデータが取り出され、ローカル変数テーブルの位置1に格納されます。このメソッドはインスタンス メソッドなので、この値は位置 0 に格納され、PC レジスタの値は 3 になります。
4. 手順 2 および 3 と同じように、最初に 8 をオペランド スタックに入れてから取り出し、ローカル変数テーブルに格納します。PC レジスタの値も 3 -> 5 -> 6 に変わります。
5. アドレス命令が 6、7、または 8 の場合、ローカル変数テーブルのインデックス位置 1 と 2 のデータがオペランド スタックに再ロードされ、iadd 操作が実行されます。結果値はオペランドスタックに格納され、PCレジスタの値も6->7->8->9に変更されます。
6. 演算命令 istore_3 を実行し、オペランド スタック内のデータを取り出してインデックス 3 のローカル変数テーブルに格納し、戻り命令を実行してメソッドを終了します。

「インタビュアー：」 心の中では、この人は大丈夫そうだ。それはいい指摘ですね。メソッドで定義されたローカル変数がスレッドセーフであるかどうか教えてください。

「Ah Q:」では、もう少し例を挙げて説明しましょう。

パブリッククラス LocalParaSafe問題 { 
 
 
    /**
     * スレッドセーフ
     * StringBuilder自体はスレッドセーフではありませんが、
     * ただし、s1 変数はこのスタック フレームのローカル変数テーブルにのみ存在します。
     * スタックフレームは各スレッドから独立しているため、
     * ここでのs1はスレッドセーフです
     */
公共 静的voidメソッド01（）{
        // スレッド内で作成され、ローカル変数に属する
        StringBuilder s1 = 新しいStringBuilder();
        s1.append( "a" );
        s1.append( "b" );
    } 
 
    /**
     * スレッドが安全でない
     * StringBuilderはこの時点でパラメータとして渡されるため、
     * 他の外部スレッドもアクセスできるため、スレッドセーフではありません
     */
公共 静的voidメソッド02(StringBuilder stringBuilder) {
        文字列ビルダー.append( "a" );
        文字列ビルダー.append( "b" );
    } 
 
    /**
     * スレッドが安全でない
     * 現時点ではStringBuilderは複数のスレッドで同時に動作しています
     */
公共 静的voidメソッド03（）{
        StringBuilder は、新しい StringBuilder() を作成します。
        新しいスレッド(() -> {
            文字列ビルダー.append( "a" );
            文字列ビルダー.append( "b" );
        }, "t1" ).start(); 
 
        メソッド02(文字列ビルダー);
    } 
 
    /**
     * スレッドが安全でない
     * メソッドはこの時点でStringBuilderを返すため
     * 外部の他のスレッドはStringBuilder参照を直接変更できるため、安全ではありません
     */
公共 静的StringBuilderメソッド04() {
        StringBuilder は、新しい StringBuilder() を作成します。
        文字列ビルダー.append( "a" );
        文字列ビルダー.append( "b" );
 stringBuilderを返します。
    } 
 
 
    /**
     * StringBuilderはスレッドセーフです
     * この時点で、stringBuilder 値は現在のスタック フレームのローカル変数テーブルに存在します。
     * 他のスレッドはこの参照にアクセスできません。
     * メソッドが実行されると、ローカル変数テーブル内のstringBuilderは破棄されます
     * 返された stringBuilder.toString() はスレッドセーフではありません
     * toString によって最終的な戻り値が返された後、他のスレッドはそれを操作できますが、String 自体はスレッドセーフではありません。
     */
公共 静的文字列メソッド05() {
        StringBuilder は、新しい StringBuilder() を作成します。
        文字列ビルダー.append( "a" );
        文字列ビルダー.append( "b" );
 stringBuilder.toString()を返します。
    }
 }

少しわかりにくいかもしれないので、まとめると、オブジェクトがメソッド内で生成および破棄され、外部に返されない場合は、スレッド セーフティの問題はありません。逆に、クラス自体がスレッドセーフでない場合は、スレッドセーフの問題が発生します。

インタビュアー: 「悪くないですね。納得できました。では、ヒープ メモリについての理解をもう少し詳しく教えてください。」

「阿Q:」ああ、今日は疲れた。私は一日中このことについて話してきましたが、これ以上は言いたくありません。

「インタビュアー:」では、今日はここまでにして、戻って通知を待ちましょう。

この記事はWeChatの公開アカウント「A Q Talks Code」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合はAQ Says Code公式アカウントまでご連絡ください。