这篇我们来介绍一下享元模式（Flyweight Pattern），Flyweight 代表轻量级的意思，享元模式是对象池的一种实现。享元模式用来尽可能减少内存使用量，它适合用于可能存在大量重复对象的场景，缓存可共享的对象，来达到对象共享和避免创建过多对象的效果，这样一来就可以提升性能，避免内存移除和频繁 GC 等。
享元模式的一个经典使用案例是文本系统中图形显示所用的数据结构，一个文本系统能够显示的字符种类就是那么几十上百个，那么就定义这么些基础字符对象，存储每个字符的显示外形和其他的格式化数据等，而不用每次都去新建对象，这样就可以避免创建成千上万的重复对象，大大提高对象的重用率。
转载请注明出处：http://blog.csdn.net/self_study/article/details/51870660。
PS：对技术感兴趣的同鞋加群544645972一起交流。
设计模式总目录
特点
使用共享对象可有效地支持大量细粒度的对象。
共享模式支持大量细粒度对象的复用，所以享元模式要求能够共享的对象必须是细粒度对象。在了解享元模式之前我们先要了解两个概念：内部状态、外部状态：
- 内部状态：在享元对象内部不随外界环境改变而改变的共享部分；
- 外部状态：随着环境的改变而改变，不能够共享的状态就是外部状态。
由于享元模式区分了内部状态和外部状态，所以我们可以通过设置不同的外部状态使得相同的对象可以具备一些不同的特性，而内部状态设置为相同部分。在我们的程序设计过程中，我们可能会需要大量的细粒度对象，如果这些对象除了几个参数不同外其他部分都相同，这个时候我们就可以利用享元模式来大大减少应用程序当中的对象。如何利用享元模式呢？这里我们只需要将他们少部分的不同的状态当做参数移动到类实例的外部去，然后在方法调用的时候将他们传递过来就可以了。这里也就说明了一点：内部状态存储于享元对象内部，而外部状态则应该由客户端来考虑。
享元模式与对象池模式对比
看了上面的特征会让我们想到对象池模式，确实，对象池模式和享元模式有很多的相同点，但是他们有一个很重要的不同点：享元模式通常情况下获取的是不可变的实例，而从对象池模式中获取的对象通常情况下是可变的。所以使用享元模式用来避免创建多个拥有同样状态的对象，只创建一个并且在应用的不同地方都使用这一个实例；而对象池中的资源从使用的角度上看具有不同的状态并且每个都需要单独控制，但是又不想花费一定的资源区频繁的创建和销毁这些资源对象，毕竟他们都有相同的初始化过程。
简而言之，享元模式更加倾向于状态的不可变性，而对象池模式则是状态的可变性。
UML类图
享元模式的 uml 类图如下：
- Flyweight：
- ConcreteFlyweight：
- UnsharedConcreteFlyweight：
- FlyweightFactory：
享元对象抽象基类或者接口；
具体的享元对象；
非共享具体享元类，指出那些不需要共享的Flyweight子类；
享元工厂，负责管理享元对象池和创建享元对象。
据此我们可以写出享元模式的基础代码：
Flyweight.class
public interface Flyweight {
void operation();
}ConcreteFlyweight.class
public class ConcreteFlyweight implements Flyweight{
private String intrinsicState;
public ConcreteFlyweight(String state) {
intrinsicState = state;
}
@Override
public void operation() {
Log.e("Shawn", "ConcreteFlyweight----" + intrinsicState);
}
}FlyweightFactory.class
public class FlyweightFactory {
private HashMap<String, Flyweight> mFlyweights = new HashMap<>();
public Flyweight getFlyweight(String key) {
Flyweight flyweight = mFlyweights.get(key);
if (flyweight == null) {
flyweight = new ConcreteFlyweight(key);
mFlyweights.put(key, flyweight);
}
return flyweight;
}
}测试代码
Flyweight flyweight1 = factory.getFlyweight("a");
Flyweight flyweight2 = factory.getFlyweight("b");
Flyweight flyweight3 = factory.getFlyweight("a");
Log.e("Shawn", "flyweight1==flyweight2 : " + (flyweight1 == flyweight2));
Log.e("Shawn", "flyweight1==flyweight3 : " + (flyweight1 == flyweight3));
break;结果
com.android.flyweightpattern E/Shawn: flyweight1==flyweight2 : false
com.android.flyweightpattern E/Shawn: flyweight1==flyweight3 : true可以很明显的看出 flyweight1 和 flyweight3 对象是同样一个享元对象。
Java 中的享元模式
在 Java 中，最经典使用享元模式的案例就应该是 String 了，String 存在常量池中，也就是说一个 String 被定义之后它就被缓存到了常量池中，当其他地方要使用同样的字符串时，则直接使用该缓存，而不会重复创建（这也就是 String 的不可变性：java/android 设计模式学习笔记（11）—原型模式）。
比如下面的代码：
String str1 = new String("abc");
String str2 = new String("abc");
String str3 = "abc";
String str4 = "ab" + "c";
str1 == str2; //false
str3 == str4; //truestr1 和 str2 是两个不同的对象，这个应该显而易见，而 str3 和 str4 由于都是使用的 String 享元池，所以他们两个是同一个对象。
示例与源码
我们这以一个图形系统为例，用来画不同颜色的圆形：
Shape.class用来定义一个图形的基本行为：
public interface Shape {
void draw();
}Circle.class Shape 的实现子类，用来画圆形：
public class Circle implements Shape{
String color;
public Circle(String color) {
this.color = color;
}
@Override
public void draw() {
Log.e("Shawn", "画了一个" + color +"的圆形");
}
}ShapeFactory.class 图形享元工厂类：
public class ShapeFactory {
private HashMap<String, Shape> shapes = new HashMap<>();
public Shape getShape(String color) {
Shape shape = shapes.get(color);
if (shape == null) {
shape = new Circle(color);
shapes.put(color, shape);
}
return shape;
}
public int getSize() {
return shapes.size();
}
}测试代码
Shape shape1 = factory.getShape("红色");
shape1.draw();
Shape shape2 = factory.getShape("灰色");
shape2.draw();
Shape shape3 = factory.getShape("绿色");
shape3.draw();
Shape shape4 = factory.getShape("红色");
shape4.draw();
Shape shape5 = factory.getShape("灰色");
shape5.draw();
Shape shape6 = factory.getShape("灰色");
shape6.draw();
Log.e("Shawn", "一共绘制了"+factory.getSize()+"中颜色的圆形");最后运行结果
从结果可以看到，同一个颜色的图形共用一个对象，总共只创建了 3 个对象。
总结
享元模式实现比较简单，但是它的作用在某些场景确实极其重要。它可以大大减少应用程序创建对象的数量和频率，降低程序内存的占用，增强程序的性能，但它同时也增加了系统的复杂性，需要分离出外部状态和内部状态，内部状态为不变的共享部分，存储于享元对象内部；而外部状态具有固化特性，应当由客户端来负责，不应该随着内部状态改变而改变，否则会导致系统的逻辑混乱。
享元模式优点：
- 能够极大的减少系统中对象的个数；
- 享元模式由于使用了外部状态，外部状态相对独立，不会影响到内部状态，所以享元模式使得享元对象能够在不同的环境中被共享。
享元模式缺点：
- 由于享元模式需要区分外部状态和内部状态，使得应用程序在某种程度上来说更加复杂化了；
- 为了使对象可以共享，享元模式需要将享元对象的状态外部化，而读取外部状态使得运行时间变长。
讨论
我在查阅相关书籍和网络资料的过程中，看到有些文章会把 Android 中的 MessagePool 定义为享元模式，但是对比了对象池模式和享元模式之后，我更倾向于认为它是对象池模式，因为从上面介绍的对比来看，MessagePool 中对象池有初始化的 size，每次从 MessagePool 中去 obtain Message 对象的时候，获取的都是一个初始对象，其中的状态都需要去根据需求变化，而享元模式则更倾向于重用具有相同状态的对象，这个对象着重于在应用的每个使用地方它的状态都具有相同性，从这个原则来看就已经排除是享元模式了，不过还是个人的看法，有没有大神指导一下，不胜感激~~~~
源码下载
https://github.com/zhaozepeng/Design-Patterns/tree/master/FlyweightPattern
引用
http://stackoverflow.com/questions/9322141/flyweight-vs-object-pool-patterns-when-is-each-useful
http://blog.csdn.net/jason0539/article/details/22908915
https://en.wikipedia.org/wiki/Flyweight_pattern
http://www.cnblogs.com/qianxudetianxia/archive/2011/08/10/2133659.html