? ? 最近新做了一個告警監(jiān)控的APP項目蛙婴，后臺代碼只有用戶登錄管理和告警查詢模塊镣丑，業(yè)務量特別少舔糖，項目部署服務器上后，發(fā)現(xiàn)內(nèi)置直接飆升至2G莺匠，甚至直接OOM金吗，導致服務器系統(tǒng)重啟，于是開始尋找原因。
1摇庙、首先排查代碼旱物，看代碼是否存在死循環(huán)及循環(huán)引用等情況，經(jīng)過詳細排查后卫袒，并沒有發(fā)現(xiàn)任何問題异袄。
2、可能沒有設置合適的jvm啟動參數(shù)玛臂，于是設置該參數(shù) 烤蜕。（參考鏈接）
java -Xms256m -Xmx512m -XX:ParallelGCThreads=2 -Djava.compiler=NONE -jar monitor-0.0.1-SNAPSHOT.jar
通過設定Xmx(程序運行期間最大可占用的內(nèi)存大小)、Xss(jvm啟動的每個線程分配的內(nèi)存大小)迹冤、XX:ParallelGCThreads(GC線程數(shù))以及關閉了JIT功能讽营，達成了降低內(nèi)存占用的目的。
3泡徙、設置項目jvm參數(shù)后內(nèi)存沒有繼續(xù)上升橱鹏，但是在運行過程中，發(fā)現(xiàn)內(nèi)存會上升到600M左右堪藐，自以為能夠穩(wěn)定運行了莉兰，結(jié)果運行了2個小時后又OOM了
Exception in thread "http-nio-8080-exec-3" Exception in thread "http-nec-4" java.lang.OutOfMemoryError: Java heap space
? ? ? ? at java.nio.HeapByteBuffer.<init>(Unknown Source)
? ? ? ? at java.nio.ByteBuffer.allocate(Unknown Source)
4、使用jmap進行抓包分析后發(fā)現(xiàn)礁竞，無論是否內(nèi)存溢出糖荒，都會存在幾個對象占用特別大的內(nèi)存。
5、看線程名稱應該是tomcat的nio工作線程狂男，
第一步：打開Histogram看看占用內(nèi)存最大的是什么對象：
可以看到byte數(shù)組占用了接近JVM配置的最大堆的大小也就是400M综看，顯然這是OOM的原因。
第二步: 看一下究竟是哪些byte數(shù)組岖食，數(shù)組是啥內(nèi)容红碑，可以看出很明顯這和HTTP請求相關。
為了進一步驗證猜想泡垃，關閉前端調(diào)用析珊，只啟動后臺進程，此時發(fā)現(xiàn)內(nèi)存占用僅在200M左右兔毙。進一步使用jmap抓包唾琼，沒有發(fā)現(xiàn)之前內(nèi)存比較大的那幾個對象。當任意調(diào)用幾個接口后澎剥，內(nèi)存再次飆升锡溯，繼續(xù)抓包分析赶舆，發(fā)現(xiàn)又出現(xiàn)了幾個97.4M的對象，由此已經(jīng)可以確定祭饭，此OOM問題肯定與http請求和tomcat有關芜茵。進一步猜想可能是設置了什么不合理的啟動參數(shù)導致。(一般而言一次請求倡蝙，不可能會占用這么大的內(nèi)存九串。)
第三步: 通過查看GC根查看誰持有了數(shù)組的引用：
這符合之前的猜測，是tomcat的線程在處理過程中分配了97.7M的buffer在堆上寺鸥。
第四步: 檢查代碼里是否有tomcat或服務器相關配置猪钮，看到有這么一個配置：
server.maxHttpHeaderSize=102400000
server.tomcat.max-http-post-size=102400000
至此，基本已經(jīng)確定了可能就是這個不合理的最大配置參數(shù)導致的問題胆建。注銷該代碼后烤低，進一步部署驗證，發(fā)現(xiàn)問題已解決笆载。
