设计模式-享元模式学习之旅

1,021 阅读9分钟

“这是我参与8月更文挑战的第20天,活动详情查看:8月更文挑战

一、享元模式的由来

面向对象技术可以很好地解决一些灵活性或可扩展性问题,但在很多情况下需要在系统中增加类和对象的个数。当对象数量太多时,将导致运行代价过高,带来性能下降等问题。享元模式正是为解决这一类问题而诞生的。

享元模式(Flyweight Pattern)又称为轻量级模式,是对象池的一种实现。类似于线程池,线程池可以避免不停地创建和销毁多个对象,消耗性能。提供了减少对象数量从而改善应用所需的对象结构的方式。其宗旨是共享细粒度对象,将多个对同一对象的访问集中起来,不必为每个访问者创建一个单独的对象,以此来降低内存的消耗,属于结构型模式。

二、享元模式的定义

享元模式把一个对象的状态分成内部状态和外部状态,内部状态即是不变的,外部状态是变化的,然后通过共享不变的部分,达到减少对象数量并节约内存的目的。

享元模式的本质是缓存共享对象,降低内存消耗。

三、享元模式涉及的角色

  1. 抽象享元角色(Flyweight):享元对象抽象基类或者接口,同时定义出对象的外部状态和内部状态的接口或实现。
  2. 具体享元角色(ConcreteFlyweight):实现抽象角色定义的业务。该角色的内部状态处理应该与环境有关,不能出现有一个操作改变内部状态,同时修改了外部状态。
  3. 享元工厂(FlyweightFactory):负责管理享元对象池和创建享元对象。

四、享元模式的应用场景

当系统中多处需要同一组信息时,可以把这些信息封装到一个对象中,然后对该对象进行缓存,这样,一个对象就可以提供给多处需要使用的地方,避免大量同一对象的多次创建,消耗大量内存空间。

享元模式其实就是工厂模式的一个改进机制,享元模式同样要求创建一个或一组对象,并且就是通过工厂方法生成对象的,只不过享元模式中为工厂方法增加了缓存这一功能。

主要总结为以下应用场景:

  1. 常常应用于系统底层的开发,以便解决系统的性能问题。
  2. 系统有大量相似对象,需要缓冲池的场景。

在生活中的享元模式也很常见,比如各中介机构的房源共享,再比如全国社保联网。

五、使用享元模式实现共享池业务

下面我们举个例子,每年春节为了抢到一张回家的火车票都要大费周折,进而出现了很多刷票软件,刷票软件会将我们填写的信息缓存起来,然后定时检查余票信息。抢票的时候,我们肯定要查询下有没有我们需要的票信息,这里我们假设一张火车的信息包含:出发站、目的站、价格、座位类别。现在要求模拟一个查询火车票伪代码,可以通过出发站,目的站查到相关票的信息。那么我们只需构建出火车票类对象,然后提供一个查询出发站,目的站的接口给到客户进行查询即可,具体代码如下,创建ITicket接口:

public interface ITicket {
    void showInfo(String bunk);
}

然后,创建TrainTicket接口:

public class TrainTicket implements ITicket {

    private String from;
    private String to;
    private int price;

    public TrainTicket(String from, String to) {
        this.from = from;
        this.to = to;
        this.price = new Random().nextInt(600);
    }

    @Override
    public void showInfo(String bunk) {
        System.out.println(String.format("%s->%s:%s价格:%s元", this.from, this.to, bunk, this.price));
    }
}

最后创建TicketFactory类:

public class TicketFactory {

    public static ITicket queryTicket(String from, String to) {
        return new TrainTicket(from, to);
    }
}

编写客户端代码:

public class Test {

    public static void main(String[] args) {
        ITicket ticket = TicketFactory.queryTicket("临汾西", "北京西");
        ticket.showInfo("动车");
    }
}

分析上面的代码,我们发现客户端进行查询时,系统通过TicketFactory直接创建一个火车票对象,但是这样做的话,当某个瞬时如果有大量的用户请求同一张票的信息时,系统就会创建出大量该火车票对象,系统内存压力骤增。而其实更好的做法应该是缓存该票对象,然后复用提供给其他查询请求,这样一个对象就满足以支撑数以千计的查询请求,对内存完全无压力,使用享元模式可以很好的解决这个问题。我们继续优化代码,只需在TicketFactory类中进行更改,增加缓存机制:

public class TicketFactory {

    private static Map<String, ITicket> ticketPool = new ConcurrentHashMap<>();

    public static ITicket queryTicket(String from, String to) {
        String key = from + "->" + to;
        if (ticketPool.containsKey(key)) {
            System.out.println("使用缓存:" + key);
            return ticketPool.get(key);
        }
        System.out.println("首次查询,创建对象:" + key);
        ITicket ticket = new TrainTicket(from, to);
        ticketPool.put(key, ticket);
        return ticket;
    }
}

修改客户端代码:

public class Test {

    public static void main(String[] args) {
        ITicket ticket = TicketFactory.queryTicket("临汾西", "北京西");
        ticket.showInfo("动车");
        ticket = TicketFactory.queryTicket("临汾西", "北京西");
        ticket.showInfo("动车");
        ticket = TicketFactory.queryTicket("临汾西", "北京西");
        ticket.showInfo("动车");
    }
}

运行结果如下:

image.png

可以看到,除了第一次查询创建对象后,后续查询相同车次票信息都是使用缓存对象,无需创建新对象了。

再比如,我们经常使用的数据库连接池,因为我们使用Connection对象时主要性能消耗在建立连接和关闭连接上,为了提高Connection在调用时的性能,我们将Connection对象在调用前创建缓存起来,用的时候从缓存中取值,用完再放回去,达到资源重复利用的目的。

六、享元模式在源码中的应用

1. String中的享元模式

Java中将String类定义为final(不可变的),JVM中字符串一般保存在字符串常量池中,java会确保一个字符串在常量池中只有一个拷贝,这个字符串常量池在JDK6.0以前是位于常量池中,位于永久代,而在JDK7.0中,JVM将其从永久代拿出来放置于堆中。

我们做一个测试:

public class StringTest {

    public static void main(String[] args) {
        String s1 = "hello";
        String s2 = "hello";
        String s3 = "he" + "llo";
        String s4 = "hel" + new String("lo");
        String s5 = new String("hello");
        String s6 = s5.intern();
        String s7 = "h";
        String s8 = "ello";
        String s9 = s7 + s8;
        System.out.println(s1 == s2);//true
        System.out.println(s1 == s3);//true
        System.out.println(s1 == s4);//false
        System.out.println(s1 == s5);//false
        System.out.println(s1 == s6);//true
        System.out.println(s4 == s5);//false
        System.out.println(s1 == s9);//false
    }
}

String类被final修饰,以字面量的形式创建String变量时,JVM会在编译期间就把该字面量"hello"放到字符串常量池中,由Java程序启动的时候就已经加载到内存中了。这个字符串常量池的特点就是有且只有一份相同的字面量,如果有其它相同的字面量,JVM则返回这个字面量的引用,如果没有相同的字面量,则在字符串常量池创建这个字面量并返回它的引用。

由于s2指向的字面量"hello"在常量池中已经存在了(s1先于s2),于是JVM就返回这个字面量绑定的引用,所以s1==s2。

s3中字面量的拼接其实就是"hello",JVM在编译期间就已经对它进行优化,所以s1和s3也是相等的。

s4中的new String("lo")生成了两个对象,lo,new String("lo"),lo存在字符串常量池,new String("lo")存在堆中,String s4 = "hel" + new String("lo")实质上是两个对象的相加,编译器不会进行优化,相加的结果存在堆中,而s1存在字符串常量池中,当然不相等。s1==s9的原理一样。

s4==s5两个相加的结果都在堆中,不用说,肯定不相等。

s1==s6,s5.intern()方法能是一个位于堆中的字符串在运行期间动态的加入到字符串常量池中(字符串常量池的内容是程序启动的时候就已经加载好了),如果字符串常量池中有该对象对应的字面量,则返回该字面量在字符串常量池中的引用,否则,创建复制一份该字面量到字符串常量池并返回它的引用。因此s1==s6输出true。

2. Integer中的享元模式

再举例一个大家都非常熟悉的对象Integer,也用到了享元模式,其中暗藏玄机,我们来看个例子:

public class IntegerTest {

    public static void main(String[] args) {
        Integer a = Integer.valueOf(100);
        Integer b = 100;

        Integer c = Integer.valueOf(1000);
        Integer d = 1000;

        System.out.println("a==b:" + (a == b));//true
        System.out.println("c==d:" + (c == d));//false
    }
}

之所以得到这样的结果,是因为Integer用到了享元模式,我们来看Integer的源码:

public static Integer valueOf(int i) {
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

我们发现Integer源码中的valueOf()方法做了一个条件判断,如果目标值在-128到127之间,则直接从缓存中取值,否则新建对象。那JDK为何要这样做呢?因为在-128到127之间的数据在int范围内是使用最频繁的,为了节省频繁创建对象带来的内存消耗,这里就用到了享元模式,来提高性能。

七、享元模式的内部状态和外部状态

享元模式的定义为我们提出了两个要求:细粒度和共享对象。因为要求细粒度对象,所以不可避免的会使对象数量多且性质相近,此时我们将这些对象的信息分为两个部分:内部状态和外部状态。

内部状态指对象共享出来的信息,存储在享元对象内部并且不会随环境的改变而改变,外部状态指对象得以依赖的一个标记,是随环境改变而改变的,不可共享的状态。

比如,连接池中的连接对象,保存在连接对象中的用户名、密码、连接url等信息,在创建对象的时候就设置好了,不会随环境的改变而改变,这些为内部状态。而每个连接要回收利用时,我们需要给它标记为可用状态,这些为外部状态。

八、享元模式的优缺点

优点:

  1. 减少对象的创建、降低内存中对象的数量,降低系统的内存,提高效率。
  2. 减少内存之外的其他资源占用。

缺点:

  1. 关注内外部状态,关注线程安全问题。
  2. 使系统程序的逻辑复杂化。

九、友情链接

设计模式-工厂模式学习之旅

设计模式-单例模式学习之旅

设计模式-原型模式学习之旅

设计模式-建造者模式学习之旅

设计模式-代理模式学习之旅

设计模式-门面模式学习之旅

设计模式-装饰器模式学习之旅

欢迎大家关注微信公众号(MarkZoe)互相学习、互相交流。