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

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

線上服務器怎么能夠出現這種低級問題呢？后悔得要命！

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

轉載自：http://hellojava.info/?p=328&utm_source=tuicool

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

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

2. jmap -permstat
這個命令執行，JVM會去統計perm區的狀況，這整個過程也會比較的耗時，并且同樣也會暫停應用。

3. jmap -histo:live
這個命令執行，JVM會先觸發gc，然后再統計信息。

上面的這三個操作都將對應用的執行產生影響，所以建議如果不是很有必要的話，不要去執行。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。