（12）Java设计模式 - 享元模式（Flyweight Pattern）

介绍

一个系统中若存在大量相同或相似的对象（比如26个英文字母），则只共享一份就可以了（并非单例模式），没有必要为每份相同的东西还都单独实例化出一个对象，浪费性能。（有点缓存的意思）

比如26个英文字母，一个文本中有10MB的26个英文字母，那你解析出来的时候需要为每一个字母都创建一个对象的话（10M那么大，对象数不可直视。。。），内存肯定扛不住。所以可以用享元模式，只创建26个对象进行共享就行了。

那么什么时候使用此模式呢？

一个应用程序使用了大量（少量的话完全没必要）的对象。

完全由于使用大量的对象，造成很大的存储开销。（对象存到堆内存，对象太多，堆内存扛不住的时候）

对象的大多数状态都可变为外部状态

如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组成对象

应用程序不依赖对象标识。

结构

主要角色：

• Flyweight（抽象享元）：此角色是所有的具体享元类的超类，为这些类规定出需要实现的公共接口或抽象类。那些需要外部状态(External State)的操作可以通过方法的参数传入。抽象享元的接口使得享元变得可能，但是并不强制子类实行共享，因此并非所有的享元对象都是可以共享的。
• ConcreteFlyweight（具体享元）：实现抽象享元角色所规定的接口。如果有内部状态的话，必须负责为内部状态提供存储空间。享元对象的内部状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享。有时候具体享元角色又叫做单纯具体享元角色，因为复合享元角色是由单纯具体享元角色通过复合而成的。
• UnsharableFlyweight（复合享元）：复合享元角色所代表的对象是不可以共享的，但是一个复合享元对象可以分解成为多个本身是单纯享元对象的组合。复合享元角色又称作不可共享的享元对象。这个角色一般很少使用。
• FlyweightFactory（享元工厂）：本角色负责创建和管理享元角色。本角色必须保证享元对象可以被系统适当地共享。当一个客户端对象请求一个享元对象的时候，享元工厂角色需要检查系统中是否已经有一个符合要求的享元对象，如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个新的合适的享元对象。
• Client（客户端）：本角色还需要自行存储所有享元对象的外部状态。

内部状态与外部状态

在享元对象内部并且不会随着环境改变而改变的共享部分，可以称之为享元对象的内部状态，反之随着环境改变而改变的，不可共享的状态称之为外部状态。

案例

实体

抽象享元角色

具体享元角色

享元工厂角色

测试类

结果表明，本来需要四个对象，运用享元模式后，只用了两个对象。减少了一半。建议在大量对象的时候使用。

优缺点

优点：

1. 大幅度地降低内存中对象的数量，减缓堆内存压力。

缺点：

1. 享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
2. 享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。

总的来说，享元模式一般是解决系统性能问题的，所以经常用于底层开发，在项目开发中并不常用。

JDK中的享元模式

Integer、Lang、Byte、String等都用到了享元模式

Integer、Lang、Byte中的valueOf()方法用到了享元模式，String常量池就是享元模式。

实例来验证我的说法

解释：

（1）String的常量池即用到了享元模式，所以为true。他首先检查常量池中是否有str这个值，若有则直接指向，不会重新创建String对象。（共享），但是每次都new String的话是不行的，因为jvm遇到new指令后就会创建一个对象出来，无法沿用常量池。

（2）（3）（4）（5）（6）（7）是因为Integer（Long、Byte等）内部维护着一个Cache，用于共享。可以查看Integer的源码，如下：（Long、Byte也是一样的）

Integer享元模式源码

可发现，若值在-128~127之间，是可以直接从Cache中获取的，好比String常量池，直接从池中获取，无需new。若不再这范围内，才会去new Integer(i)返回新对象。否则共享。所以享元模式来减少对象数目，达到优化还是很牛的。