メモリのJVM深刻な不足は、java.lang.OutOfMemoryErrorエラーをスローした場合。下記に示すように、この論文では、一般的な原因と解決策OOMをまとめました。いずれかが欠けていたり間違っている場合は、補正を追加してください。
1、Javaヒープスペース
ヒープ（ヒープスペース）は、新しく作成されたオブジェクトを格納するのに十分なスペースがない場合はスローされますjava.lang.OutOfMemoryError:Javaheap spaceエラーを（実際の生産の経験をもとに、あなたはプログラムのキーワードアラート・ログのOutOfMemoryErrorを設定することができ、発見された後、すぐに対処）。
原因分析
Javaheap space 発生したエラーの一般的な原因は、次のカテゴリに分けることができます。
1、ラージオブジェクト、通常、大きなアレイを作成するための要求。
尖ったピークが存在する場合に予想されるよりも、データトラフィックの2 /量は、通常、上流のシステム要求トラフィックがプロモーション/スパイク活動のすべてのタイプに、一般的に急増し、トラフィックメトリック調査と組み合わせることができます。
図3は、ターミネーターの過度の使用（ファイナライザ）、オブジェクトは直ちにGCではありません。
図4は、メモリリーク（メモリリーク）、オブジェクト参照の多数が解除されないが、JVMは自動的に回収しないファイルやその他のリソースを使用するために、その一般的に回復することはできません。
ソリューション
ほとんどの部分については、通常は必要な-XmxJVMのヒープメモリパラメータを増加します。それでも解決しない場合は、さらに処理するために、以下を参照することができます：
オブジェクトが大きい場合に1、あなたは、このようなすべての結果のデータベースワンタイムクエリかどうかと、その正当性を確認することができますが、結果の数を制限するものではありません。
図2は、ビジネスがピーク圧力であれば、マシンのリソースを追加する制限またはダウングレードを行うことを検討してください。
3、それはメモリリークであれば、あなたがオブジェクトを見つける必要があるような接続が解除されていないクローズなど、コードの設計を変更し、保持しています。
2、GCオーバーヘッド制限を超え
Javaプロセスは、GCを実行するために時間の98％以上を要するが、唯一のメモリの2％未満を回収し、そして行動が一列に5回繰り返され、それがスローされたときにjava.lang.OutOfMemoryError:GC overhead limit exceededエラーが。簡単に言えば、あること、アプリケーションは基本的にすべての利用可能なメモリを使い果たしてきた、GCを回復することはできません。
このような問題と解決策の原因Javaheap spaceあなたは上記を参照することができ非常に類似し、。
3、Permgenスペース
このエラーは、クラスの数が多すぎるか、ボリュームの負荷が大きすぎる通常ので、永久世代（Permanent世代）は、フルを有することを示します。
原因分析
メインターゲットの代わりに永続的なストレージには、次のカテゴリが含まれます。
クラス、フィールド、メソッド及びバイトコードの名前を含むクラス定義、1、ロード/キャッシュメモリ。
図2に示すように、定数プール。
図3に示すように、オブジェクト/クラス型配列のアレイに関連します。
4、JITコンパイラの最適化後のクラス情報。
PermGenの量及び数は、クラス/正の相関の大きさのメモリにロードされます。
ソリューション
次のように時間を与えPermgen空間は、異なる溶液を使用することができます。
1、プログラムがエラーを開始し、修正する-XX:MaxPermSize永久譲渡大きなスペースを代表して、起動パラメータを。
図2に示すように、アプリケーションエラーを再デプロイ、それがロードされている複数のクラスになり、再起動しない全く適用しない可能性がある、単にJVMを解決することができる再起動します。
3、実行時エラーは、アプリケーションが動的にクラスの多くを作成することができ、これらのクラスのライフサイクルは非常に短いですが、デフォルトのJVMクラスアンインストールし、あなたが設定することができていない-XX:+CMSClassUnloadingEnabledと、-XX:+UseConcMarkSweepGCこれら2つのパラメータは、アンインストールクラスにJVMを可能にします。
これは、メモリオブジェクトによってjmapはdumpコマンドを解決しない場合はjmap-dump:format=b,file=dump.hprof<process-id>、その後、1つずつのEclipse MATのhttps://www.eclipse.org/mat機能を使用して最も高価なクラスローダクラスの繰り返しを分析しました。
4、メタスペース
誤差を表す（Permanent世代）を代入永久交換メタスペースを使用してJDK 1.8は、通常、クラスローディングの数が多すぎる、または大きすぎる体積ため、メタスペースが一杯に使用されてきました。
原因として、これらの問題の解決Permgenspaceに非常に似て、あなたは上記を参照することができます。特に注目すべきなのはメタスペーススペースがある起動パラメータを調整することです-XX:MaxMetaspaceSize。
新しいネイティブスレッドを作成できません5、
基礎となるオペレーティングシステムにJVM要求は新しいネイティブスレッドを作成する際に、いくつかのメモリ空間を占有するために、各Javaスレッドのニーズは、不十分な資源配分がある場合は、このようなエラーを報告します。
原因分析
スレッドが失敗したネイティブOSを作成するためのJVM要求、スローUnableto createnewnativethread、一般的な原因は、次のカテゴリに分類されます
図1に示すように、スレッドの数は、システムのulimit制限を操作するスレッドの最大数を超えています。
図2に示すように、スレッドの数kernel.pid_maxより（再起動のみ）。
図3は、ネイティブメモリ不足します。
この共通の問題は、プロセスは以下のステップを含む発生します。
1、新しいJavaスレッドを作成するために、JVMアプリケーション要求の内部;
2、JVMネイティブプロキシ前記第2の要求とネイティブ・オペレーティング・システム・スレッドを作成するための要求。
図3に示すように、オペレーティングシステムは、新しいネイティブスレッド、および割り当てメモリを作成しよう。
オペレーティングシステムの仮想メモリを使い果たす、または32ビットプロセスのアドレス空間の制限を受けている場合4、オペレーティング・システムは、このネイティブメモリ割り当てを拒否します。
5、JVMがスローされますjava.lang.OutOfMemoryError:Unableto createnewnativethreadエラーを。
ソリューション
1、マシンのより多くのメモリを提供し、構成をアップグレード。
2、Javaヒープスペースのサイズを縮小します。
3、アプリケーションスレッドの漏れを修復します。
図4に示すように、スレッドプールのサイズ制限。
図5に示すように、スレッドのスタックサイズの減少-Xssパラメータを使用して、
実装：6は、OSレベルのスレッドの最大数を増やすulimia-a使用するスレッドの最大数のビューの制限をulimit-u xxxスレッド限界の最大数を調整します。
パートは、ulimitのが-A .... .....最大ユーザ・プロセス（-u）16384を省略しました
どのような問題あなたはそれに遭遇しましたか？あなたは、問題の解決策が何をするか、である持っていますか？ウェルカムメッセージが交換を示しています。