享元模式

Published on 2016 - 09 - 04

应用示例

内存溢出对Java应用来说实在是太平常了,有以下两种可能。

  • 内存泄漏

无意识的代码缺陷,导致内存泄漏,JVM不能获得连续的内存空间。

  • 对象太多

代码写得很烂,产生的对象太多,内存被耗尽。现在的情况是没有内存泄漏,那只有一种原因——代码太差把内存耗尽。

该系统是一个报考系统,其中有一个模块负责社会人员报名,该模块对全国的考试人员只开放3天,并且限制报考人员数量。第一天9点开始报考,系统慢得像蜗牛,基本上都不能访问,后来设置了HTTP Server的并发数量,稍有缓解,40分钟后宕了一台机器,10分钟后,又挂了一台,下午3点又挂了一台,看样子晚上要让郎当去寺庙烧烧香了。

该系统一共有8台应用服务器,基本上CPU繁忙程度都在60%以上,HTTP的最大并发是2000,平均分配到每台应用服务器上没有太大的压力,于是怀疑是代码问题,然后详细了解了一下业务和数据流逻辑,基本的业务操作过程清楚了,先登录(没有账号的,则要先注册),登录后,需要填写以下信息:

  • 考试科目,选择框。
  • 考试地点,选择框,根据科目不同,列表不同。
  • 准考证邮寄地址,输入框。

还有其他一堆信息,我们以这三者作为代表来讲解。信息填写完毕后,点击确认,报名就结束了。简单程序的业务逻辑也确实是这样,为什么出现Crash情况呢?那肯定是和压力有关系!

我们先把这个过程的静态类图画出来,如图1所示。

很简单的工厂方法模式,表现层通过工厂方法模式创建对象,然后传递给业务层和持久层,最终保存到数据库中,为什么要使用工厂方法模式而不用直接new一个对象呢?因为是在框架下编程,必须有一个对象工厂(ObjectFactory,Spring也有对象工厂)。我们先来看报考信息,如代码清1所示。

public class SignInfo {
     //报名人员的ID
     private String id;
     //考试地点
     private String location;
     //考试科目
     private String subject;
     //邮寄地址
     private String postAddress;
     public String getId() {
             return id;
     }
     public void setId(String id) {
             this.id = id;
     }
     public String getLocation() {
             return location;
     }
    public void setLocation(String location) {
             this.location = location;
     }
     public String getSubject() {
             return subject;
     }
     public void setSubject(String subject) {
             this.subject = subject;
     }
     public String getPostAddress() {
             return postAddress;
     }
     public void setPostAddress(String postAddress) {
             this.postAddress = postAddress;
     }
}

它是一个很简单的POJO对象(Plain Ordinary Java Object,简单Java对象)。我们再来看工厂类,如代码清单2所示。

public class SignInfoFactory {
     //报名信息的对象工厂
     public static SignInfo getSignInfo(){
             return new SignInfo();
     }
}

工厂类就这么简单?非也,这是我们的教学代码,真实的ObjectFactory要复杂得多,主要是注入了部分Handler的管理。表现层是如何创建对象的,如代码清单3所示。

public class Client {
     public static void main(String[] args) {
             //从工厂中获得一个对象
             SignInfo signInfo = SignInfoFactory.getSignInfo();
             //进行其他业务处理
     }
}

就这么简单,但是简单为什么会出现问题呢?而且这样写也没有问题呀,很标准的工厂方法模式,应该不会有大问题,然后又看了看系统厂商提供的分析报告,报告中指出:内存突然由800MB飙升到1.4GB,新的对象申请不到内存空间,于是出现OutOfMemory,同时报告中还列出宕机时刻内存中的对象,其中SignInfo类的对象就有400MB,疯子,绝对是疯子!报告都没有看嘛!

问题找到了,我拉郎当过来谈话,“厂商不是分析出原因了嘛,人家已经指出SignInfo类的对象占用了400MB多的内存,这是怎么回事?”

“三哥,这是很正常的,这么大的访问量,产生出这么多的SignInfo对象也是应该的,内存中有这么多对象并不表示这些对象正在被使用呀,估计很大一部分还没有被回收而已,垃圾回收器什么时候回收内存中的对象这是不确定的。你看,并发200多个,这可是并发数量……”

我想了想,也确实是这么回事。既然已经定位是内存中对象太多,那就应该想到使用一种共享的技术减少对象数量,那怎么共享呢?

大家知道,对象池(Object Pool)的实现有很多开源工具,比如Apache的commons-pool就是一个非常不错的池工具,我们暂时还用不到这种重量级的工具,我们自己来设计一个共享对象池,需要实现如下两个功能。

  • 容器定义

我们要定义一个池容器,在这个容器中容纳哪些对象。

  • 提供客户端访问的接口

我们要提供一个接口供客户端访问,池中有可用对象时,可以直接从池中获得,否则建立一个新的对象,并放置到池中。

设计思路有了,那我们池中对象的标准是什么呢?你想想看,如果你把所有的对象都放到池中,那还有什么意义?内存早就给你撑爆了!这么多对象,必然有一些相同的属性值,如几十万SignInfo对象中,考试科目就4个,考试地点也就是30多个,其他的属性则是每个对象都不相同的,我们把对象的相同属性提取出来,不同的属性在系统内进行赋值处理,是不是就可以建立一个池了?话无须多说,我们以类图来表示,如图2所示。

做一个很小的改动,增加了一个子类,实现带缓冲池的对象建立,同时在工厂类上增加了一个容器对象HashMap,保存池中的所有对象。我们先来看产品子类,如代码清单4所示。

public class SignInfo4Pool extends SignInfo {
     //定义一个对象池提取的KEY值
     private String key;
     //构造函数获得相同标志
     public SignInfo4Pool(String _key){
             this.key = _key;
     }
     public String getKey() {
             return key;
     }
     public void setKey(String key) {
             this.key = key;
     }
}

很简单,就是增加了一个key值,为什么要增加key值?为什么要使用子类,而不在SignInfo类上做修改?好,我来给你解释为什么要这样做,我们刚刚已经分析了所有的SignInfo对象都有一些共同的属性:考试科目和考试地点,我们把这些共性提取出来作为所有对象的外部状态,在这个对象池中一个具体的外部状态只有一个对象。按照这个设计,我们定义key值的标准为:考试科目+考试地点的复合字符串作为唯一的池对象标准,也就是说在对象池中,一个key值唯一对应一个对象。

注意 在对象池中,对象一旦产生,必然有一个唯一的、可访问的状态标志该对象,而且池中的对象声明周期是由池容器决定,而不是由使用者决定的。

你可能马上就要提出了,为什么不建立一个新的类,包含subject和location两个属性作为外部状态呢?嗯,这是一个办法,但不是最好的办法,有两个原因:

  • 修改的工作量太大,增加的这个类由谁来创建呢?同时,SignInfo类是否也要修改呢?你不可能让两段相同的POJO程序同时出现在同一模块中吧!
  • 性能问题,我们会在扩展模块中讲解。

说了这么多,我们还是继续来看程序,工厂类如代码清单5所示。

public class SignInfoFactory {
     //池容器
     private static HashMap<String,SignInfo> pool = new HashMap<String,SignInfo>();
     //报名信息的对象工厂
     @Deprecated
     public static SignInfo(){
          return new SignInfo();
     }
     //从池中获得对象
     public static SignInfo getSignInfo(String key){
          //设置返回对象
          SignInfo result = null;
          //池中没有该对象,则建立,并放入池中
          if(!pool.containsKey(key)){
               System.out.println(key + "----建立对象,并放置到池中");
               result = new SignInfo4Pool(key);
               pool.put(key, result);
          }else{
               result = pool.get(key);
               System.out.println(key +"---直接从池中取得");
          }
    return result;
     }
}

方法都很简单,不多解释。读者需要注意一点的是@Deprecated注解,不要有删除投产中代码的念头,如果方法或类确实不再使用了,增加该注解,表示该方法或类已经过时,尽量不要再使用了,我们应该保持历史原貌,同时也有助于版本向下兼容,特别是在产品级研发中。

我们再来看看客户端是如何调用的,如代码清单6所示。

public class Client {
     public static void main(String[] args) {
          //初始化对象池
          for(int i=0;i<4;i++){
               String subject = "科目" + i;
               //初始化地址
               for(int j=0;j<30;j++){
                    String key = subject + "考试地点"+j;
                    SignInfoFactory.getSignInfo(key);
               }
          }
          SignInfo signInfo = SignInfoFactory.getSignInfo("科目1考试地点1");
     }
}

运行结果如下所示:

科目3考试地点25----建立对象,并放置到池中
科目3考试地点26----建立对象,并放置到池中
科目3考试地点27----建立对象,并放置到池中
科目3考试地点28----建立对象,并放置到池中
科目3考试地点29----建立对象,并放置到池中
科目1考试地点1---直接从池中取得

前面还有很多的对象创建提示语句,不再复制。通过这样的改造后,我们想想内存中有多少个SignInfo对象?是的,最多120个对象,相比之前几万个SignInfo对象优化了非常多。细心的读者可能注意到了SignInfo4Pool类基本上没有跑出我们的视线范围,仅仅在工厂方法中使用到了,尽量缩小变更引起的风险,想想看我们的改动是不是很小,只要在展示层中拼一个字符串,然后传递到工厂方法中就可以了。

通过这样的改造后,第三天系统运行得非常稳定,CPU占用率也下降了,而且以后再也没有出现类似问题,这就是享元模式的功劳。

享元模式的定义

享元模式(Flyweight Pattern)是池技术的重要实现方式,其定义如下:Use sharing to support large numbers of fine-grained objects efficiently.(使用共享对象可有效地支持大量的细粒度的对象。)

享元模式的定义为我们提出了两个要求:细粒度的对象和共享对象。我们知道分配太多的对象到应用程序中将有损程序的性能,同时还容易造成内存溢出,那怎么避免呢?就是享元模式提到的共享技术。我们先来了解一下对象的内部状态和外部状态。

要求细粒度对象,那么不可避免地使得对象数量多且性质相近,那我们就将这些对象的信息分为两个部分:内部状态(intrinsic)与外部状态(extrinsic)。

  • 内部状态

内部状态是对象可共享出来的信息,存储在享元对象内部并且不会随环境改变而改变,如我们例子中的id、postAddress等,它们可以作为一个对象的动态附加信息,不必直接储存在具体某个对象中,属于可以共享的部分。

  • 外部状态

外部状态是对象得以依赖的一个标记,是随环境改变而改变的、不可以共享的状态,如我们例子中的考试科目+考试地点复合字符串,它是一批对象的统一标识,是唯一的一个索引值。

有了对象的两个状态,我们就可以来看享元模式的通用类图,如图3所示。

类图也很简单,我们先来看我们享元模式角色名称。

  • Flyweight——抽象享元角色

它简单地说就是一个产品的抽象类,同时定义出对象的外部状态和内部状态的接口或实现。

  • ConcreteFlyweight——具体享元角色

具体的一个产品类,实现抽象角色定义的业务。该角色中需要注意的是内部状态处理应该与环境无关,不应该出现一个操作改变了内部状态,同时修改了外部状态,这是绝对不允许的。

  • unsharedConcreteFlyweight——不可共享的享元角色

不存在外部状态或者安全要求(如线程安全)不能够使用共享技术的对象,该对象一般不会出现在享元工厂中。

  • FlyweightFactory——享元工厂

职责非常简单,就是构造一个池容器,同时提供从池中获得对象的方法。

享元模式的目的在于运用共享技术,使得一些细粒度的对象可以共享,我们的设计确实也应该这样,多使用细粒度的对象,便于重用或重构。我来看享元模式的通用代码,先看抽象享元角色,如代码清单7所示。

public abstract class Flyweight {
     //内部状态
     private String intrinsic;
     //外部状态
     protected final String Extrinsic;
     //要求享元角色必须接受外部状态
     public Flyweight(String _Extrinsic){
             this.Extrinsic = _Extrinsic;
     }
     //定义业务操作
     public abstract void operate();
     //内部状态的getter/setter
     public String getIntrinsic() {
             return intrinsic;
     }
     public void setIntrinsic(String intrinsic) {
             this.intrinsic = intrinsic;
     }
}

抽象享元角色一般为抽象类,在实际项目中,一般是一个实现类,它是描述一类事物的方法。在抽象角色中,一般需要把外部状态和内部状态(当然了,可以没有内部状态,只有行为也是可以的)定义出来,避免子类的随意扩展。我们再来看具体的享元角色,如代码清单8所示。

public class ConcreteFlyweight1 extends Flyweight{
     //接受外部状态
     public ConcreteFlyweight1(String _Extrinsic){
             super(_Extrinsic);
     }
     //根据外部状态进行逻辑处理
     public void operate(){
             //业务逻辑
     }
}
public class ConcreteFlyweight2 extends Flyweight{
     //接受外部状态
     public ConcreteFlyweight2(String _Extrinsic){
             super(_Extrinsic);
     }
     //根据外部状态进行逻辑处理
     public void operate(){
             //业务逻辑
     }
}

这很简单,实现自己的业务逻辑,然后接收外部状态,以便内部业务逻辑对外部状态的依赖。注意,我们在抽象享元中对外部状态加上了final关键字,防止意外产生,什么意外?获得了一个外部状态,然后无意修改了一下,池就混乱了!

注意 在程序开发中,确认只需要一次赋值的属性则设置为final类型,避免无意修改导致逻辑混乱,特别是Session级的常量或变量。

我们继续看享元工厂,如代码清单9所示。

public class FlyweightFactory {
     //定义一个池容器
     private static  HashMap<String,Flyweight> pool= new HashMap<String,Flyweight>();
     //享元工厂
     public static Flyweight getFlyweight(String Extrinsic){
             //需要返回的对象
             Flyweight flyweight = null;
             //在池中没有该对象
             if(pool.containsKey(Extrinsic)){
                     flyweight = pool.get(Extrinsic);
             }else{
                     //根据外部状态创建享元对象
                     flyweight = new ConcreteFlyweight1(Extrinsic);
                     //放置到池中
                     pool.put(Extrinsic, flyweight);
             }
             return flyweight;
     }
}

享元模式的应用

享元模式的优点和缺点

享元模式是一个非常简单的模式,它可以大大减少应用程序创建的对象,降低程序内存的占用,增强程序的性能,但它同时也提高了系统复杂性,需要分离出外部状态和内部状态,而且外部状态具有固化特性,不应该随内部状态改变而改变,否则导致系统的逻辑混乱。

享元模式的使用场景

在如下场景中则可以选择使用享元模式。

  • 系统中存在大量的相似对象。
  • 细粒度的对象都具备较接近的外部状态,而且内部状态与环境无关,也就是说对象没有特定身份。
  • 需要缓冲池的场景。

享元模式的扩展

线程安全的问题

线程安全是一个老生常谈的话题,只要使用Java开发都会遇到这个问题,我们之所以要在今天的享元模式中提到该问题,是因为该模式有太大的几率发生线程不安全,为什么呢?

我们还以报考系统为例来说明这个问题。大家有没有想过,为什么要以考试科目+考试地点作为外部状态呢?为什么不能以考试科目或者考试地点作为外部状态呢?这样池中的对象会更少!可以!完全可以!我们把程序以考试科目为外部状态,把享元工厂稍作修改,如代码清单10所示。

public class SignInfoFactory {
     //池容器
     private static HashMap<String,SignInfo> pool = new HashMap<String,SignInfo>();
     //从池中获得对象
     public static SignInfo getSignInfo(String key){
             //设置返回对象
             SignInfo result = null;
             //池中没有该对象,则建立,并放入池中
             if(!pool.containsKey(key)){
                     result = new SignInfo();
                     pool.put(key, result);
             }else{
                     result = pool.get(key);
             }
             return result;
     }
}

下面做很小的改动,只修改了黑色字体部分。为了展示多线程的情况,我们写一个多线程的类,如代码清单11所示。

public class MultiThread extends Thread {
     private SignInfo signInfo;
     public MultiThread(SignInfo _signInfo){
                     this.signInfo = _signInfo;
     }
     public void run(){
             if(!signInfo.getId().equals(signInfo.getLocation())){
                     System.out.println("编号:"+signInfo.getId());
                     System.out.println("考试地址:"+signInfo.getLocation());
                     System.out.println("线程不安全了!");
             }
     }
}

在run方法中判断特殊值,检查是否是线程安全,我们来看看场景类,如代码清单12所示。

public class Client {
     public static void main(String[] args) {
             //在对象池中初始化4个对象
             SignInfoFactory.getSignInfo("科目1");
             SignInfoFactory.getSignInfo("科目2");
             SignInfoFactory.getSignInfo("科目3");
             SignInfoFactory.getSignInfo("科目4");
            //取得对象
             SignInfo signInfo = SignInfoFactory.getSignInfo("科目2");
             while(true){
                     signInfo.setId("ZhangSan");
                     signInfo.setLocation("ZhangSan");
                     (new MultiThread(signInfo)).start();
                     signInfo.setId("LiSi");
                     signInfo.setLocation("LiSi");
                     (new MultiThread(signInfo)).start();
             }
     }
}

模拟实际的多线程情况,在对象池中我们保留4个对象,然后启动N多个线程来模拟,我们马上就看到如下的提示:

编号:LiSi
考试地址:ZhangSan
线程不安全了!

看看,线程不安全了吧,这是正常的,设置的享元对象数量太少,导致每个线程都到对象池中获得对象,然后都去修改其属性,于是就出现一些不和谐数据。只要使用Java开发,线程问题是不可避免的,那我们怎么去避免这个问题呢?享元模式是让我们使用共享技术,而Java的多线程又有如此问题,该如何设计呢?没什么可以参考的标准,只有依靠经验,在需要的地方考虑一下线程安全,在大部分的场景下都不用考虑。我们在使用享元模式时,对象池中的享元对象尽量多,多到足够满足业务为止。

性能平衡

尽量使用Java基本类型作为外部状态。在报考系统中,我们不考虑系统的修改风险,完全可以重新建立一个类作为外部状态,因为这才完全符合面向对象编程的理念。好,我们实现处理,先看类图,如图4所示。

我们首先来看ExtrinsicState外部状态类,如代码清单13所示。

public class ExtrinsicState {
     //考试科目
     private String subject;
     //考试地点
     private String location;
     public String getSubject() {
             return subject;
     }
     public void setSubject(String subject) {
             this.subject = subject;
     }
     public String getLocation() {
             return location;
     }
     public void setLocation(String location) {
             this.location = location;
     }
     @Override
     public boolean equals(Object obj){
             if(obj instanceof ExtrinsicState){
                 ExtrinsicState state = (ExtrinsicState)obj;
                  return state.getLocation().equals(location) && state.getSubject().equals(subject);
             }
             return false;
     }
     @Override
     public int hashCode(){
             return subject.hashCode() + location.hashCode();
     }
}

注意,一定要覆写equals和hashCode方法,否则它作为HashMap中的key值是根本没有意义的,只有hashCode值相等,并且equals返回结果为true,两个对象才相等,也只有在这种情况下才有可能从对象池中查找获得对象。
注意 如果把一个对象作为Map类的键值,一定要确保重写了equals和hashCode方法,否则会出现通过键值搜索失败的情况,例如map.get(object)、map.contains(object)等会返回失败的结果。

SignInfo的修改较小,仅在SignInfo中引入该ExtrinsicState外部状态对象,在此不再赘述。我们再来看享元工厂,它是以ExtrinsicState类作为外部状态,如代码清单14所示。

public class SignInfoFactory {
     //池容器
     private static HashMap<ExtrinsicState,SignInfo> pool = new HashMap <ExtrinsicState,SignInfo>();
     //从池中获得对象
     public static SignInfo getSignInfo(ExtrinsicState key){
             //设置返回对象
             SignInfo result = null;
             //池中没有该对象,则建立,并放入池中
             if(!pool.containsKey(key)){
                     result = new SignInfo();
                     pool.put(key, result);
             }else{
                     result = pool.get(key);
             }
             return result;
     }
}

重点是看看我们的场景类,我们来测试一下性能差异,如代码清单15所示。

public class Client {
     public static void main(String[] args) {
             //初始化对象池
             ExtrinsicState state1 = new ExtrinsicState();
             state1.setSubject("科目1");
             state1.setLocation("上海");
             SignInfoFactory.getSignInfo(state1);
             ExtrinsicState state2 = new ExtrinsicState();
             state2.setSubject("科目1");
             state2.setLocation("上海");
             //计算执行100万次需要的时间
             long currentTime = System.currentTimeMillis();
             for(int i=0;i<1000000;i++){
                     SignInfoFactory.getSignInfo(state2);
             }
             long tailTime = System.currentTimeMillis();
             System.out.println("执行时间:"+(tailTime - currentTime) + " ms");
     }
}

运行结果如下所示:

执行时间:172 ms

同样,我们看看以String类型作为外部状态的运行情况,如代码清单16所示。

public class Client {
     public static void main(String[] args) {
             String key1 = "科目1上海";
             String key2 = "科目1上海";
             //初始化对象池
             SignInfoFactory.getSignInfo(key1);
            //计算执行10万次需要的时间
             long currentTime = System.currentTimeMillis();
             for(int i=0;i<10000000;i++){
                     SignInfoFactory.getSignInfo(key2);
             }
             long tailTime = System.currentTimeMillis();
             System.out.println("执行时间:"+(tailTime - currentTime) + " ms");
     }
}

运行结果如下所示:

执行时间:78 ms

看到没?一半的效率,这还是非常简单的享元对象,看看我们重写的equals方法和hashCode方法,这段代码是必须实现的,如果比较复杂,这个时间差异会更大。

各位,想想看,使用自己编写的类作为外部状态,必须覆写equals方法和hashCode方法,而且执行效率还比较低,这种吃力不讨好的事情最好别做,外部状态最好以Java的基本类型作为标志,如String、int等,可以大幅地提升效率。

最佳实践

Flyweight是拳击比赛中的特用名词,意思是“特轻量级”,指的是51公斤级比赛,用到设计模式中是指我们的类要轻量级,粒度要小,这才是它要表达的意思。粒度小了,带来的问题就是对象太多,那就用共享技术来解决。

享元模式在Java API中也是随处可见,如这样的程序就是一个很好的例子,如代码清单17所示。

public class Test {
    public static void main(String[] args) {
           String str1 = "和谐";
           String str2 = "社会";
           String str3 = "和谐社会";
           String str4; 
           str4 = str1 + str2; 
           System.out.println(str3 == str4);
           str4 = (str1 + str2).intern(); 
           System.out.println(str3 == str4);
    }
}

看看Java的帮助文件中String类的intern方法。如果是String的对象池中有该类型的值,则直接返回对象池中的对象,那当然相等了。

需要说明一下的是,虽然可以使用享元模式可以实现对象池,但是这两者还是有比较大的差异,对象池着重在对象的复用上,池中的每个对象是可替换的,从同一个池中获得A对象和B对象对客户端来说是完全相同的,它主要解决复用,而享元模式在主要解决的对象的共享问题,如何建立多个可共享的细粒度对象则是其关注的重点。

参考文档