定义
享元模式，Flyweight Pattern，轻量模式？如果不熟悉，光从字面上很难能理解具体的意思，根据定义享元模式是运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模式。
其实根据定义还是比较晦涩，其实享元模式面对最重要的场景，或者问题就是在内存有限的情况下，通过共享多个对象所共有的相同状态，能载入更多对象。我们常用的一些技术，比如池技术，缓存等等都是享元模式的一种应用。
享元模式的核心在于享元工厂类，享元工厂类的作用在于提供一个用于存储享元对象的享元池，用户需要对象时，首先从享元池中获取，如果享元池中不存在，则创建一个新的享元对象返回给用户，并在享元池中保存该新增对象。
享元模式以共享的方式高效地支持大量的细粒度对象，享元对象能做到共享的关键是区分内部状态和外部状态。
- 内部状态是存储在享元对象内部并且不会随环境改变而改变的状态，因此内部状态可以共享。
- 外部状态是随环境改变而改变的、不可以共享的状态。享元对象的外部状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。一个外部状态与另一个外部状态之间是相互独立的。
实例
网上已经 有很多的文章介绍享元模式具体的代码分析，这里用一个实际例子来说明。在知乎上有个问题，《超级马里奥3》使用了什么样的技术可以在128KB中写进这么多东西？ ，而当时FC游戏机主存和显示内存为2KB，但是超级马里奥却有八个场景，每个场景又有四个小关，在这种条件下，就非常符合享元模式的使用场景，可是它又是怎么实现的呢？
我们来看超级马里奥第一关的所有场景
如果这里面的每一个贴图都是一个新的对象，那2kb的内存早就撑爆，其实我们可以发现，里面很多东西都是重复，比如地砖，下水管，山脉，云朵，和草地，下水管只是长短不一，但是形状是一样的，云朵和地上的草地，也只是颜色不同，形状是一样的。
由上图我们可以看到，FC 版本的《超级马里奥兄弟》看似有这么多关卡，其实出现过的东西就这么多，里面的水管只是颜色不同，里面的蘑菇，乌龟，砖块等等很多只是改变了颜色，更有食人花和星星其实是只是半张图，如下图
其实我们通过这个例子来理解享元模式，享元对象能做到共享的关键是区分内部状态和外部状态。游戏里的内部状态就是各种元素的形状，而外部状态就是颜色和位置，在第一关中有山脉，云朵，地砖，墙块，金币块，石头，水管，旗子，旗杆，城堡(城堡也砖块是拼起来的)，这些都是属于享元，在游戏中渲染需要时，会从享元池中获取，如果池中没有就创建新的，并保存在池中，这样其实在游戏中看似元素很多，其实只是这几个模块颜色位置变化渲染，从而达到了在内存资源极其紧缺的情况下，制作出丰富的游戏内容。
不可变性
由于享元对象可在不同的情景中使用， 你必须确保其状态不能被修改。 享元类的状态只能由构造函数的参数进行一次性初始化， 它不能对其他对象公开其设置器或公有成员变量。这也就以为着享元模式的内部状态是线程安全的，在并发的模式下不需要加锁实现线程安全，不需要用一些锁机制等保证内存一致性问题也减少了同步开销。在 Java的JDK中String，Long，Integer，Byte等这些基本数据类型在设计时，就使用了享元模式，节省了内存的同时也满足了不可变性的要求，所以当面对有并发的场景，同时又要考虑内存问题，就可以考虑享元模式了。
在我们的代码中，经常要传递容器类的对象，比如Map，Set， List 等。 在这样的传递中，通常很少考虑不可变性。 作为应用的开发者， 这样写问题不大。 但是作为框架的开发者，提供library给外部用户， 如果不考虑这些问题通常就会导致一些问题。比如返回一个HashMap, 如果这个对象在遍历的时候，有新的对象插入就会有并发的问题。 那么这个HashMap到底希望拿到这个对象的用户修改，还是不希望他们修改。
如果不希望修改，那么就应该做成immutable的， 首先不会出现上文提到的并发调用的冲突问题，其实immutalbe 的对象是不用考虑并发的问题的，它是天然线程安全的。
如果希望修改，通常就考虑返回线程安全的容器，比如ConcurrentHashMap 之类。
