一、引子
让 我们先来复习下java中String类型的特性：String类型的对象一旦被创造就不可改变；当两个String对象所包含的内容相同的时候，JVM 只创建一个String对象对应这两个不同的对象引用。让我们来证实下着两个特性吧（如果你已经了解，请跳过直接阅读第二部分）。
先来验证下第二个特性：
public class TestPattern {
public static void main(String[] args){
String n = "I Love Java";
String m = "I Love Java";
System.out.println(n==m);
}
}
这段代码会告诉你n==m是true，这就说明了在JVM中n和m两个引用了同一个String对象（如果你还分不清== 和 equals的区别的话，请先确认）。
那么接着验证下第一个特性：
在系统输出之前加入一行代码“m = m + "hehe";”，这时候n==m结果为false，为什么刚才两个还是引用相同的对象，现在就不是了呢？原因就是在执行后添加语句时，m指向了一个新创建的String对象，而不是修改引用的对象。
呵呵，说着说着就差点跑了题，并不是每个String的特性都跟我们今天的主题有关的。
String类型的设计避免了在创建N多的String对象时产生的不必要的资源损耗，可以说是享元模式应用的范例，那么让我们带着对享元的一点模糊的认识开始，来看看怎么在自己的程序中正确的使用享元模式！
注：使用String类型请遵循《Effective Java》中的建议。
二、定义与分类
享 元模式英文称为“Flyweight Pattern”，我非常感谢将Flyweight Pattern翻译成享元模式的那位强人，因为这个词将这个模式使用的方式明白得表示了出来；如果翻译成为羽量级模式或者蝇量级模式等等，虽然可以含蓄的 表现出使用此模式达到的目的，但是还是没有抓住此模式的关键。
享元模式的定义为：采用一个共享来避免大量拥有相同内容对象的开销。这种开销中最常见、直观的就是内存的损耗。享元模式以共享的方式高效的支持大量的细粒度对象。
在 名字和定义中都体现出了共享这一个核心概念，那么怎么来实现共享呢？要知道每个事物都是不同的，但是又有一定的共性，如果只有完全相同的事物才能共享，那 么享元模式可以说就是不可行的；因此我们应该尽量将事物的共性共享，而又保留它的个性。为了做到这点，享元模式中区分了内蕴状态和外蕴状态。内蕴状态就是 共性，外蕴状态就是个性了。
注：共享的对象必须是不可变的，不然一变则全变（如果有这种需求除外）。
内
蕴状态存储在享元内部，不会随环境的改变而有所不同，是可以共享的；外蕴状态是不可以共享的，它随环境的改变而改变的，因此外蕴状态是由客户端来保持（因
为环境的变化是由客户端引起的）。在每个具体的环境下，客户端将外蕴状态传递给享元，从而创建不同的对象出来。至于怎样来维护客户端保持的外蕴状态和享元
内部保持的内蕴状态的对应关系，你先不用担心这个问题，我们后面会涉及到的。
我们引用《Java与模式》中的分类，将享元模式分为：单纯享元模式和复合享元模式。在下一个小节里面我们将详细的讲解这两种享元模式。
三、结构
先从简单的入手，看看单纯享元模式的结构。
1) 抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。在Java中可以由抽象类、接口来担当。
2) 具体享元角色：实现抽象角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3) 享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键！
4) 客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。
来用类图来形象地表示出它们的关系吧（对类图的了解可以参看我关于类图的blog）。
怎 么咋看咋像简单工厂模式呢！没错，可以说结构型的单纯享元模式和创建型的简单工厂模式实现上非常相似，但是它的重点或者用意却和工厂模式截然不同。工厂模 式的使用主要是为了使系统不依赖于实现得细节（见《深入浅出工厂模式》）；而在享元模式的主要目的如前面所述：采用共享技术来避免大量拥有相同内容对象的 开销。正所谓“旧瓶装新酒”阿！
再来看看复合享元模式的结构。
1) 抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。在Java中可以由抽象类、接口来担当。
2) 具体享元角色：实现抽象角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3) 复合享元角色：它所代表的对象是不可以共享的，并且可以分解成为多个单纯享元对象的组合。
4) 享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键！
5) 客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。
统比一下单纯享元对象和复合享元对象，里面只多出了一个复合享元角色，但是它的结构就发生了很大的变化。我们还是使用类图来表示下：
你 也许又纳闷了，这个也似曾相逢！单看左半部，和简单工厂模式类似；再看右半部，怎么这么像合成模式呢（请参看关于合成模式的文章或者期待我的《深入浅出合 成模式》）！合成模式用在此处就是为了将具体享元角色和复合享元角色同等对待和处理，通过将享元模式与合成模式组合在一起，可以确保复合享元中所包含的每 个单纯享元都具有相同的外蕴状态，而这些单纯享元的内蕴状态往往是不同的。
五、使用优缺点
享元模式优点就在于它能够大幅度的降低内存中对象的数量；而为了做到这一步也带来了它的缺点：它使得系统逻辑复杂化，而且在一定程度上外蕴状态影响了系统的速度。
所以一定要切记使用享元模式的条件：
1) 系统中有大量的对象，他们使系统的效率降低。
2) 这些对象的状态可以分离出所需要的内外两部分。
外
蕴状态和内蕴状态的划分以及两者关系的对应也是非常值得重视的。只有将内外划分妥当才能使内蕴状态发挥它应有的作用；如果划分失误，在最糟糕的情况下系统
中的对象是一个也不会减少的！两者的对应关系的维护和查找也是要花费一定的空间（当然这个比起不使用共享对象要小得多）和时间的，可以说享元模式就是使用
时间来换取空间的。在Gof的书中是使用了B树来进行对应关系查找优化。
六、总结
也许你要长叹一声：这个享元模式未必太复杂了吧！这点是不得不承认的，也许由于它的复杂，实际应用也不是很多，这是我们更加无法看清他的真面目了。不过享元模式并不是鸡肋，它的精髓——共享是对我们系统优化非常有好处的，而且这种思想已经别越来越多的应用，这应该就算是享元模式的应用了吧。如果你已经领会到了享元模式的精髓，那么也就是掌握了享元模式了!
解释一下概念：也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可以了，不必每个都去实例化一个对象。比如说一个文本系统，每个字母定
一个对象，那么大小写字母一共就是52个，那么就要定义52个对象。如果有一个1M的文本，那么字母是何其的多，如果每个字母都定义一个对象那么内存早就
爆了。那么如果要是每个字母都共享一个对象，那么就大大节约了资源。
在Flyweight模式中，由于要产生各种各样的对象，所以在Flyweight(享元)模式中常出现Factory模式。Flyweight的内
部状态是用来共享的,Flyweight factory负责维护一个对象存储池（Flyweight
Pool）来存放内部状态的对象。Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度.应用场合很多，下面举个例子：
先定义一个抽象的Flyweight类：
|
实现一个具体类：
|
实现一个工厂方法类：
|
这个工厂方法类非常关键，这里详细解释一下：
在1处定义了一个Hashtable用来存储各个对象；在2处选出要实例化的对象，在6处将该对象返回，如果在Hashtable中没有要选择的对
象，此时变量flyweight为null，产生一个新的flyweight存储在Hashtable中，并将该对象返回。
最后看看Flyweight的调用：
|
下面是运行结果：
|
我们定义了6个对象，其中有5个是相同的，按照Flyweight模式的定义“Google”应该共享一个对象，在实际的对象数中我们可以看出实际的对象却是只有2个。
总结：
Flyweight(享元)模式是如此的重要，因为它能帮你在一个复杂的系统中大量的节省内存空间。在JAVA语言中，String类型就是使用了享
元模式。String对象是final类型，对象一旦创建就不可改变。在JAVA中字符串常量都是存在常量池中的，JAVA会确保一个字符串常量在常量池
中只有一个拷贝。String a="abc"，其中"abc"就是一个字符串常量。
熟悉java的应该知道下面这个例子：
|
输出结果是：OK。可以看出if条件比较的是两a和b的地址，也可以说是内存空间
核心总结，可以共享的对象，也就是说返回的同一类型的对象其实是同一实例，当客户端要求生成一个对象时，工厂会检测是否存在此对象的实例，如果存在那么直 接返回此对象实例，如果不存在就创建一个并保存起来，这点有些单例模式的意思。通常工厂类会有一个集合类型的成员变量来用以保存对象，如 hashtable,vector等。在java中，数据库连接池，线程池等即是用享元模式的应用。