1、問題描述
這兩天公司專案的專案進行測試，
伺服器會偶爾出現訪問不通，ejb遠端呼叫全部失效的情況，經過對jvm監控，發現是jvm記憶體fullgc造成系統停頓造成的。目前基礎系統jboss啟動jvm記憶體設定為3g，之前出現過out of memory heap 的錯誤。現在正常開發情況下，基礎系統平均一兩天就會因為記憶體爆滿，出現系統停頓，不得不重啟jboss來解決。
一開始一直認為ejb不穩定，一般個別介面遠端呼叫不通，經過檢視系統日誌發現有oom的異常。
jconsole：jdk自帶的jvm簡單監控工具，直接cmd—jconsole即可使用
jvisualvm：jconsole高階版本，比jconsole資訊詳細些，cmd-jvisualvm即可使用
jprofiler：效能監控工具，可以同步檢測程式執行過程中jvm的各個引數，類，執行緒的實時情況。同時也可以分析dump。
eclipesememory analyzer：多用於離線分析dump日誌，可以給出記憶體溢位的建議，工具具體使用較為專業，需要對jvm內部結構了解。
監測情況如圖：
主要是老年代記憶體不足，及fullgc造成的。
名詞介紹：
新生代：主要用來存放新生的物件，物件更新速度快，短時間內產生大量的「死亡物件」
引起記憶體溢位的原因可能是：
1、jvm引數使用預設的不能夠滿足我們的需要，需要根據我們系統的需要對新生代和老年代進行記憶體分配。
2、大量使用本地快取（如大量使用hashmap作為k/v快取）的應用，在邏輯集群造成即到達的記憶體浪費，因為每個邏輯節點上都有乙份快取。
這時候可以考慮把本地快取改為集中式快取。·
3、不恰當的資料結構導致記憶體占用過大（例如：hashmap結構中來儲存資料檔案空間效率太低）
總結：通過修改jvm的引數，系統改善不是很明顯，只能延緩，不能從根本上解決問題。最根本的著手點還是我們的**，可以考慮和**走查的相關負責人配合。優化我們的**，比如：優化map是很有必要的，**中是否存在不合理的for迴圈或者是遞迴呼叫，由於循產生過多重複的物件實體，或者是list、map等集合物件是否有使用完後，未清除的問題，導致不能被gc**。
最終的原因還是由於自己**中使用多租戶+級聯導致不能**，問題的原因知道，但是不清楚為什麼他倆放一起使用就不行了，該問題還在研究中。
JVM 發生native heap溢位問題
1 最近專案中出現jvm中native heap無法分配的問題，但是根據jvm產生的dump檔案來看，heap是夠用的，根據自己學些的jvm的知識和在網上查詢的一些資料，分析是jni這塊出現了問題。2 往jni方面分析，然後找到jvm崩潰的那個時間點的日誌，在那個時間點呼叫了很多的native方法，...
一次jvm記憶體溢位問題排查
首先看下問題原因 上圖的意思是獲取直接記憶體失敗，然後jvm建議減少堆的大小，或者減小每個執行緒的大小，或者增加系統記憶體 觀察下執行緒的狀態 目前總共產生了十三萬個執行緒池 編寫存在問題，一般情況下不會有這麼多執行緒池 且統計了一下，存在十三萬的執行緒都處於阻塞狀態 開始使用jstack l pi...
tensorflow記憶體溢位問題
tensorflow的靜態圖結構簡潔清晰，符合人的思維。雖然程式設計上略微有些複雜，但是原理很容易看懂。tensorflow分建圖過程和執行圖 張量求值 兩個階段，在這兩個階段中都可以定義操作和張量。但是有乙個非常容易犯的錯誤 把操作定義在迴圈裡面。例如下面這個例子，tf.assign操作放在了迴圈...