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程序猿必须要面对的问题，后期可以总结一下常见内存泄漏的场景。

*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});
 }


}

单例模式（单例设计模式）详解

在有些系统中，为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，这就是所谓的单例模式。

单例模式的定义与特点

单例（Singleton）模式的定义：指一个类只有一个实例，且该类能自行创建这个实例的一种模式。例如，Windows 中只能打开一个任务管理器，这样可以避免因打开多个任务管理器窗口而造成内存资源的浪费，或出现各个窗口显示内容的不一致等错误。

在计算机系统中，还有 Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用程序的日志对象、数据库的连接池、网站的计数器、Web 应用的配置对象、应用程序中的对话框、系统中的缓存等常常被设计成单例。

单例模式在现实生活中的应用也非常广泛，例如公司 CEO、部门经理等都属于单例模型。J2EE 标准中的 ServletContext 和 ServletContextConfig、Spring 框架应用中的 ApplicationContext、数据库中的连接池等也都是单例模式。

单例模式有 3 个特点：

1. 单例类只有一个实例对象；
2. 该单例对象必须由单例类自行创建；
3. 单例类对外提供一个访问该单例的全局访问点。

单例模式的优点和缺点

单例模式的优点：

• 单例模式可以保证内存里只有一个实例，减少了内存的开销。
• 可以避免对资源的多重占用。
• 单例模式设置全局访问点，可以优化和共享资源的访问。

单例模式的缺点：

• 单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
• 在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
• 单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

单例模式看起来非常简单，实现起来也非常简单。单例模式在面试中是一个高频面试题。希望大家能够认真学习，掌握单例模式，提升核心竞争力，给面试加分，顺利拿到 Offer。

单例模式的应用场景

对于 Java 来说，单例模式可以保证在一个 JVM 中只存在单一实例。单例模式的应用场景主要有以下几个方面。

• 需要频繁创建的一些类，使用单例可以降低系统的内存压力，减少 GC。
• 某类只要求生成一个对象的时候，如一个班中的班长、每个人的身份证号等。
• 某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
• 某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。
• 频繁访问数据库或文件的对象。
• 对于一些控制硬件级别的操作，或者从系统上来讲应当是单一控制逻辑的操作，如果有多个实例，则系统会完全乱套。
• 当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

单例模式的结构与实现

单例模式是设计模式中最简单的模式之一。通常，普通类的构造函数是公有的，外部类可以通过“new 构造函数()”来生成多个实例。但是，如果将类的构造函数设为私有的，外部类就无法调用该构造函数，也就无法生成多个实例。这时该类自身必须定义一个静态私有实例，并向外提供一个静态的公有函数用于创建或获取该静态私有实例。

下面来分析其基本结构和实现方法。

1. 单例模式的结构

单例模式的主要角色如下。

• 单例类：包含一个实例且能自行创建这个实例的类。
• 访问类：使用单例的类。

其结构如图 1 所示。

图1 单例模式的结构图

2. 单例模式的实现

Singleton 模式通常有两种实现形式。

第 1 种：懒汉式单例

该模式的特点是类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。代码如下：

1. public class LazySingleton {
2. private static volatile LazySingleton instance = null; //保证 instance 在所有线程中同步
4. private LazySingleton() {
5. } //private 避免类在外部被实例化
7. public static synchronized LazySingleton getInstance() {
8. //getInstance 方法前加同步
9. if (instance == null) {
10. instance = new LazySingleton();
11. }
12. return instance;
13. }
14. }

注意：如果编写的是多线程程序，则不要删除上例代码中的关键字 volatile 和 synchronized，否则将存在线程非安全的问题。如果不删除这两个关键字就能保证线程安全，但是每次访问时都要同步，会影响性能，且消耗更多的资源，这是懒汉式单例的缺点。

第 2 种：饿汉式单例

该模式的特点是类一旦加载就创建一个单例，保证在调用 getInstance 方法之前单例已经存在了。

1. public class HungrySingleton {
2. private static final HungrySingleton instance = new HungrySingleton();
4. private HungrySingleton() {
5. }
7. public static HungrySingleton getInstance() {
8. return instance;
9. }
10. }

饿汉式单例在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以是线程安全的，可以直接用于多线程而不会出现问题。

单例模式的扩展

单例模式可扩展为有限的多例（Multitcm）模式，这种模式可生成有限个实例并保存在 ArrayList 中，客户需要时可随机获取，其结构图如图 5 所示。