设计模式之享元模式

享元模式：

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

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

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

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

享元模式有三个参与角色：

抽象享元角色(Flyweight) ：享元对象抽象基类或者接口， 同时定义出对象的外部状态和内部状态的接口或实现；

具体享元角色(Concrete Flyweight) ：实现抽象角色定义的业务。该角色的内部状态处理应该与环境无关，不能出现会有一个操作改变内部状态，同时修改了外部状态；

享元工厂(Flyweight Factory) ：负责管理享元对象池和创建享元对象。

享元模式的应用场景：

　　当系统中多处需要同一组信息时，可以把这些信息封装到一个对象中，然后对该对象进行缓存，这样，一个对象就可以提供给多处需要使用的地方，避免大量同一对象的多次创建，消耗大量内存空间。享元模式其实就是工厂模式的一个改进机制，享元模式同样要求创建一个或一组对象，并且就是通过工厂方法生成对象的，只不过享元模式中为工厂方法增加了缓存这一功能。主要总结为以下应用场景：

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

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

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


    public void showInfo(String bunk) {
        this.price = new Random().nextInt(500);
        System.out.println(String.format("%s->%s：%s价格：%s 元", this.from, this.to, bunk, this.price));
    }
}

　　最后创建工厂类：

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("硬座");
    }
}

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

class TicketFactory {
    private static Map<String, ITicket> sTicketPool = new ConcurrentHashMap<String,ITicket>();

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

　　其中ITicket就是抽象享元角色， Train Ticket就是具体享元角色， Ticket Factory就是享元工厂。有些小伙伴一定会有疑惑了，这不就是注册式单例模式吗?对，这就是注册式单例模式。虽然，结构上很像， 但是享元模式的重点在结构上， 而不是在创建对象上。

享元模式的内部状态和外部状态：

　　享元模式的定义为我们提出了两个要求：细粒度和共享对象。因为要求细粒度对象，所以不可避免地会使对象数虽多且性质相近，此时我们就将这些对象的信息分为两个部分：内部状态和外部状态。内部状态指对象共享出来的信息，存储在享元对象内部并且不会随环境的改变而改变；外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。比如， 连接池中的连接对象， 保存在连接对象中的用户名、密码、连接url等信息， 在创建对象的时候就设置好了，不会随环境的改变而改变，这些为内部状态。而每个连接要回收利用时，我们需要给它标记为可用状态，这些为外部状态。

优点：

• 减少对象的创建，降低内存中对象的数量，降低系统的内存，提高效率；
• 减少内存之外的其他资源占用。

缺点：

• 关注内、外部状态、关注线程安全问题；
• 使系统、程序的逻辑复杂化。