JavaRush /Java Blog /Random-JA /Java メモリの管理 (およびコードの保存) のガイド
pandaFromMinsk
レベル 39
Минск

Java メモリの管理 (およびコードの保存) のガイド

Random-JA グループに公開済み
翻訳者注: このメモを翻訳したいという欲求は、6 月の早朝、地下鉄の車内で半分寝ながらこのメモを読んだ後に現れました。対象者: Java の世界への最初の一歩を踏み出しており、基本的な技術的背景や願望の性質上、Java の内部に入り込み、すべての「電気力学」プロセスを学びたいと強く望んでいる人々。これを読む人にとって、これが JVM と GC の構成の世界への旅の出発点になると確信しています。順風!元の記事はこちら 開発者は、Java アプリケーションからバグを除去し、必要なパフォーマンスを得るために数え切れないほどの時間を費やしています。テスト中に、アプリケーションの動作が徐々に遅くなり、最終的には完全にクラッシュするか、単にパフォーマンスが低下していることに気づきます。最終的にはメモリ リークが発生することを受け入れます。ガベージ コレクター Java は、これらのリークに対処するために最善を尽くします。しかし、このような状況に直面したときにできることは限られています。メモリ リーク呼び出しを特定し、原因を特定し、アプリケーション全体のパフォーマンスに影響を与える Java ガベージ コレクターの役割を理解する方法が必要です。

Java メモリ リークの主な症状

アプリケーションにメモリ リークの問題があることを示す症状がいくつかあります。アプリケーションの突然の障害ではなく、パフォーマンスのわずかな低下は、メモリ リークを示しているだけです。この問題は、動作中に毎回発生することもあれば、アプリケーションが大量のデータを処理し始めたとき、または逆にアプリケーションのスケーリングを開始したときにのみ発生することもあります。リークによって利用可能なメモリ リソースがすべて消費されると、アプリケーションはおそらくメモリ不足エラーを表示します。アプリケーションを再起動して最善の結果を期待すると、リークが修正されるまで繰り返しクラッシュが発生することになります。一般に、メモリ リークは、メモリを解放せずにオブジェクト参照が蓄積した場合に発生します。これらは利用可能なメモリをすべて占有し、アプリケーションが必要なリソースにアクセスできなくなります。

メモリリークとして現れる構成エラー

Java メモリの問題を引き起こす状況を調べて分析を行う前に、その調査がまったく別の問題に関連していないかを確認する必要があります。一部のメモリ不足エラーは、構成エラーなどのさまざまなエラーが原因で発生します。アプリケーションのヒープ メモリが不足しているか、システム上の他のアプリケーションと競合している可能性があります。メモリ不足の問題について話し始めても、リークの原因がわからない場合は、アプリケーションを別の視点から見てください。ファイナライゼーション スレッドを変更するか、永続生成スペースの量を増やす必要があることがわかります。永続生成スペースは、Java クラスの記述といくつかの追加データを保存するための JVM メモリの領域です。

メモリ監視ツールの利点

メモリ監視ツールを使用すると、Java アプリケーションによる利用可能なリソースの使用状況をより詳細に把握できます。このソフトウェアを使用すると、メモリ リークやその他のパフォーマンス インシデントの問題の根本原因を絞り込むための一歩を踏み出すことができます。ツールにはいくつかのカテゴリがあり、メモリ リークに対処している場合でも、問題と何が問題かを適切に報告する方法を理解するには、さまざまなアプリケーションを使用する必要がある場合があります。ヒープ ダンプ ファイルは、Java メモリの分析に必要な情報を提供します。この場合、ダンプ ファイルを生成するツールと詳細な分析用の 2 つのツールを使用する必要があります。このソリューションは、アプリケーションで何が起こっているかに関する詳細情報を提供します。一度、ツールが問題の可能性のある場所を特定し、領域を絞り込んでインシデントの正確な場所を発見します。そしてこの期間は、試行錯誤の中で最も長く、最も憂鬱な時期です。メモリ アナライザーはコード内のいくつかの問題を示しますが、アプリケーションがどのような問題に遭遇しているのか完全にはわかりません。それでも同じエラーが発生する場合は、最初からやり直して、別の考えられるエラーに対処してください。一度に 1 つずつ変更を加えて、エラーを再現してみてください。エラー状態を再現するには、アプリケーションをしばらく実行する必要があります。最初のテスト中にメモリ リークが発生した場合は、必ずアプリケーションのロード テストを行ってください。アプリケーションは少量のデータでは問題なく動作する可能性がありますが、大量のデータを扱うと再び同じエラーが発生する可能性があります。それでも同じエラーが発生する場合は、最初からやり直して、考えられる別の原因を探す必要があります。メモリ監視ツールは、アプリケーションが完全に動作するとその有用性が証明されます。開発者が問題に取り組み、将来のプログラミング技術を向上させ、高負荷下で Java がどのように動作するかを確認するために役立つ過去のパフォーマンス データを収集する前に、JVM パフォーマンスをリモートで監視し、障害状況を事前に検出できます。多くのソリューションには「危険」アラート モードまたは他の同様のモードが含まれているため、開発者は何が問題になっているのかをすぐに知ることができます。すべての開発者は、運用中に重要なアプリケーションがクラッシュして、アプリケーションのダウンタイム中に数万ドルまたは数十万ドルの損失が発生することを望んでいません。そのため、メモリ監視ツールは開発者の応答時間を短縮します。メモリ監視アプリケーションを使用すると、顧客のところに行く必要がなく、診断プロセスを即座に開始できます。顧客のところでは、どのようなエラーが発生したか、アプリケーションがどのようなエラー コードを生成したかを正確に教えてくれる人は誰もいません。Java アプリケーションのメモリとパフォーマンスの問題に頻繁に悩まされる場合は、テスト プロセスを詳しく調べてください。開発プロセスのそれぞれの弱点を特定し、テスト戦略を変更します。同僚に相談し、テストのアプローチを既存のベスト プラクティスと比較してください。場合によっては、コードの小さな部分を修正して、アプリケーション全体に永続的な影響を与えることが必要になることがあります。

Java メモリとメモリ リークに対するガベージ コレクタの役割

Java のガベージ コレクターは、アプリケーションのパフォーマンスとメモリ使用量において重要な役割を果たします。未使用の (死んだ) オブジェクトを探して削除します。これらのオブジェクトはメモリを占有しないため、アプリケーションは引き続きリソースの可用性を確保します。場合によっては、アプリケーションが GC に死んだオブジェクトを削除するための十分な時間やリソースを与えず、それらのオブジェクトが蓄積されることがあります。死んだと思われるオブジェクトにアクティブにアクセスできる状況に遭遇する場合があります。ガベージコレクターはこれについて何もできません。なぜなら... 自動メモリ管理メカニズムはアクティブなオブジェクトをバイパスします。通常、ガベージ コレクターは自律的に動作しますが、深刻なメモリ問題に対応するには動作を調整する必要があります。ただし、GC 自体がパフォーマンスの問題を引き起こす可能性があります。

GC エリア

ガベージ コレクターはオブジェクトをさまざまな領域に分離して、アセンブリを最適化します。ヤングジェネレーションでは、すぐに消えてしまうオブジェクトが特徴です。ゴミ収集人は、掃除の時間からこのエリアで働くことがよくあります。一定期間経過後も存続するオブジェクトは旧世代に転送されます。旧世代領域では、オブジェクトは長期間にわたって残り、コレクターによって頻繁に削除されません。ただし、コレクターがスコープ内で実行されている場合、アプリケーションはコレクターがライブ オブジェクトを調べてガベージをクリーンアップする大規模な操作を実行します。その結果、アプリケーションオブジェクトは最終永続世代領域に配置されます。通常、これらのオブジェクトには必要な JVM メタデータが含まれています。アプリケーションは永続生成では多くのガベージを生成しませんが、クラスが不要になったときにクラスを削除するコレクターが必要です。

ガベージ コレクターと応答時間の関係

ガベージ コレクターは、アプリケーション スレッドの実行優先順位に関係なく、完了を待たずにスレッドを停止します。この現象は「ストップ・ザ・ワールド」イベントと呼ばれます。ガベージ コレクターの若い世代領域はパフォーマンスにわずかな影響を与えますが、GC が集中的なクリーンアップを実行している場合には問題が顕著になります。最終的には、若い世代のマイナー GC が常に実行されたり、古い世代が制御不能な状態になったりする状況になります。このような状況では、若い世代の周波数と、このコレクタ領域のサイズを増やす必要があるパフォーマンスのバランスを取る必要があります。ガベージ コレクターの永続世代領域と旧世代領域は、アプリケーションのパフォーマンスとメモリ使用量に大きな影響を与えます。この大規模なガベージ クリーンアップ操作はヒープを通過して、死んだオブジェクトを追い出します。このプロセスにはマイナー ビルドよりも時間がかかり、パフォーマンスへの影響にさらに時間がかかる可能性があります。スクラビング強度が高く、旧世代領域のサイズが大きい場合、「Stop the world」イベントによりアプリケーション全体のパフォーマンスが滞ります。ガベージ コレクションを最適化するには、プログラムの実行頻度、全体的なパフォーマンスへの影響、および監視の頻度を減らすためにアプリケーション設定を調整する方法を監視する必要があります。アプリケーションが配置から自分自身を隔離することなく、複数回配置された同じオブジェクトを識別する必要がある場合や、システム全体を妨げている圧縮ポイントを見つける必要がある場合があります。バランスを正しく保つには、特に若い世代と古い世代のバランスが取れていない場合、CPU 負荷からガベージ コレクター サイクルに至るすべてに細心の注意を払う必要があります。メモリ リークに対処し、ガベージ コレクションを最適化すると、Java アプリケーションのパフォーマンスが向上します。文字通り、多くの可動部分をやりくりしていることになります。しかし、適切なトラブルシューティング アプローチと、厳密な可視性を提供するように設計された分析ツールを使用すれば、トンネルの終わりの光に到達することができます。そうしないと、パフォーマンス関連の問題が発生することになります。Java アプリケーションでは、慎重なメモリの配置と監視が重要な役割を果たします。アプリケーションを最適化し、メモリ不足エラーを回避するには、ガベージ コレクション、オブジェクトの破棄、パフォーマンスの間の相互作用を完全に制御する必要があります。監視ツールを使用すると、潜在的な問題を常に把握し、メモリ使用率の傾向を強調できるため、トラブルシューティングに積極的にアプローチできます。メモリ リークは、特に構成パラメータ値が正しくない場合に通常のトラブルシューティングが無効であることを示しますが、メモリの問題に対処することで、障害となるインシデントを迅速に回避できます。Java メモリ チューニングと GC の完璧な機能により、開発プロセスが大幅に容易になります。
コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION