看周邊搞的 java 夥伴,普遍反映 java 專案太吃記憶體,動不動要重啟服務,不知道對於吃記憶體以及記憶體洩露大家有沒有處理方式
Total: 25
-
記憶體不夠加記憶體,實在不行優化程式碼
記憶體洩漏的話 用 MAT ( MemoryAnalyzerTool ) 分析下,看下哪裡出問題了 -
應用吃記憶體跟 OOM 不是一個事情
-
@pjntt 哈哈哈,OOM 和 吃記憶體、記憶體洩漏都不是一個事情
-
建議先用 JVM 監控工具分析下佔用記憶體多的都是些什麼物件,如果發現是業務相關的,就很好優化了,改改程式碼,複用物件或者讓物件早點被 young gc 就能省大把記憶體。
-
很多常用的框架沒有太考慮記憶體使用,但這個和動不動就要重啟是兩回事。你這個明顯是實現的問題,就不要怪語言了。
-
這跟記憶體洩露一點關係都沒有。Java 吃記憶體是因為它使用虛擬機器進行記憶體的管理和回收。不像 c++和 objective-c 使用完就主動釋放,java 是虛擬機器會定期進行記憶體的回收,在記憶體沒有回收之前就會一直佔用。這就是為什麼 ios 需要的記憶體比安卓少的原因。
-
1. 普遍反映 java 專案太吃記憶體
不設定引數預設最大堆是 1/4 系統記憶體,加上除了堆的部分吃掉 1/3 不是問題
不過確實吃得多,手裡的專案啟動起來後設資料區就直奔 100m,對於配置低記憶體小的機器並不友好
2. 動不動要重啟服務
為啥要重啟服務呢?
3. 不知道對於吃記憶體以及記憶體洩露大家有沒有處理方式
吃記憶體:就讓它吃,設定引數限制它吃
記憶體洩漏:加引數打 dump,或者直接 jmap 拿 dump,然後分析 dump 定位洩露點修好就行了 -
對 java 有誤解,幹這麼多年沒見過要動不動重啟服務的應用更別說因為記憶體不夠去重啟服務的。
-
誰家動不動重啟服務解決記憶體問題?
基礎知識不過關啊. -
只要還能用,你管他記憶體佔用多少
-
記憶體洩露是指,某個物件沒用使用,沒有釋放記憶體,且隨著系統執行時間增長,該物件消耗記憶體持續增長,最終引起系統崩潰。
如果某個物件沒有使用,但是該物件使用的記憶體恆定。那麼這個物件只是個普通的物件。
btw 我這面給你解決記憶體洩露的話先遠離你周邊的小夥伴,結交一些懂技術的就可以了 -
我司某個 Java 專案啟動引數就 100G 記憶體。。。。。
-
記憶體洩漏難道不是 bug 嗎……是 Bug 就修啊……
-
我的 android studio 用著用著,電腦的風扇實然 瘋,狂,咆,哮, 開啟個任務管理一看 java.exe 吃了一 G 記憶體, 大哥,我就用個編輯器而已,吸效能用不用吸得這麼猛
-
有病就治,跳大神沒用的
-
@kingfalse #12 來一次 GC 這不起飛
-
@fxjson 讓程式跑很長一段時間,記憶體佔用大了之後,jmap dump 出來 jvm 的記憶體使用,eclipse 有個 MAT 工具,會簡單地自動分析下記憶體洩漏的原因。
然後,在 MAT 裡找到記憶體消耗比較大的而且是可達( Reachable,不可達的有 unReachable 標記)的類,在 MAT 裡的物件上,滑鼠右鍵 GC Path,看看引用路徑。就大概知道了。 -
記憶體洩漏可以分析。
記憶體不夠可以加記憶體。
啊?嫌記憶體用得多?旁邊有用記憶體少的語言和執行環境,歡迎重寫。 -
Java 一方面的確記憶體佔用較大,尤其是用了一堆重形框架後。
另一方面 jvm 有個問題是很不喜歡把用過的記憶體還給作業系統。 -
openj9 的 jvm 記憶體佔用會小很多,但是目前版本號依然沒到 1.0.0 。非生產環境可以用用
-
洩露,靠自己就行。吃不夠,就加點
-
記憶體洩漏你用 C++不是更爆炸
-
回到正題,最起碼的啟動就加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/kar 這倆引數引數,起碼蹦的時候還能挖挖墳看看到底是誰的墓( bug )
-
dump 下來用 mat 看下就知道哪裡洩露了,執行緒就用 jstack 看
-
哦豁,我新入坑 java,一個專案就是用 java 寫的,現在上線了,還沒使用者的,關鍵是我 java 新手,還不知道咋解決這個問題。go 是不是要好些,不用擔心這些,直接寫業務就行了?早知道該選 go 寫的。
Add a reply