最適化：

メソッド内でのみ使用されるオブジェクトはヒープ上に割り当てられず、スタック上に直接割り当てられ、メソッド終了後に自動的にガベージコレクションが実行され、GC の負荷が軽減されます。

最適化のリファレンス:

Java でのエスケープ解析ですが、.net では参照されません。

Java オブジェクトはヒープに割り当てられ、呼び出しスタックにはオブジェクトのポインタのみが保存されます。

オブジェクトが使用されなくなった場合、参照ツリーを走査してメモリを再利用するために GC に依存する必要があります。オブジェクトの数が多い場合は、GC が実行されます。

大きなプレッシャーをもたらしますが、アプリケーションのパフォーマンスにも間接的に影響します。ヒープに割り当てられる一時オブジェクトの数を減らすことが、間違いなく最も効果的な最適化です。

方法。

メソッド本体でローカル変数が宣言されており、その変数はメソッド実行ライフサイクル中にエスケープされないと仮定します。

(メソッド本体では、参照は外部に公開されません)。JVM メモリ割り当てメカニズムに従って、変数クラスのインスタンスが最初にヒープ内に作成され、次に返されたオブジェクトポインタがコールスタックにプッシュされて実行が継続されます。これは、最適化の前に JVM がそれを処理する方法です。

最適化の原則: エスケープされていない変数を分析して見つけ、変数クラスのインスタンス化メモリを (ヒープに入ることなく) スタック上に直接割り当てます。

割り当てが完了すると、呼び出しスタック内で実行が継続され、最終的にスレッドが終了し、スタック領域が再利用され、ローカル変数も再利用されます。

これは最適化された処理方法であり、比較すると、主な違いはスタック領域が一時オブジェクトの記憶媒体として直接使用されることであることがわかります。

これにより、ヒープ内の一時オブジェクトの割り当て数が削減されます。

エスケープ分析により、ローカル変数への複数の参照が同じメソッド本体に制限されており、これらすべての参照がメソッド本体の外側の場所に「エスケープ」できないことが判明した場合、HotSpot は JIT に最適化アクション (ロックの省略) を実行するように要求します。ローカル変数で所有されます。

これがロックの省略です。