案例一：

一、事件：

支付系统突然出现频繁的超时，查看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程序猿必须要面对的问题，后期可以总结一下常见内存泄漏的场景。

*19年三月底针对微信支付高峰期超时问题，分析内存快照，还是有内存泄漏
在这里插入图片描述

案例二：

关键词：XStream单例；XStream性能问题

线上有一项目使用了XStream进行XML序列化、反序列化的方案，完成服务之间的接口报文Object与Xmlg格式之间的转化。

当线上业务量并不大的情况下，一切正常；但是发现当业务量突然加大的情况下，突然发现，线上服务器出现CPU居高不下，服务接口调用速度越来越慢，研究JVM日志分析，发现出现很多的RUNNABLE问题：

"http-nio-6680-exec-197" #4381 daemon prio=5 os_prio=0 tid=0x00007fda180aa000 nid=0x14e41b runnable [0x00007fd8d6536000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at com.thoughtworks.xstream.XStream.registerConverterDynamically(XStream.java:929)
	at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:917)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:574)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:496)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:465)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:411)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:378)
	at com.wings.frame.xml.XStreamInitializer.getInstance(XStreamInitializer.java:21)
	...

初步判断问题出在XStream上，分析XStream的源码，发现在XStream在new的时候会创建CompositeClassLoader（初始类加载器），并且不断new会不断创建，导致ygc需要扫描的内容越来越多，最终导致接口调用性能下降。

XStream是线程安全的，不需要重复初始化xstream对象，每一种类型实例化一个对象即可，而正是由于开发人员错误地在每次处理时都实例化一个新的xstream对象，才导致了该问题

XStream实例化的方法

		XStream xstream = XStreamInitializer.getInstance();
        xstream.processAnnotations(this.getClass());
        xstream.aliasSystemAttribute(null, "class");
        return xstream.toXML(this);

确定了问题，接下来就好办了，XStream是线程安全的支持单例模式，那就修改一下调用方法：

package com.wings.frame.tools;

import com.thoughtworks.xstream.XStream;
import java.io.*;
import java.util.concurrent.ConcurrentHashMap;

public class XmlHandler{

    private static final ConcurrentHashMap xStream = new ConcurrentHashMap<String, XStream>();
    
    /**
     * 初始化
     * @param objName
     * @return
     */
    private static XStream getXStream(Class<?> objName) {
        String key = objName.getName();
        if (xStream.get(key) == null)
            xStream.put(key, new XStream());
        return (XStream) xStream.get(key);
    }
    
    /**
     * 序列化
     * @param xmlHead
     * @param reqObjName
     * @return
     */
    public String toXML(String xmlHead,Class<?> reqObjName) {
        XStream xstream = getXStream(reqObjName);
        xstream.processAnnotations(reqObjName);
        //不显示class属性
        xstream.aliasSystemAttribute(null, "class");
        return xmlHead + xstream.toXML(reqObjName);
    }
    
    /**
     * 反序列化
     * @param clazz
     * @param xml
     * @param <T>
     * @return
     */
    public static <T> T parseXml(Class<T> clazz, String xml) {
        XStream xStream = getXStream(clazz);
        xStream.processAnnotations(clazz);
        @SuppressWarnings("unchecked")
        T t = (T) xStream.fromXML(xml);
        return t;
    }

}

/**
 * 解决原来XStream直接new出对象取使用，无法自动回收，引起的系统缓慢问题。
 */
public class XStreamUtil {
 public static final XStream bsp_req_stream = new XStream(new DomDriver("UTF-8",new XmlFriendlyNameCoder("_-", "_"))); 
 public static final XStream bsp_res_stream = new XStream(new DomDriver("UTF-8",new XmlFriendlyNameCoder("_-", "_"))); 
 
 static{
  bsp_req_stream.allowTypes(new Class[]{BspRequestXml.class});
  bsp_req_stream.processAnnotations(new Class[]{BspRequestXml.class});
  
  bsp_res_stream.allowTypes(new Class[] { BspResponseXml.class });
  bsp_res_stream.processAnnotations(new Class[]{BspResponseXml.class});
 }


}

XStream内存泄露和性能问题分析

案例一：

一、事件：

二、分析：

三、解决方案：

案例二：