JVMヒープメモリ領域

ヒープ、JVMにはヒープメモリが1つしかないため、ヒープメモリのサイズを調整できます。
クラスローダーがこれらのファイルを読み取った後、通常はヒープ内にあるものを配置しますか?
クラス、メソッド、定数、変数、および参照されたタイプの実際のオブジェクトを保存します。

ヒープメモリは、次の3つの領域に分けられます。

  • 新生児エリア(エデンスペース)
  • リタイアメントエリア

  •  ここに画像の説明を挿入
    主にエデンパークとリタイアメントエリアの常設エリアでのGCガベージコレクション。JKD8以降
    、メモリがいっぱいでOOM、ヒープメモリが不足
    していると仮定して、常設ストレージエリアの名前を変更します(メタスペース)。
    ここに画像の説明を挿入

新生児領域:
カテゴリー:出生地と成長、さらには死。

  • エデンの園:すべてのオブジェクトはエデンの園で新しいです

  • サバイバルエリア(0、1)

  • 調査後、オブジェクトの99%は一時的なものです

高齢者エリア:

パーマネントエリア
このエリアはメモリに常駐します。JDK自体によって運ばれるClassオブジェクトを格納するために使用されます。インターフェイスメタデータは、Javaの実行時に環境またはクラス情報を格納します〜、この領域にはガベージコレクションはありません!VM仮想化をオフにすると、この領域のメモリが解放されます。
スタートアップクラスは、多数のサードパーティのjarパッケージをロードします。Tomcatは、あまりにも多くのアプリケーション、動的に生成された多数のリフレクションクラスをデプロイしました。常にロードされています。メモリがいっぱいになるまで、00Mが表示されます。
●jdk1.6の前:永続的な生成、定数プールはメソッド領域にあります。
●jdk1.7:永続的な生成ですが、徐々に劣化します。永続的な生成に進みます。定数プールはヒープ内
●jdk1.8以降:永続的な生成はなく、定数プールはメタスペースにあります

ここに画像の説明を挿入

ここに画像の説明を挿入
メタスペース:物理的にではなく、論理的に存在します

プログラムを実行して、仮想マシンのメモリサイズを確認しましょう。

public class Test {
    
    

    public static void main(String[] args) {
    
    
        //返回虚拟机试图使用的最大内存
        long max = Runtime.getRuntime().maxMemory();
        //返回jvm的初始化总内存
        long total = Runtime.getRuntime().totalMemory();

        System.out.println("max=" + max +"字节" + (max/(double)(1024*1024))+"MB");
        System.out.println("total=" + max +"字节" + (total/(double)(1024*1024))+"MB");
        //默认情况下:分配内的总内存大约是电脑内存的1/4,而初始化的内存为1/64
    }
}

デフォルト:割り当てられた合計メモリはコンピュータメモリの約1/4であり、初期化されたメモリは1/64
です。操作の結果:(私のコンピュータメモリは16Gです)
ここに画像の説明を挿入

ここに画像の説明を挿入

305664k + 699392 = 1029177344であるため、メタスペースの物理メモリはヒープ内にないことがわかり
ます。

構成でメモリサイズを手動で調整します。

-Xms1024m -Xmx1024m -XX:+ PrintGCDetails

ここに画像の説明を挿入
ここに画像の説明を挿入
おじさん:

public class Hello {
    
    
    public static void main(String[] args) {
    
    

// -Xms8m -Xmx8m -XX:+PrintGCDetails
   String str = "longzx6666666666666";
   while (true){
    
    
       str += str + new Random().nextInt(999999999)+new Random().nextInt(999999999);
   }
    }

}

メモリを8Mに調整し、結果を印刷します

-Xms8m -Xmx8m -XX:+ PrintGCDetails

ここに画像の説明を挿入

プロジェクトで、0OMの障害が突然発生し、トラブルシューティングの方法〜問題が発生した理由を調査する

●コードの最初の数行にエラーが表示されます:メモリスナップショット分析ツール、MAT、Jprofiler
●Dubug、コードを1行ずつ分析します!
MAT、Jprofiler役割
●ダンプメモリファイルを分析し、メモリリークをすばやく特定します。
●ヒープ内のデータを取得する
●大きなオブジェクトを取得する〜
メモリ分析ツール:JProfilerをダウンロードしてインストールし、IDEAがプラグインをインストールしました

1. JProfiler(IDEA)プラグイン
をダウンロードします。設定のダウンロード-IDEAに直接プラグインし、JProfilerを検索し、インストールボタンをクリックしてインストールし、IDEAツールを起動します。
方法2:
公式Webサイトからプラグインをダウンロードします。
公式プラグインを手動でインストールします。ダウンロードアドレス
はホームページの中央にあります。過去のバージョンのダウンロードリンクを含む、最新バージョンのJProfilerを確認できます。ダウンロードをクリックしてダウンロードしてください。
次に、IDEAにプラグインを導入し、
ここに画像の説明を挿入
圧縮パッケージの場所を見つけて、
インストールが成功した後に再起動すると、次の兆候が見られます
ここに画像の説明を挿入

2.JProfiler監視ソフトウェアの
公式Webサイトアドレスをインストールします。3。IDEA
ここに画像の説明を挿入
オペレーティング環境を構成します。
設定–ツール–JProflier–JProflier実行可能ファイルJProfileを選択して実行可能ファイルをインストールします。(システムにインストールされているバージョンが1つだけの場合、IDEAの起動時にデフォルトで選択されます)
ここに画像の説明を挿入
テストの保存

import java.util.ArrayList;

public class DumpDemo {
    
    
    byte[] array = new byte[1*1024*1024]; //1m

    public static void main(String[] args) {
    
    
        ArrayList<DumpDemo> list = new ArrayList<>();
        int count = 0;
        try{
    
    
            while (true){
    
    
                list.add(new DumpDemo());
                count = count + 1;
            }
        }catch (Exception e){
    
    
            System.out.println(" count:"+count);
        }
    }
}

ここに画像の説明を挿入

-Xms1m -Xmx8m -XX:+ HeapDumpOnOutOfMemoryError

再実行
ここに画像の説明を挿入

ファイル
ここに画像の説明を挿入
ここに画像の説明を挿入
を開くクリックしてファイルを開き、JProfilerを使用して
ここに画像の説明を挿入
ここに画像の説明を挿入
分析スレッドを分析します。
ここに画像の説明を挿入
プログラムでエラーをキャッチすることもできます。
ここに画像の説明を挿入
ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/qq_41784749/article/details/111589410