最佳的解決方案
我們先給大家說一種最佳的OOM監控方案，其實說白了也很簡單，之前一直給大家強調，公司最好是應該有一種監控平台，比如Zabbix、Open-Falcon之類的監控平台。
如果有監控平台的話，就可以接入系統異常的一些監控和報警，你可以設置一旦系統出現了OOM異常，就發送報警給對應的開發人員，通過郵件、短信或者釘釘之類的IM工具。
這個是中大型公司里最常用的一種方案了，一般來說我們都對線上系統有以下幾個層面的監控：
機器（CPU、磁盤、內存、網絡）資源的負載情況，JVM的GC頻率和內存使用率，系統自身的業務指標，系統的異常報錯。
這些東西都會基於監控平台接入對應的監控項，同時設定關鍵監控項的一些報警閾值。
下面我來分層給大家解釋一下這個所謂的監控體系的思路，我們這個專欄雖然不是專門教大家做監控的，但是因為說到了系統的JVM監控，因此可以順帶給大家說一下思路，大家再結合自己公司的監控系統去考慮一下怎么做。
一個比較成熟的系統監控體系的建議
首先通過監控平台是可以看到你的所有線上系統所在的機器資源的負載情況的，比如CPU負載，這個可以看到現在你的CPU目前的使用率有多高，比如你的CPU使用率都達到100%了，此時一定有問題了，你得檢查一下為什么CPU負載那么高。
而且可以看到你的機器上磁盤IO的一些負載，包括磁盤上發生了多少數據量的IO，一些IO的耗時等等。
當然一般的業務系統本身不會直接讀寫自己本地的磁盤IO，最多就是寫一些本地日志而已。
但是你應該關注的是你本地磁盤的使用量和剩余空間，因為有的系統因為一些代碼bug，可能會一直往本地磁盤寫東西，萬一把你的磁盤空間寫滿了就麻煩了，這樣也會導致你的系統無法運行。
其次可以看到你機器上的內存使用量，這個是從機器整體層面去看的，看看機器對內存使用的一些變化。
當然內存這塊，比較核心的還是JVM這塊的監控，我們是可以看到JVM各個內存區域的使用量的一個變化的。
最后就是機器上的網絡負載，就是通過網絡IO讀寫了多少數據，一些耗時，等等。
還有一個比較關鍵的，就是JVM的Full GC的頻率，這個一般會用一段時間內的Full GC次數來監控，比如5分鍾內發生了幾次Full GC。
其實線上機器最容易出問題的主要三大塊，一個是CPU，必須要對CPU的使用率做一個監控，如果CPU負載過高，比如長期使用率超過90%，就得報警了；
一個是內存，同樣得監控內存的使用率，如果機器內存長期使用率超過了一定的閾值，比如長期使用率超過90%，那肯定是有問題的，隨時機器內存可能就不夠了；
一個是JVM的Full GC問題，假設5分鍾內發生了10次Full GC，那一定是頻繁Full GC了。
所以建議大家去看看自己公司是否有監控平台，同時是否建立起來基本的監控體系， 對CPU、內存、Full GC等核心問題進行了監控和自動報警。
另外比較常見的就是對系統的業務指標的監控，比如你可以在每次系統創建一個訂單就上報一次監控，然后監控系統會收集你1分鍾內的訂單數量。然后你可以設定一個閾值，比如1分鍾內要是訂單數量超過了100就報警。
因為可能訂單過多涉及到了一些刷單之類的行為，這就是業務系統的指標監控，這個都是你自己去進行指標上報的。
最后一個，就是系統所有的try catch中的異常報錯，必須要接入報警，一旦有異常，都需要上報到監控平台，然后監控平台會告訴你，最近有一次異常，只要系統報錯，你立馬可以收到報警。
因此非常核心的一點，就是要對線上系統的異常進行監控，一旦JVM有OOM之類的問題可以立馬感知到。
一種比較Low的JVM OOM問題的被動發現方法
如果大家實在沒有上述那種監控和報警的體系，那就沒辦法主動感知到JVM OOM問題了，此時只能用最Low的土辦法就發現OOM了。
被動發現OOM問題，主要靠兩個：
第一個是線上系統假設因為OOM突然掛掉，此時一定會導致用戶無法使用，然后迅速反饋到客服，客服反饋給你，你就知道自己的系統掛掉了。
第二個就是你必須去檢查一下系統的線上日志，一般來說，系統有異常的時候，必須通過log4j之類的日志框架寫入本地日志文件，如果這個都不做，那實在是沒辦法說什么了。只要你檢查日志，就會發現之前給大家演示過的OOM問題。
今天給大家總結了一下
一種是通過監控系統，一種是被動等待系統掛掉后客服來通知你