av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

給我1萬(wàn)字，也講Java不清內(nèi)存排查。1萬(wàn)不行來(lái)2萬(wàn)~.~

本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。

對(duì)于內(nèi)存問(wèn)題排查來(lái)說(shuō)，搞理論的痛苦，搞實(shí)踐的也痛苦，沒(méi)有一片清凈之地。

why?因?yàn)閮?nèi)存溢出是Java碼農(nóng)永遠(yuǎn)的傷。

溢出有很多種解釋，有精滿自溢，有緩沖區(qū)溢出攻擊，還有另外一種叫做領(lǐng)導(dǎo)的溢出。不知道什么叫作溢出理論，xjjdog在此普及一下。

《領(lǐng)導(dǎo)看了會(huì)炸毛的溢出理論》

內(nèi)存溢出什么最重要?其實(shí)，內(nèi)存溢出就像是一場(chǎng)交通事故。事故的發(fā)生方，就是具體的服務(wù);事故的處理方，就是相關(guān)的程序員。其中有一個(gè)最重要的環(huán)節(jié)，就是在事故現(xiàn)場(chǎng)需要拍照取證。

如果沒(méi)有照片沒(méi)有行車記錄儀沒(méi)有證據(jù)，就只能靠那張嘴，怎么說(shuō)都是不可信的。

**這句話很重要很重要：內(nèi)存問(wèn)題排查什么最重要?當(dāng)然是信息收集，留下一些為我們的排查提供支持的依據(jù)。**千萬(wàn)不要舍本逐末，對(duì)內(nèi)存問(wèn)題排查本身感興趣，那是自虐行為。

有很多工具可以幫助我們定位問(wèn)題，但前提是你得把它留下來(lái)。下面這篇文章是xjjdog很久之前留下來(lái)的，由于標(biāo)題的緣故，你可能忽略了，但這些工具能夠快速幫我們定位問(wèn)題。

 
 
 
 
    
  
  
  
  
  1. ss -antp > $DUMP_DIR/ss.dump 2>&1
    2. 
  
  
  
  
  2. netstat -s > $DUMP_DIR/netstat-s.dump 2>&1
    3. 
  
  
  
  
  3. top -Hp $PID -b -n 1 -c >  $DUMP_DIR/top-$PID.dump 2>&1
    4. 
  
  
  
  
  4. sar -n DEV 1 2 > $DUMP_DIR/sar-traffic.dump 2>&1
    5. 
  
  
  
  
  5. lsof -p $PID > $DUMP_DIR/lsof-$PID.dump
    6. 
  
  
  
  
  6. iostat -x > $DUMP_DIR/iostat.dump 2>&1
    7. 
  
  
  
  
  7. free -h > $DUMP_DIR/free.dump 2>&1
    8. 
  
  
  
  
  8. jstat -gcutil $PID > $DUMP_DIR/jstat-gcutil.dump 2>&1
    9. 
  
  
  
  
  9. jstack $PID > $DUMP_DIR/jstack.dump 2>&1
    10. 
  
  
  
  
  10. jmap -histo $PID > $DUMP_DIR/jmap-histo.dump 2>&1
    11. 
  
  
  
  
  11. jmap -dump:format=b,file=$DUMP_DIR/heap.bin $PID > /dev/null  2>&1
    12.

GC日志配置

但并不是每次出現(xiàn)故障，你都在機(jī)器的身邊。靠人工也不能保證實(shí)時(shí)性。所以，強(qiáng)烈建議你把GC日志輸出的詳細(xì)一些，那么出現(xiàn)問(wèn)題的時(shí)候就舒坦一些。

實(shí)際上，這個(gè)要求在我看來(lái)是強(qiáng)制的。

很多同學(xué)上來(lái)就說(shuō)，我的內(nèi)存溢出了。但你和它要一些日志信息，要堆棧，要現(xiàn)場(chǎng)保存的快照。都沒(méi)有。這就是純粹來(lái)搞笑的。

下面是JDK8或者以下的GC日志參數(shù)，可以看到還是很長(zhǎng)的。

 
 
 
 
    
  
  
  
  
  1. #!/bin/sh
    2. 
  
  
  
  
  2. LOG_DIR="/tmp/logs"
    3. 
  
  
  
  
  3. JAVA_OPT_LOG=" -verbose:gc"
    4. 
  
  
  
  
  4. JAVA_OPT_LOG="${JAVA_OPT_LOG} -XX:+PrintGCDetails"
    5. 
  
  
  
  
  5. JAVA_OPT_LOG="${JAVA_OPT_LOG} -XX:+PrintGCDateStamps"
    6. 
  
  
  
  
  6. JAVA_OPT_LOG="${JAVA_OPT_LOG} -XX:+PrintGCApplicationStoppedTime"
    7. 
  
  
  
  
  7. JAVA_OPT_LOG="${JAVA_OPT_LOG} -XX:+PrintTenuringDistribution"
    8. 
  
  
  
  
  8. JAVA_OPT_LOG="${JAVA_OPT_LOG} -Xloggc:${LOG_DIR}/gc_%p.log"
    9. 
  
  
  
  
  9. 
  
  
  
  
  10. JAVA_OPT_OOM=" -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOG_DIR} -XX:ErrorFile=${LOG_DIR}/hs_error_pid%p.log "
    11. 
  
  
  
  
  11. 
  
  
  
  
  12. JAVA_OPT="${JAVA_OPT_LOG} ${JAVA_OPT_OOM}"
    13. 
  
  
  
  
  13. JAVA_OPT="${JAVA_OPT} -XX:-OmitStackTraceInFastThrow"
    14.

下面是JDK9及其以上的日志配置。可以看到它的配置方式全變了，而且不向下兼容。Java搞的這個(gè)變化還是挺蛋疼的。

 
 
 
 
    
  
  
  
  
  1. #!/bin/sh
    2. 
  
  
  
  
  2. 
  
  
  
  
  3. LOG_DIR="/tmp/logs"
    4. 
  
  
  
  
  4. JAVA_OPT_LOG=" -verbose:gc"
    5. 
  
  
  
  
  5. JAVA_OPT_LOG="${JAVA_OPT_LOG} -Xlog:gc,gc+ref=debug,gc+heap=debug,gc+age=trace:file=${LOG_DIR}/gc_%p.log:tags,uptime,time,level"
    6. 
  
  
  
  
  6. JAVA_OPT_LOG="${JAVA_OPT_LOG} -Xlog:safepoint:file=${LOG_DIR}/safepoint_%p.log:tags,uptime,time,level"
    7. 
  
  
  
  
  7. 
  
  
  
  
  8. JAVA_OPT_OOM=" -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOG_DIR} -XX:ErrorFile=${LOG_DIR}/hs_error_pid%p.log "
    9. 
  
  
  
  
  9. 
  
  
  
  
  10. JAVA_OPT="${JAVA_OPT_LOG} ${JAVA_OPT_OOM}"
    11. 
  
  
  
  
  11. JAVA_OPT="${JAVA_OPT} -XX:-OmitStackTraceInFastThrow"
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. echo $JAVA_OPT
    14.

一旦發(fā)現(xiàn)了問(wèn)題，就可以拿GC日志來(lái)快速定位堆內(nèi)問(wèn)題。但是并不是讓你一行行去看，那太低效了。因?yàn)槿罩究赡軙?huì)很長(zhǎng)很長(zhǎng)，而且也不一定看得懂。這個(gè)時(shí)候，就可以使用一些在線工具輔助解決。我經(jīng)常使用的是gceasy，下面是它的一張截圖。

 
 
 
 
    
  
  
  
  
  1. http://gceasy.io
    2.

有了GC日志還不行，因?yàn)樗鼉H僅是記錄了堆空間的一些變化，至于操作系統(tǒng)的一些資源變動(dòng)，它是無(wú)從知曉的。所以，如果你有一個(gè)監(jiān)控系統(tǒng)的話，在尋找問(wèn)題的時(shí)候也能幫到忙。從下圖可以看到系統(tǒng)資源的一些變動(dòng)。

溢出示例

堆溢出

代碼。

日志。

 
 
 
 
    
  
  
  
  
  1. java -Xmx20m -Xmn4m -XX:+HeapDumpOnOutOfMemoryError - OOMTest
    2. 
  
  
  
  
  2. [18.386s][info][gc] GC(10) Concurrent Mark 5.435ms
    3. 
  
  
  
  
  3. [18.395s][info][gc] GC(12) Pause Full (Allocation Failure) 18M->18M(19M) 10.572ms
    4. 
  
  
  
  
  4. [18.400s][info][gc] GC(13) Pause Full (Allocation Failure) 18M->18M(19M) 5.348ms
    5. 
  
  
  
  
  5. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    6. 
  
  
  
  
  6.     at OldOOM.main(OldOOM.java:20)
    7.

jvisualvm的反應(yīng)。

元空間溢出

代碼。

日志。

 
 
 
 
    
  
  
  
  
  1. java -Xmx20m -Xmn4m -XX:+HeapDumpOnOutOfMemoryError -XX:MetaspaceSize=16M -XX:MaxMetaspaceSize=16M MetaspaceOOMTest
    2. 
  
  
  
  
  2. 6.556s][info][gc] GC(30) Concurrent Cycle 46.668ms
    3. 
  
  
  
  
  3. java.lang.OutOfMemoryError: Metaspace
    4. 
  
  
  
  
  4. Dumping heap to /tmp/logs/java_pid36723.hprof ..
    5.

jvisualvm的反應(yīng)。

直接內(nèi)存溢出

代碼。

日志。

 
 
 
 
    
  
  
  
  
  1. java -XX:MaxDirectMemorySize=10M -Xmx10M OffHeapOOMTest
    2. 
  
  
  
  
  2. Exception in thread "Thread-2" java.lang.OutOfMemoryError: Direct buffer memory
    3. 
  
  
  
  
  3.     at java.nio.Bits.reserveMemory(Bits.java:694)
    4. 
  
  
  
  
  4.     at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
    5. 
  
  
  
  
  5.     at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
    6. 
  
  
  
  
  6.     at OffHeapOOMTest.oom(OffHeapOOMTest.java:27)...
    7.

棧溢出

代碼。

日志。

 
 
 
 
    
  
  
  
  
  1. java -Xss128K StackOverflowTest
    2. 
  
  
  
  
  2. Exception in thread "main" java.lang.StackOverflowError
    3. 
  
  
  
  
  3.     at java.io.PrintStream.write(PrintStream.java:526)
    4. 
  
  
  
  
  4.     at java.io.PrintStream.print(PrintStream.java:597)
    5. 
  
  
  
  
  5.     at java.io.PrintStream.println(PrintStream.java:736)
    6. 
  
  
  
  
  6.     at StackOverflowTest.a(StackOverflowTest.java:5)
    7.

哪些代碼容易出現(xiàn)問(wèn)題

忘記重寫(xiě)hashCode和equals

看下面的代碼。由于沒(méi)有重寫(xiě)Key類的hashCode和equals方法。造成了放入HashMap的所有對(duì)象，都無(wú)法被取出來(lái)。它們和外界失聯(lián)了。

下面這篇文章詳細(xì)的描述了它的原理。

結(jié)果集失控

不要覺(jué)得這段代碼可笑。在實(shí)際工作中的review中，xjjdog不止一次發(fā)現(xiàn)這種蛋疼的代碼。這有可能是趕工期，也有可能是剛學(xué)會(huì)寫(xiě)Java。這行代碼有很大的可能性踩坑。

條件失控

代碼。與之類似的就是條件失控，當(dāng)某個(gè)條件不滿足的時(shí)候，將會(huì)造成結(jié)果集的失控。大家可以看下面的代碼，fullname 和 other為空的時(shí)候，會(huì)出現(xiàn)什么后果?

萬(wàn)能參數(shù)

還有的同學(xué)使用各種Object和HashMap來(lái)進(jìn)行信息交換。這種代碼正常運(yùn)行的時(shí)候沒(méi)什么問(wèn)題，但一旦出錯(cuò)，幾乎無(wú)法排查。排查參數(shù)、排查堆棧、排查調(diào)用鏈，全部失效。

一些預(yù)防的措施

  • 減少創(chuàng)建大對(duì)象的頻率：比如byte數(shù)組的傳遞
  • 不要緩存太多的堆內(nèi)數(shù)據(jù)：使用guava的weak引用模式
  • 查詢的范圍一定要可控：如分庫(kù)分表中間件;ES等有同樣問(wèn)題
  • 用完的資源一定要close掉：可以使用新的 try-with-resources語(yǔ)法
  • 少用intern：字符串太長(zhǎng)，且無(wú)法復(fù)用，就會(huì)造成內(nèi)存泄漏
  • 合理的Session超時(shí)時(shí)間
  • 少用第三方本地代碼，使用Java方案替代
  • 合理的池大小
  • XML(SAX/DOM)、JSON解析要注意對(duì)象大小

案例分析一

這是最常見(jiàn)的一種情況。了解了這種方式，能夠應(yīng)對(duì)大多數(shù)內(nèi)存溢出和內(nèi)存泄漏問(wèn)題。

現(xiàn)象

  • 環(huán)境：CentOS7，JDK1.8，SpringBoot
  • G1垃圾回收器
  • 剛啟動(dòng)沒(méi)什么問(wèn)題，慢慢放量后，發(fā)生了OOM
  • 系統(tǒng)自動(dòng)生成了heapdump文件
  • 臨時(shí)解決方式：重啟，但問(wèn)題依然發(fā)現(xiàn)

信息收集

  • 日志：GC的日志信息：內(nèi)存突增突降，變動(dòng)迅速
  • 堆棧：Thread Dump文件：大部分阻塞在某個(gè)方法上
  • 壓測(cè)：使用wrk進(jìn)行壓測(cè)，發(fā)現(xiàn)20個(gè)用戶并發(fā)，內(nèi)存溢出
 
 
 
 
    
  
  
  
  
  1. wrk -t20 -c20 -d300s http://127.0.0.1:8084/api/test
    2.

MAT分析

堆棧文件獲?。?/p>

 
 
 
 
    
  
  
  
  
  1. jmap -dump:format=b,file=heap.bin 37340
    2. 
  
  
  
  
  2. jhsdb jmap  --binaryheap --pid  37340
    3.

MAT工具是基于eclipse平臺(tái)開(kāi)發(fā)的，本身是一個(gè)Java程序。分析Heap Dump文件：發(fā)現(xiàn)內(nèi)存創(chuàng)建了大量的報(bào)表對(duì)象。

通過(guò)菜單Find Leaks，一鍵找出黑李逵。

根據(jù)提示向下挖就可以。

解決

分析結(jié)果：

  • 系統(tǒng)存在大數(shù)據(jù)量查詢服務(wù)，并在內(nèi)存做合并
  • 當(dāng)并發(fā)量達(dá)到一定程度，會(huì)有大量數(shù)據(jù)堆積到內(nèi)存進(jìn)行運(yùn)算

解決方式：

  • 重構(gòu)查詢服務(wù)，減少查詢的字段
  • 使用SQL查詢代替內(nèi)存拼接，避免對(duì)結(jié)果集的操作
  • 舉例：查找兩個(gè)列表的交集

案例分析二

現(xiàn)象

  • 環(huán)境：CentOS7，JDK1.8，JBoss
  • CMS垃圾回收器
  • 操作系統(tǒng)CPU資源耗盡
  • 訪問(wèn)任何接口，響應(yīng)都非常的慢

分析

  • 發(fā)現(xiàn)每次GC的效果都特別好，但是非常頻繁
  • 了解到使用了堆內(nèi)緩存，而且設(shè)置的容量比較大
  • 緩存填充的速度特別快!

結(jié)論：

  • 開(kāi)了非常大的緩存，GC之后迅速占滿，造成GC頻繁

案例分析三

  • 現(xiàn)象java進(jìn)程異常退出
  • java進(jìn)程直接消失
  • 沒(méi)有留下dump文件
  • GC日志正常
  • 監(jiān)控發(fā)現(xiàn)死亡時(shí)，堆內(nèi)內(nèi)存占用很少，堆內(nèi)仍有大量剩余空間

分析

  • XX:+HeapDumpOnOutOfMemoryError不起作用
  • 監(jiān)控發(fā)現(xiàn)操作系統(tǒng)內(nèi)存持續(xù)增加

下面這些情況都會(huì)造成程序退出而沒(méi)什么響應(yīng)。

  • 被操作系統(tǒng)殺死 dmesg oom-killer
  • System.exit()
  • java com.cn.AA & 后終端關(guān)閉
  • kill -9

解決

發(fā)現(xiàn)：

  • 在dmesg命令中發(fā)現(xiàn)確實(shí)被oom-kill

解決：

  • 給JVM少分配一些內(nèi)存，騰出空間給其他進(jìn)程

本文標(biāo)題：給我1萬(wàn)字，也講Java不清內(nèi)存排查。1萬(wàn)不行來(lái)2萬(wàn)~.~
URL分享：http://uogjgqi.cn/article/cceppio.html
掃二維碼與項(xiàng)目經(jīng)理溝通

我們?cè)谖⑿派?4小時(shí)期待你的聲音

解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流