[問題] VistualVM能否找出哪一個method吃掉記憶

[comodore (Commodore)]

目前系統執行大量資料進行測試時

跑到一半便會出現out of memory的問題

之前試過使用Vistual JVM去找出最花時間的method是哪個

來降低執行速度太慢的問題,

現在遇到另一個記憶體空間不足的問題,

但似乎Vistual JVM沒有辦法顯示是哪一個method一直在爆量增加記憶體,

還是找吃掉記憶體元凶通常不是這樣看呢?

或者是要用其他工具才有辦法看到更詳細的分析結果呢?

麻煩大家
謝謝

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.110.208
※ 文章網址: https://www.ptt.cc/bbs/java/M.1498040703.A.1EF.html
→ Lordaeron: 花錢請人找問題吧, 想學一下就會, 很多人早升天了.
推 loser5566: Heap dump?
→ Lordaeron: heap dump不會告訴你哪個METHOD吃RESOURCE的.
→ Chikei: VisualVM -> Profiler -> Settings -> Memory settings ->
→ Chikei: Record allocations stack traces -> start profiling ->
→ Chikei: Take Snapshot -> 右鍵 -> Show Alloc. Stack Traces
→ comodore: failed to obtain results snapshot
→ comodore: the profiled application terminated
→ Lordaeron: 程式可能重寫比你這麼找半天來得快囉.
→ cowbaying: 是可以看哪個物件吃了最多記憶體
→ cowbaying: 找method除非是程式在寫的時候就有寫監視功能進去
→ cowbaying: 不然沒辦法知道是哪個METHOD
→ WildCherry: jrockit?
→ Lordaeron: 一堆沒做過的人,提了一堆工具,認為就可以有答案了.
推 gmoz: 沒這麼簡單阿~~
→ cowbaying: 我說的是用jstat
→ cowbaying: 但是有沒有符合原PO的需求就不曉得了
→ cowbaying: jstat可以看到哪個物件生成數最多  占多少記憶體
→ cowbaying: 應該是說變數啦
推 csieflyman: code review + 逐漸縮小範圍測試
推 csieflyman: 你運氣算好的 可以透過測試重現OOM問題
→ ssccg: 能歸在method吃掉的記憶體只有local variable吧
→ ssccg: 其他的物件就在heap上啊