记一次xstream引起的内存泄漏

Posted qhj348770376

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次xstream引起的内存泄漏相关的知识,希望对你有一定的参考价值。

一、起
支付系统突然出现频繁的超时,查看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
 

以上是关于记一次xstream引起的内存泄漏的主要内容,如果未能解决你的问题,请参考以下文章

记一次内存泄漏问题排查

记一次 .NET 某电厂Web系统 内存泄漏分析

记一次服务Full GC背后的内存泄漏问题,真是匪夷所思

记一次 .NET 某智能服装智造系统 内存泄漏分析

记一次 .NET 某消防物联网 后台服务 内存泄漏分析

记一次使用windbg排查内存泄漏的过程