最近中大招了，前一周開始偶爾在線上發(fā)現(xiàn)一些請求時長竟長達7秒，甚至在部分時段系統(tǒng)存在周期性的請求失敗或者超時，各種招式都使用了還是不知道確切的原因，百思不得其解，頭大的很！昨日晚上發(fā)現(xiàn)這個問題簡直太嚴重了，必須要馬上處理掉，一會都耽誤不得，遂持續(xù)奮斗到晚上一點多，早晨7點多又跑起來搞，用各種手段來找到問題的產(chǎn)生規(guī)律，一直到下午1點多，才終于發(fā)現(xiàn)癥結(jié)所在了！

應(yīng)用服務(wù)上曾經(jīng)出現(xiàn)過Load突然升高，并且伴隨OOM，遂加上了一個crontab定時任務(wù)，通過jmap來檢查老年代的使用情況，有到達快fullgc的點就告警出來，好立馬人工來檢查，上述問題倒是解決了，但是crontab任務(wù)沒有取消，才有了今天的惡果！

線上服務(wù)器怎么能夠出現(xiàn)這種低級問題呢？后悔得要命！

以下為從網(wǎng)上轉(zhuǎn)載的一篇文章，也有提到這個，留在這里好隨時提個醒！××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××

轉(zhuǎn)載自：http://hellojava.info/?p=328&utm_source=tuicool

JDK中帶有了一堆的工具是可以用來查看運行狀況，排查問題的，但對于這些工具還是要比較清楚執(zhí)行后會發(fā)生什么，否則有可能會因為執(zhí)行了一個命令就導(dǎo)致嚴重故障，重點講下影響比較大的jmap。

最主要的危險操作是下面這三種：
1. jmap -dump
這個命令執(zhí)行，JVM會將整個heap的信息dump寫入到一個文件，heap如果比較大的話，就會導(dǎo)致這個過程比較耗時，并且執(zhí)行的過程中為了保證dump的信息是可靠的，所以會暫停應(yīng)用。

2. jmap -permstat
這個命令執(zhí)行，JVM會去統(tǒng)計perm區(qū)的狀況，這整個過程也會比較的耗時，并且同樣也會暫停應(yīng)用。

3. jmap -histo:live
這個命令執(zhí)行，JVM會先觸發(fā)gc，然后再統(tǒng)計信息。

上面的這三個操作都將對應(yīng)用的執(zhí)行產(chǎn)生影響，所以建議如果不是很有必要的話，不要去執(zhí)行。

另外，在排查問題的時候，對于保留現(xiàn)場信息的操作，可以用gcore [pid]直接保留，這個的執(zhí)行速度會比jmap -dump快不少，之后可以再用jmap/jstack等從core dump文件里提取相應(yīng)的信息，不過這個操作建議大家先測試下，貌似在有些jdk版本上不work。

之前碰到過一次語言集的問題，我們的Java應(yīng)用多數(shù)在做字符串轉(zhuǎn)碼的時候是沒有指定編碼的，編碼信息主要靠啟動腳本里面設(shè)置LANG來控制，但沒想到在某種場景下，竟然有地方設(shè)置了LC_ALL，在之前的一篇語言集的文章中，有講過LC_ALL的優(yōu)先級是最高的，所以導(dǎo)致啟動腳本里設(shè)置的LANG失效了，從而導(dǎo)致了亂碼，這個Case來看，對于Java應(yīng)用，還是在啟動參數(shù)上指定下-Dfile.encoding比較安全一點，避免這種默認的轉(zhuǎn)碼依賴系統(tǒng)的配置，很容易踩進坑里。

總結(jié)

以上是生活随笔為你收集整理的jmap 几个慎用操作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。