利用Hadoop分析BHO上報日志時，發(fā)現(xiàn)很多日志文件會出現(xiàn)下面的錯誤：
即在map結(jié)束的時候拋出Java堆棧溢出異常！
（友情提示：本博文章歡迎轉(zhuǎn)載，但請注明出處：hankchen，http://www.aygfsteel.com/hankchen）
首先設(shè)置下面的參數(shù)：
發(fā)現(xiàn)還是解決不了問題。開始懷疑代碼問題，于是進行了一系列的優(yōu)化：
主要的優(yōu)化是，在map和reduce程序中，重用key和value對象。但是發(fā)現(xiàn)還是解決不了問題。并且mapred.child.java.opts設(shè)置3G也無濟于事。
沒有辦法，只好繼續(xù)找原因。最后發(fā)現(xiàn)一個規(guī)律：報這個異常出錯的日志不一定是最大的日志。
只好使用最后一招了，直接分析報錯時的Java堆內(nèi)存情況！
再次出現(xiàn)異常的時候，把集群里面所有的機器的Hadoop進程的堆內(nèi)存導(dǎo)出來分析！
主要是下面的幾類進程：
同時，關(guān)注每臺機器的top命令輸出，可以從內(nèi)存的使用情況中發(fā)現(xiàn)主要是哪臺機器出問題！然后重點導(dǎo)出這臺機器的Java堆參數(shù)！
jmap -dump:live,format=b,file=heapt0923.bin pid
剩下來的就是把/data/bhopid_output/heapt0923.bin這個文件復(fù)制到本地，利用Eclipse Memory Analyzer Tool 進行分析！
下面是分析的結(jié)果：
發(fā)現(xiàn)有兩個內(nèi)存泄漏的情況：
1、
2、
找到根本原因：說明日志文件有這樣很大的空記錄導(dǎo)致的！在代碼中把這些記錄忽略掉即可！
![clip_image002[11]](http://www.aygfsteel.com/images/blogjava_net/hankchen/WindowsLiveWriter/EclipseMemoryAnalyzerToolMAT_FC20/clip_image002%5B11%5D_thumb.jpg "clip_image002[11]")
（友情提示：本博文章歡迎轉(zhuǎn)載，但請注明出處：hankchen，http://www.aygfsteel.com/hankchen）