入門
七夕祭りの際には、オファーの無数の姉妹紙をあきらめた、コンピュータコードワードの前に座って、読者に新しい知識をもたらすことです、これが大きな原因です！
まあ、現実には、およそその誰もありません。恥ずかしを解決するために、私はああ、私はあまりにも巨根ワイヤーでなければならない、ハード記事を書くことにしました！
まあ、焦点は言うようになりました。今日、私たちはこの問題について話しています
JAVAプロセスは、理由は何ですか消えること？
以下に示すように、この問題は、またしばしば現れるインタビューです
インタビュアー：プロセスはJAVAを終了することがありますか？
PS：二年以上以来の使用方法をMyBatisの、上記の問題ように、私は無視することを選択したCRUDを書くので、忘れてはいけませんでした。
その後、我々はこの質問は実際には非常に簡単で、3例にほかなら記事を開きます。
LinuxのOOMキラーが殺さ
JVM自身の障害
OOMプロセスが終了したJVMを（非常にまれな、私はまだ会ったことがない）
はじめに
LinuxのOOMキラー
LinuxカーネルがOOMキラー（メモリ不足キラー）と呼ばれる機構を有し、このメカニズムは、特に瞬間に、あまりにも多くのメモリを取る人たちはすぐにメモリ不足を防止するために、メモリのプロセスを大量に消費し、カーネルがプロセスを殺す監視しますアウト。
だから、あなたはjavaプロセスが突然なくなっていることを見つけ、それを取り除くために、LinuxのOOMキラーではない疑いが初めてでした！
あなたは、次の文書翻訳に行くことができます
システム・エラー・ログ：は/ var / log / messagesに
あなたは、コマンドを実行します
egrepの-i "殺さプロセスのの/ var / log / messagesに
検索するには、ログインしてください。
もちろん、あなたはまた、カーネルログクエリ内で行くことができます。システムまたはJavaまたは他のプロセスで実行されている時には、Linuxシステムでは、いくつかの奇妙な問題が発生し、突然、このような突然の再起動時などのように、ハングアップなど。ソフトウェアでの問題を見つけることができませんし、我々は、我々が見ることのdmesgを使用することができ、問題がハードウェアまたはカーネルで疑う必要があります。
dmesgの| グレップのJava
出力は以下の
【5673702.665338】メモリ不足：（Java）の431または犠牲子スコアプロセス29953を殺す
9805316kB、アノン-RSS：2344496kB、ファイル、RSS：128kBの、[5673702.665338]殺したプロセス29953 UID 500、（Java）の全VMの
これらはすべて、カーネルの動作について進捗状況を見ることができます。
JVM自身の障害
JVMエラーが致命的なクラッシュを引き起こすことが発生した場合、原因のJVMがクラッシュに関する重要な情報が含まれ、このファイル、hs_err_pid_xxx.logを生成します、我々は、システムの安定性を確保するために修復するJVMクラッシュの原因を突き止めるために、ファイルを分析することができます。
デフォルトでは、このファイルはもちろん、パスのJVMパラメータで指定することができ、作業ディレクトリに生成されます。
-XX：ERRORFILE =は/ var / log / hs_err_pid <PID> .logに
このファイルの主な内容は、次のような内容を持っています
ヘッダログ
クラッシュスレッド情報につながったが
、情報のすべてのスレッドのための
セキュリティロック情報ポイントと
ヒープ情報は、
ローカルコードキャッシュ
コンパイラのイベント
GCレコードは
メモリマッピングJVM
JVM起動パラメータ
サーバーの情報を
このファイルを取得した後、ゆっくりとそれを食べることは言うまでもないです。ここで、私は感情の良心にしたいと彼は言いました。あなたが何かをして、このファイルを読み込みます場合は、このファイルには、巨大な複雑です。
JVMのOOM
率直に言って、私はめったに終了するJavaプロセスで、その結果、JVM OOMので、状況に遭遇しません。
一般的に、OOM異常は、JVMのGCが回収されます表示され、ので、それはJVMプロセスが終了することはありません。実際には状況が終了してしまうと、メモリフットプリントが成長しているので、それは、メモリリークで、結果を言うために。。。。
しかし、この異常は、JVM OOM良い調査によって引き起こされます。
、あなたは、2つのパラメータに注意を払うので
-XX：+ HeapDumpOnOutOfMemoryError
-XX：HeapDumpPath = * / java.hprof;
その後、ダンプ・スナップショット・ファイルを検索し、対応するディレクトリに移動し、これはライン上のVisualVMの解析可視化ツールを意味します。問題を見つけることは容易です。
概要
要約すると、正解はい。まず、ファイルのダンプをオンにしない場合は、ダンプ、hs_err_pid.logログをオンにします。ない場合は、カーネルのログをオンにします。