1、起
支付系统忽然出现频繁的超时，查看error日志没有什么发现，凭经验去gc日志瞅一眼，有频繁的full gc，并且每两次gc，老年代会有80%的内存没法被回收，基本确认是系统出现内存泄漏，致使老年代空间被占满，频繁触发full gc,full gc 触发stop the word，致使业务接口超时。
2、承
2.一、dump内存数据
#netstat -tunlp|grep 端口号
#jmap -dump:live,file=dump.file pid
2.二、解析内存数据
#jhat -J-Xmx8192M dump.file
2.三、分析内存数据
查看实例个数前五的对象，能够看出第一名是第二名的实例个数的十几倍，大几率是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就没法对其进行回收。致使内存泄漏。
3、转
此问题的解决方案。
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，重复利用，问题解决。
4、合
内存泄漏是每一个Java程序猿必需要面对的问题，后期能够总结一下常见内存泄漏的场景。
http://note.youdao.com/noteshare?id=6e36d4003850b41166e8cfda085a825e