java case容易崩溃_一些故障解决的CASE

这个贴用于记录自己碰到过的一些Java问题，会根据经验不断增加，以便总结，:)

case1: 某应用在运行个一两天后就会把物理内存耗光解决过程：

1、先按经验查了下有没有错误使用Inflater和Deflater，没有，于是继续；

2、继续上perftools，看看到底什么原因造成的，结果在6u21版本上看到的很诡异，是JVM_handle_linux_signal占了最多，觉得不靠谱，于是先升级成了6u26；

3、再分析，看到os::malloc占用了最多，但其他的就完全没头绪了；

4、在@JosephWang_CN的帮助下，图形分析下了perftools的stack

trace，才发现还是unsafe_allocate的地方，但这次现象和上个case不同，不同点在于这次是由于cms

gc的bug造成的，bug id为7112034，这个bug会造成即使direct bytebuffer已经无引用了，但在cms

gc时其并不会被清除掉，而要等到full

gc才会清除，官方版本在6u32中修复此bug(这个很容易验证，如果没开启ExplicitGCInvokesConcurrent，用jmap

-histo:live强制触发下)；

5、在fix了这个bug的前提下，还需要限制-XX:MaxDirectMemorySize的大小才行，否则可能会出现还没到触发cms

gc时，物理内存就用完了的现象。

总结：

根据多次排查Java Heap外内存泄露的问题，目前的经验为：

1、先查查看有没有错误使用Inflater和Deflater，如有则基本就搞定了；

2、多执行几次jmap -histo:live，看看内存会不会下降，如果会的话，多数和GC的bug有关；

3、perftools，对调用次数的那列进行排序(pprof –text … | sort -n -r

-k4)，如果看到是Unsafe_Allocate比较多，且为server端应用，则通常说明是哪个地方分配了Direct

ByteBuffer，但来不及释放引用，然后嘛，就是用btrace跟踪下看看谁干的，分析原因。

case2: 某应用在压测一段时间后就会把物理内存耗光解决过程：

1、从gc log以及jstat信息来看，java heap内的内存消耗并不多，但堆外消耗非常严重，导致了物理内存被耗光；

2、于是装上google perftools，看看堆外到底是什么原因造成的消耗；

3、分析了下google perftools的内存malloc消耗，主要是调用Unsafe.allocate造成的；

4、通常调用Unsafe.allocateMemory来分配内存的，只有Direct

ByteBuffer和AWT，这应用是没用AWT的，Direct ByteBuffer倒是用到了；

5、网上google了一会，找到一个貌似和这个应用的场景很像的内存泄露的现象，具体信息请见：http://t.co/S9jvDt8O，号称是SocketChannel.write的时候，如果是Direct

ByteBuffer会导致memory leak，而且Trustin Lee(Mina/Netty的作者)也这么说的：”it’s a

known bug”;

6、于是建议应用的同学将ByteBuffer的地方改成不用direct方式；

7、改完后，重新压测，物理内存消耗是没那么严重了，但java heap用满了后回收不了了；</