jvm問題，一般會有三種情況，目前遇到了兩種，執行緒溢位和jvm不夠用
系統在1月4號左右，突然發現會產生記憶體溢位問題，從日誌上看，錯誤資訊為：
導致系統不能使用，對外不能相應，但是觀察gc等又處於正常情況，free 系統記憶體也正常。開始重啟機器進行解決，真正的原因查詢，過程比較坎坷，經歷也比較痛苦。
命令：pstree -p pid (對該項已經加了監控)
我們實現了threadfactory，通過它，給執行緒的加乙個字首。來標記執行緒所屬。重現問題後，發現是task模組的taskscheduler的定時任務中，在方法內使用
executorservice taskexecutor = executors.newfixedthreadpool(nthreads);
taskexecutor.invokeall(tasks);
導致**不及時，發生了問題。
1月31號，中午中影突然所有的機器陸續出現不能工作的現象，日誌中看不到oom錯誤，但是不能訪問服務，或者訪問非常的慢，觀察jmap -heap發現老生代占用達到99%以上（不同版本jdk顯示可能不一樣。）
1、檢視對記憶體使用情況，發現存在jvm堆記憶體不能釋放的問題
命令：jmap -heap pid 此命令有時候，會執行卡頓，不建議加監控
語法：jmap - heap pid
2、進一步檢視gc**情況，發現fgc頻率高，而且時間長，且**不給力。
命令：jstat -gcutil pid
語法：jstat [ generaloption | outputoptions vmid [interval[s|ms] [count]] ]
3、檢視jvm堆中具體有哪些物件。發現不正常，byte陣列占用過大。例項達到1億兩千萬，大小竟然有4g(3958m).同時，訂單、hibernate引擎、mysql結果集類例項都很多。
命令：jmap -histo
語法：jmap -histo[:live] pid
見附件4、檢視mysql慢查詢，發現確實找達到問題原因。
命令1:mysql資料庫上檢視，所有的。
命令2：檢視當前慢查詢
select * from information_schema.`processlist` ;(簡化版：show processlist)
java記憶體洩漏
記憶體洩露 memory leak，是指程式在申請記憶體後，無法釋放已申請的記憶體空間，一次記憶體洩露危害可以忽略，但記憶體洩露堆積後果很嚴重，無論多少記憶體,遲早會被占光。memory leak會最終會導致out of memory！以發生的方式來分類，記憶體洩漏可以分為4類 常發性記憶體洩漏。發...
java記憶體洩漏
一 長時間存活物件引用了短生命週期物件 使用了單例模式 private context context this.context context if instance null return instance 這樣不管傳入什麼context最終將使用第一次傳入的context，而單例的生命週期和應...
避免Java記憶體洩漏的方法
1 靜態集合類像hashmap vector等的使用最容易出現記憶體洩露，這些靜態變數的生命週期和應用程式一致，所有的物件object也不能被釋放，因為他們也將一直被vector等應用著。2 大量臨時變數的使用，沒有及時將物件設定為null也可能導致記憶體的洩露 3 資料庫的連線沒有關閉情況，包括連...