一、
某天线上支付系统突然出现频繁的超时，接到系统报警后，查看日志没有什么发现，就只发现响应比平时慢了很多。通过SkyWalking发现有频繁的 gc，分析dump，基本确认是系统出现内存泄漏，导致老年代空间被占满，频繁触发gc，导致业务接口超时。
二、
通知运维dump内存数据，拿到文件后分析内存数据
1：dump内存数据
#netstat -tunlp|grep 端口号
#jmap -dump:live,file=dump.file pid
2：解析内存数据：
#jhat -J-Xmx8192M dump.file
查看实例个数前五的对象，可以看出第一名是第二名的实例个数的十几倍，大概率是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，重复利用，问题解决。
四：贴上我改动后的代码
