一、起
支付系统突然出现频繁的超时，查看error日志没有什么发现，凭经验去gc日志瞅一眼，有频繁的full gc，而且每两次gc，老年代会有80%的内存无法被回收，基本确认是系统出现内存泄漏，导致老年代空间被占满，频繁触发full gc,full gc 触发stop the word，导致业务接口超时。
二、承
2.1、dump内存数据
#netstat -tunlp|grep 端口号
#jmap -dump:live,file=dump.file pid
2.2、解析内存数据
#jhat -J-Xmx8192M dump.file
2.3、分析内存数据
查看实例个数前五的对象，可以看出第一名是第二名的实例个数的十几倍，大概率是class com.thoughtworks.xstream.core.util.CompositeClassLoader 对象造成的内存泄漏。
晚上搜资料，果然是。
我们支付系统在和微信第三方支付系统进行交互处理支付业务时，需要解析微信接口返回的XML数据，用到了xstream，而且每个请求都会新建一个xstream对象，xstream对象内部又会new CompositeClassLoader对象，Class.forName调用该Application ClassLoader，gc时xstream会被回收，但是CompositeClassLoader对象会被其他对象引用，大致一直无法回收，如果支付系统运行时间久了，就会有大量无用但是无法被回收的CompositeClassLoader，导致内存泄漏频繁gc。
这是一个比较典型的ClassLoader内存泄漏问题。
正规流程应该是：一个classloader就是一个从jar文件中加载.class文件的简单的类。当你卸载应用时，该classloader连同所有由该classloader加载的类都将被垃圾回收掉(可能不会立即回收，但是没用任何引用的对象，最终都会被gc回收)。
但现实情况是，有时候有些对象会防不胜防地引用到classloader，这样gc就无法对其进行回收。导致内存泄漏。
三、转
此问题的解决方案。
XStream官方有一段话：The XStream instance is thread-safe. That is, once the XStream instance has been created and configured, it may be shared across multiple threads allowing objects to be serialized/deserialized concurrently.即XStream是线程安全的，不需要重复初始化xstream对象，每一种类型实例化一个对象即可，而正是由于开发人员错误地在每次处理请求时都实例化一个新的xstream对象，没有把相同类型的缓存起来使用，才导致了该性能问题。
落地到支付系统，则需要为每个反序列化的对象声明一个静态的XStream，重复利用，问题解决。
四、合
内存泄漏是每个Java程序猿必须要面对的问题，后期可以总结一下常见内存泄漏的场景。
http://note.youdao.com/noteshare?id=6e36d4003850b41166e8cfda085a825e