OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方

Copyright (c)2014 ITOCHU Techno-Solutions Corporation Copyright (c)2014 ITOCHU Techno-Solutions Corporation

OutOfMemoryError の対応方法 / Heap 解析ツール(MAT)の使い方

ソリューションビジネス部

橋本和俊

2014/6/24

Copyright (c)2014 ITOCHU Techno-Solutions Corporation

はじめに

• 発表する内容は個人の見解であり、所属する組織の公式な見解ではありません。

• 資料の内容は正確を期するよう注意しておりますが、妥当性や正確性について保証するものではありません。

• 資料に関しては以下の環境において作成しております。

– Oracle WebLogic Server 12.1.2

– Windows 7

• 内容として、管理者向け、及び、初心者用に用意してあります。

1


導入

OutOfMemoryError(以降、OOME)に

悩まされておりませんか？

2


導入

• OOMEはJavaVMのメモリ不足に対するエラーです。

• 下記を知れば、OOMEの解決までが早くなります。

1. JavaVMのメモリに関する内訳

2. OOMEのエラーメッセージの意味

3. Heap Dumpの出し方

• あとできれば、MAT(解析ツール)の簡単な使い方も…

3


Agenda

• OOME の理解

– Javaの製品知識/メモリの持ち方

– OOMEとは

– GCログの出力設定

– GCログの見方

– OOME調査方法

– Heap Dump の取得方法

• MATの使い方

• 個人的所管

4


Javaの製品知識

• Oracle 社が提供している Java は簡単に分けると…

– HotSpot(Sun JDK)

• Sun -> Oracle 社

• 今回はJDK5以降を対象に記載しています。JDK1.4でも同様の部分が多いです。

– JRockit

• Appeal Virtual Machines -> BEA Systems -> Oracle 社

• 今回はR28以降を対象に記載しています。

– HotRockit

• HotSpotとJRockitとの融合を行ったJavaVM(JDK7 以降)の通称。

• 正式にはOracle JDKやHotSpot。

5


Java におけるメモリの持ち方

• HotSpotとJRockitとではメモリの持ち方が違います。

– HotSpot/HotRockit(JDK7まで)

• Heap

– JavaVMのオブジェクト(String等)や配列の実体が格納されます。

– 中でYoung領域とOld領域に分かれます。

• Permanent(以降Perm)

– JavaVMのクラス情報などのMeta情報が格納されます。

• C Heap(Native)

– 最適化されたコード/JNIなどが格納されます。

• JDK8からはPerm -> Metaspace となり、Nativeに配置されるなど仕様も変わっておりますが、今回は説明を省略。

6

Heap Permanent C Heap

(Native)


Java におけるメモリの持ち方

• HotSpotとJRockitとではメモリの持ち方が違います。

– JRockit

• Permはありません。C Heapに含まれます。

7

Heap C Heap

(Native)


OOMEとは

• JavaVMは使用済みで参照されないオブジェクトをメモリを開放する仕組み=GC(Young領域のGC)/FullGC(Heap

全体のGC)があります。

• しかし、GCを行ってもメモリが確保できない場合、JavaVMはメモリ不足(OOME)を発生させます。

• OOMEはJavaのメモリ不足を示すエラーですが、場所により種類があります。

8


OOMEとは

• Heap

– java.lang.OutOfMemoryError: Java heap space

– java.lang.OutOfMemoryError: GC overhead limit

exceeded

• JDK6以降で” -XX:-UseGCOverheadLimit”を指定していない場合

– java.lang.OutOfMemoryError: getNewTla

• JRockitの場合(※TLAが足りていない可能性もあり。)

• Perm

– java.lang.OutOfMemoryError: PermGen space

• C Heap(Native)

– SIGSEGVで落ちることとか、

java.lang.OutOfMemoryError: unable to create new

native thread とかrequested XXXX bytes for

ChunkPool::allocate. Out of swap space? とか…

9

Heap Permanent C Heap

(Native)


OOMEとは

• OOMEが発生した際にはJavaの動作が不安定になるため、ありえない動作が起こりえます。 (※FYI)

– 再起動しなければ解消されません。

– 再起動したのみでは一時的な解消でしかありません。

– OOME後の動作についてはサポート対象外とされます。

• OOMEはコンソールログにのみに出力される場合があります。WebLogicの運用においてはコンソールログの出力は必須です。

– 下記設定のみでは出力されない情報もあります。(スレッドダンプとか…)

• “標準出力のロギングのリダイレクトを有効化”

• ”標準エラー出力のロギングのリダイレクトを有効化”

10


OOMEとは

• 原因を特定させるためにはOOME発生時のスレッドスタックだけでは不可能です。

– スレッドで実行した行が原因でメモリを圧迫しているのか、別のスレッドで確保していたオブジェクトがメモリを圧迫しているのかは分かりません。

• 普段からGCの発生状況が分かるGCログを取得し、どのメモリが足りないかを確認できる状態にしましょう。

– vmstatやpsの結果ではJavaVMのメモリ使用量までは分かりません。

11


GCログの出力設定(HotSpot)

• GCログの設定

12

オプション説明

-verbose:gc GC情報の出力

-Xloggc:<ファイル名> GCログの出力先設定再起動時に上書きされないようにファイル名に日時を入れる等、工夫してください。

-XX:+PrintGCDetails GCログの詳細設定

-XX:+PrintGCDateStamps(6u4以降)

/ -XX:+PrintGCTimeStamps GCログの時間出力設定


GCログの出力設定(HotSpot)

• GCログのローテーション(7u2,6u34以降)

13


-XX:-UseGCLogFileRotation GCログのローテーション有効化

-XX:NumberOfGClogFiles=1 GCログのローテーションファイル数

-XX:GCLogFileSize=8K GCログのローテーションのファイルサイズ


GCログの出力設定(JRockit)

• HotSpotとほぼ同様の設定です。

– JRockitにおけるGCログのローテーションのオプションはありません。

– 代わりとして、jrcmd {PID} verbosity filename={FILE}

にて出力ファイル名を変更させることにより代用することが可能です。

• cron等で定期的に実行する必要があります。

14


-Xverbose:memory GC情報の出力

-Xverboselog:<ファイル名> GCログの出力先設定

-XverboseTimeStamp GCログの日時出力設定


GCログの見方

• GCログの見方を確認する前に基本的なHeapの使用量の推移を確認してみましょう。

• Heap使用量が下がる時点がGC/FullGCが発生しております。

15

4/1

/20

14

9:0

0

4/1

/20

14

9:0

3

4/1

/20

14

9:0

6

4/1

/20

14

9:0

9

4/1

/20

14

9:1

2

4/1

/20

14

9:1

5

4/1

/20

14

9:1

8

4/1

/20

14

9:2

1

4/1

/20

14

9:2

4

4/1

/20

14

9:2

7

4/1

/20

14

9:3

0

4/1

/20

14

9:3

3

4/1

/20

14

9:3

6

4/1

/20

14

9:3

9

4/1

/20

14

9:4

2

4/1

/20

14

9:4

5

4/1

/20

14

9:4

8

4/1

/20

14

9:5

1

4/1

/20

14

9:5

4

4/1

/20

14

9:5

7

4/1

/20

14

10

:00

4/1

/20

14

10

:03

4/1

/20

14

10

:06

4/1

/20

14

10

:09

4/1

/20

14

10

:12

4/1

/20

14

10

:15

4/1

/20

14

10

:18

4/1

/20

14

10

:21

4/1

/20

14

10

:24

4/1

/20

14

10

:27

4/1

/20

14

10

:30

4/1

/20

14

10

:33

4/1

/20

14

10

:36

4/1

/20

14

10

:39

Heapの推移


GCログの見方

• 赤丸がFullGCが発生した時点です。

• FullGC時の発生後のHeap使用量がほぼ同一ならば使用量 = 開放量であり、動作に問題ありません。

16

4/1

/20

14

9:0

0

4/1

/20

14

9:0

3

4/1

/20

14

9:0

6

4/1

/20

14

9:0

9

4/1

/20

14

9:1

2

4/1

/20

14

9:1

5

4/1

/20

14

9:1

8

4/1

/20

14

9:2

1

4/1

/20

14

9:2

4

4/1

/20

14

9:2

7

4/1

/20

14

9:3

0

4/1

/20

14

9:3

3

4/1

/20

14

9:3

6

4/1

/20

14

9:3

9

4/1

/20

14

9:4

2

4/1

/20

14

9:4

5

4/1

/20

14

9:4

8

4/1

/20

14

9:5

1

4/1

/20

14

9:5

4

4/1

/20

14

9:5

7

4/1

/20

14

10

:00

4/1

/20

14

10

:03

4/1

/20

14

10

:06

4/1

/20

14

10

:09

4/1

/20

14

10

:12

4/1

/20

14

10

:15

4/1

/20

14

10

:18

4/1

/20

14

10

:21

4/1

/20

14

10

:24

4/1

/20

14

10

:27

4/1

/20

14

10

:30

4/1

/20

14

10

:33

4/1

/20

14

10

:36

4/1

/20

14

10

:39

Heapの推移


GCログの見方

• メモリリークが疑われる例です。 FullGC発生後のHeap

の使用量が少しずつ増えています。

– メモリ使用量が短時間で急激に伸びている場合はメモリリークよりもアプリの作り的にメモリを大きく消費しているケースが多いです。(※DBのデータを全てHeapメモリに載せたとか…)

17

4/1

/20

14

9:0

0

4/1

/20

14

9:0

2

4/1

/20

14

9:0

4

4/1

/20

14

9:0

6

4/1

/20

14

9:0

8

4/1

/20

14

9:1

0

4/1

/20

14

9:1

2

4/1

/20

14

9:1

4

4/1

/20

14

9:1

6

4/1

/20

14

9:1

8

4/1

/20

14

9:2

0

4/1

/20

14

9:2

2

4/1

/20

14

9:2

4

4/1

/20

14

9:2

6

4/1

/20

14

9:2

8

4/1

/20

14

9:3

0

4/1

/20

14

9:3

2

4/1

/20

14

9:3

4

4/1

/20

14

9:3

6

4/1

/20

14

9:3

8

4/1

/20

14

9:4

0

4/1

/20

14

9:4

2

4/1

/20

14

9:4

4

4/1

/20

14

9:4

6

4/1

/20

14

9:4

8

4/1

/20

14

9:5

0

4/1

/20

14

9:5

2

4/1

/20

14

9:5

4

4/1

/20

14

9:5

6

4/1

/20

14

9:5

8

4/1

/20

14

10

:00

4

/1/2

01

4 1

0:0

2

4/1

/20

14

10

:04

4

/1/2

01

4 1

0:0

6

4/1

/20

14

10

:08

4

/1/2

01

4 1

0:1

0

4/1

/20

14

10

:12

4

/1/2

01

4 1

0:1

4

4/1

/20

14

10

:16

4

/1/2

01

4 1

0:1

8

4/1

/20

14

10

:20

4

/1/2

01

4 1

0:2

2

4/1

/20

14

10

:24

4

/1/2

01

4 1

0:2

6

4/1

/20

14

10

:28

4

/1/2

01

4 1

0:3

0

4/1

/20

14

10

:32

4

/1/2

01

4 1

0:3

4

4/1

/20

14

10

:36

4

/1/2

01

4 1

0:3

8

Heapの推移


GCログの見方

• GCログを見てみましょう。(FullGCの場合)

– HotSpot

• 2014-06-10T15:55:31.907+0900: 39.336: [Full GC

– [日付]: [起動してからの秒時間]: [GC/Full GC

• PSYoungGen: 43512K->0K(306176K)

– Young領域の使用量が 43512K->0K に。

– 現在のYoung領域の最大値：306176K

18

2014-06-10T15:55:31.907+0900: 39.336: [Full GC [PSYoungGen:

43512K->0K(306176K)] [ParOldGen: 74381K->85121K(699392K)]

117894K->85121K(1005568K) [PSPermGen: 103309K-

>103237K(262144K)], 0.3625735 secs] [Times: user=1.00

sys=0.02, real=0.36 secs]


GCログの見方


– HotSpot

• ParOldGen: 74381K->85121K(699392K)

– Old領域の使用量が 74381K->85121K に。

– 現在のOld領域の最大値：699392K

• 117894K->85121K(1005568K)

– Heap全体の使用量が 117894K->85121K に。

– 現在のHeapの最大値：1005568K

19



117894K->85121K(1005568K) [PSPermGen: 103309K-




GCログの見方


– HotSpot

• PSPermGen: 103309K->103237K(262144K)], 0.3625735 secs

– Permの使用量が 103309K->103237K に。

– 現在のPermの最大値：262144K

– GCにかかった時間： 0.3625735 secs

• Times: user=1.00 sys=0.02, real=0.36 secs

– user/sys はCPU時間

– real が実際にかかった時間

20



117894K->85121K(1005568K) [PSPermGen: 103309K-




GCログの見方


– JRockit

• [memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1]

– [ログの種類][時刻][PID][GC(YC)/FullGC(OC)と回数]

• 584.903-584.937

– 起動してからの秒数における、GC起動時間 – GC終了時間

21

[memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1] 584.903-

584.937: OC 1032213KB->239710KB (1048576KB), 0.034 s, sum

of pauses 31.643 ms, longest pause 31.643 ms.


GCログの見方


– JRockit

• OC 1032213KB->239710KB (1048576KB), 0.034 s,

– YC(GC)/OC(FullGC)

– Heapの使用量が 1032213KB->239710KB に。

– 現在のHeapの最大値： 1048576KB

– かかった時間： 0.034 s

• sum of pauses 31.643 ms, longest pause 31.643 ms

– GCの停止時間総計と最長の停止時間

22

[memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1] 584.903-

584.937: OC 1032213KB->239710KB (1048576KB), 0.034 s, sum

of pauses 31.643 ms, longest pause 31.643 ms.


GCログの見方

• GCログの見方

– まずは見るべきは…

• FullGC後のHeap使用量

• FullGCの単位時間あたりの回数

• FullGCにかかった時間(特にStop The Worldの時間)

– 2014-06-09T16:43:52.404+0900: 62.115: [GC

[PSYoungGen: 304340K->43490K(306176K)] 304412K-

>55271K(1005568K), 0.0649016 secs] [Times: user=0.20


– 可能であれば加工してグラフにするとメモリ消費傾向が分かりやすいです。

23


OOME調査方法(Perm)

• Permが足りない場合は…

– まずは増やしてみましょう。

• -XX:PermSize(初期値) と -XX:MaxPermSize(最大値)

• 基本的に初期値=最大値に設定してください。

– 増やしても足りない場合は読み込まれているクラス情報を確認する等の別の視点からの調査が必要です。

• クラス・ローダー分析ツール(CAT)を使うとか…

(※WebLogic 10.3.4 以降)

24


OOME調査方法(C Heap)

• C Heapが足りない場合は…

– 64bit JavaVMに変更すればとりあえず制限はほぼありません。

– 32bit JavaVM の場合はHeapやPermを減らしてみるのも一つの手段です。

• C Heapの最大量は[プロセスの最大メモリ量] – [Heap最大量] –

[Perm最大量]のため、Heap/Permを減らせば最大量は増えることになります。

• ただし、他のOOMEが出ないように注意してください。

– Native Memory Tracking(7u40以降) を使えば解析も可能ですが…

25


OOME調査方法(Heap)

• Heapが足りない場合…

1. Heapが少ない場合はHeapを増やしてみましょう。

• 単純に足りない場合もあります。

2. GCログを見て、Heapの使用量の動きをみてみましょう。

• GCログにより、メモリリークが起きているかどうかを確認しましょう。

3. MATを使ってみましょう。

26



• Heapが足りない場合…

– Heapが1Gぐらいの場合は単純にプログラムに対するHeapが足りない場合もあるため、まずはHeapを増やして(-Xms/-Xmx)

再現するかどうかの検証をすることが有効です。

– Heapが大きいとHeap Dump等を解析する時に問題が顕在化し、調査が行いやすくなります。逆に大きすぎると解析しづらいので、ほどほどに…

– Heapを大きくするとOOMEが発生するまで時間が延びます。原因不明ならばHeapを大きくして毎日再起動等での対処もありといえばありです。(あまり推奨したくないですが。)

– 32bit JavaVMを使用している場合は2G制限を考慮し、Heap

は1.5Gまでとりあえず上げてみてください。64bitならばOSの空き物理メモリ量と相談しましょう。

27



• メモリリークが起きている可能性がある場合…

– Oracle JRockit Mission Controlを使用している場合はMemory Leak Detectorを使用することで解析可能です。しかも高機能です。(ただし、ライセンスは有料)

– Heap Histogramはコマンドで表示できます(※FYI)が、見るのにコツがいります。

– jhatはJavaVMにデフォルトでついているtoolです。しかし、jhat

を見てもどこが問題かを特定することは慣れていなければ難しいです。

↓

– OOME時のHeap Dumpを取得し、自分でMATを使ってちょっと見るのが無料で簡単にできます！(かもしれません)

28


Heap Dumpの取得方法

• Heap Dumpの取得はいろいろな方法があります。

• OOME発生後に取得してもあまり意味がありません。発生前に取得するか、オプションを使いましょう。

• 比較するためには通常時とOOME発生時で取得することも必要です。

– OOME時にHeap Dumpを出力するオプションを使用します。

29

JavaVM オプション

HotSpot -XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=[HEAP_DUMP_PATH]

JRockit -XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=[HEAP_DUMP_DIR_PATH]


HeapDumpの取得方法

• Heap Dumpの取得はいろいろな方法があります。

– 動作中のHeap Dumpを取得することも可能です。

– とりあえずは上記を覚えておけば問題ありません。

30

JavaVM コマンド

HotSpot jps -mlv でJavaVMのプロセスIDを確認し、

jmap -dump:format=b,file=[FILE_NAME] [JVM_PID]

JDK5.0以降にjmapはありますが、Windows版のJDK5.0ではjmapは提供されておりません。

JDK6.0以降は全てのプラットフォームで提供されております。

JRockit jps -mlv でJavaVMのプロセスIDを確認し、

jrcmd [JVM_PID] hprofdump filename=[FILE_NAME]


MATのインストール

31



• Standalone版とEclipseのplugin版がありますが、今回はStandalone版を使います。

32



• 後はダウンロード先を選んでDLします。

33



• 解凍したMemoryAnalyzer.exeを実行します。

34


MATの使用

• 起動後、File -> Open Heap Dump… を行います。

35


MATの使用

• ファイルが表示されない場合は All Files を選択します。

36


MATの使用

• この画面ではそのまま[Finish]を押下します。

37


MATの使用

• 読み込みが終わると、Leak Suspects Reportの画面になります。

38


MATの見方

• Leak Suspects Reportの画面にて Problem Suspect の詳細を確認します。

39


MATの見方

• Detailを確認すると具体的な内容等が分かります。

40


MATの見方

• MemorySessionContextとあるため、セッションにデータが多く格納されていることが分かります。

41


MATの見方

• Heap Histogramを確認することも可能です。

42


MATの見方

43

• dominator treeを確認することも可能です。


MATの見方

44

• Heapの量により、分かりやすさが変わります。


MATの見方

• Leak Suspectsは必ずしも正解が出てくるとは限りませんが、有効なツールです。

• 詳細に確認する場合はHeapの差分比較を行い、どのオブジェクトが増え、増えたオブジェクトがどれだけのメモリを使用しているかを確認します。

45


MATの見方

• Heapの差分比較を行う場合

– 事前に通常時とOOME時のHeap Dumpを取得します。

– MATに両方のHeap Dumpを読み込ませます。

46


MATの見方


– OOME時のHeap Histogramを表示します。

47


MATの見方


– 右端にある[Compare to another Heap Dump]を押下します。

48


MATの見方


– どのHeap Dumpと比較するかを選択し、[OK]を押下します。

– 今回の場合は通常時を選択します。

49


MATの見方


– 差分でどのオブジェクトが増えて、メモリを消費しているかがわかります。

50


MATを使うときのポイント

• Heapが大きい方が問題が分かりやすくなります。

– 前頁での円グラフでの割合が大きくなるため、見やすい。

– また、Leak Suspectが正常に働く可能性が高い。

– 大きすぎると解析にメモリが必要になり、時間もかかるので、ほどほどに…

• MAT自体がメモリ不足になった場合は、同フォルダにあるMemoryAnalyzer.ini にてメモリ設定を可能です。

– -Xmx1024mがデフォルト(Windows_64bit_standalone版)

51


個人的所感

• WebLogicのJavaVMのメモリに関するデフォルト設定値よりも小さい値での運用は行わない方が無難です。

– OOMEの頻度があがります…

• GCの方式の変更に過度の期待をしないようにしましょう。

– JavaVMのバージョンアップの方が早くなる可能性もあります。

• HeapやPermの容量を変更する場合は初期値と最大値を同じにしましょう。

52


個人的所感

• 32bit JavaVMを使用する場合はHeapの容量は最大でも1.5Gに抑えましょう。

– それより大きく設定したい場合はOracle Coherenceを使用するか、インスタンスを分けましょう。

• 64bit JavaVMを使用する場合はHeapを大きく設定できますが、必ず物理メモリ範囲に抑えましょう。

– Heapが大きくなれば、GCにかかる時間も増えます。

– 状況により、 Oracle Coherenceを使用するか、インスタンスを分けましょう。

53


結び

御清聴ありがとうございました。

構築中やOOMEが出たときに

御確認いただけますと幸いです。

54


FYI

• OOME時に強制的に停止させる場合

– このオプションだけでは停止したままとなります。起動にはノードマネージャ等で再起動の設定が別途必要です。

55

JavaVM オプション

HotSpot -XX:OnOutOfMemoryError="kill -9 %p” (UNIX)

-XX:OnOutOfMemoryError="taskkill /F /PID %p“ (Windows)

JDK1.4.2 update 12以降や6以降で使用が可能です。

5では使用できません。

JRockit -XX:+ExitOnOutOfMemoryError

R28.1以降であれば、-XX:+CrashOnOutOfMemoryError を追加することができます。


FYI

• Heap Histogram の取得方法

56

JavaVM コマンド

HotSpot jps -mlv でJavaVMのプロセスIDを確認し、

jmap -histo [JVM_PID]

JDK5.0以降にjmapはありますが、Windows版のJDK5.0ではjmapは提供されておりません。

JDK6.0以降は全てのプラットフォームで提供されております。

JRockit jps -mlv でJavaVMのプロセスIDを確認し、

jrcmd [JVM_PID] print_object_summary [increaseonly=true]


リンク集

• Java HotSpot VM Options

– http://www.oracle.com/technetwork/java/javase/tech/vmopti

ons-jsp-140102.html

• JRockit コマンドラインリファレンス

– http://docs.oracle.com/cd/E15289_01/doc.40/e15062/toc.ht

m

57

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html







http://docs.oracle.com/cd/E15289_01/doc.40/e15062/toc.htm

http://docs.oracle.com/cd/E15289_01/doc.40/e15062/toc.htm


リンク集

• Memory Analyzer (MAT)

– https://www.eclipse.org/mat/

• Oracle JRockit Mission Control

– http://www.oracle.com/technetwork/jp/middleware/jrockit/mi

ssion-control/index.html?ssSourceSiteId=ocomjp

• jhat

– http://docs.oracle.com/javase/jp/7/technotes/tools/share/jhat

.html

58

https://www.eclipse.org/mat/

https://www.eclipse.org/mat/

http://www.oracle.com/technetwork/jp/middleware/jrockit/mission-control/index.html?ssSourceSiteId=ocomjp





http://docs.oracle.com/javase/jp/7/technotes/tools/share/jhat.html

http://docs.oracle.com/javase/jp/7/technotes/tools/share/jhat.html


リンク集

• jmap

– http://docs.oracle.com/javase/7/docs/technotes/tools/share/j

map.html

• jrcmd

– http://otndnld.oracle.co.jp/document/products/jrockit/geninfo

/diagnos/ctrlbreakhndlr.html#wp1001718

• hprofdump

– http://docs.oracle.com/cd/E22646_01/doc.40/b61441/diagn

ostic.htm#BABIACCC

59

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html

http://otndnld.oracle.co.jp/document/products/jrockit/geninfo/diagnos/ctrlbreakhndlr.html

http://otndnld.oracle.co.jp/document/products/jrockit/geninfo/diagnos/ctrlbreakhndlr.html

http://docs.oracle.com/cd/E22646_01/doc.40/b61441/diagnostic.htm




Copyright (c)2014 ITOCHU Techno-Solutions Corporation 60

OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方

Technology