前言：
为什么之前写过Golang 版的设计模式，还在重新写Java 版？
答：因为对于我而言，当然也希望对正在学习的大伙有帮助。Java作为一门纯面向对象的语言，更适合用于学习设计模式。
为什么类图要附上uml
因为很多人学习有做笔记的习惯，如果单纯的只是放一张图片，那么学习者也只能复制一张图片，可复用性较低，附上uml，方便有新理解时，快速出新图。
当一个软件系统在运行时产生的对象数量太多，将导致运行代价过高，带来系统性能下降等问题。例如，在一个文本字符串中存在很多重复的字符，如果每个字符都用一个单独的对象来表示，将会占用较多的内存空间。
那么，如何去避免系统中出现大量相同或相似的对象，同时又不影响客户端程序通过面向对象的方式对这些对象进行操作？享元模式正为解决这一类问题而诞生。
享元模式通过共享技术实现相同或相似对象的重用。在逻辑上每个出现的字符都有一个对象与之对应，然而在物理上它们却共享同一个享元对象。这个对象可以出现在一个字符串的不同地方，相同的字符对象都指向同一个实例。在享元模式中，存储这些共享实例对象的地方称为享元池（Flyweight Pool）。可以针对每个不同的字符创建一个享元对象，将其放在享元池中，需要时再从享元池取出，如图所示。
享元模式以共享的方式高效地支持大量细粒度对象的重用。享元对象能做到共享的关键是区分了内部状态（Intrinsic State）和外部状态（Extrinsic State）。下面对享元的内部状态和外部状态进行简单介绍。
（1）内部状态是存储在享元对象内部并且不会随环境改变而改变的状态，内部状态可以共享。例如字符的内容，不会随外部环境的变化而变化，无论在任何环境下，字符“a”始终是“a”，都不会变成“b”。
（2)外部状态是随环境改变而改变的、不可以共享的状态。享元对象的外部状态通常由客户端保存，并在享元对象被创建之后，需要使用的时候，再传入享元对象内部。一个外部状态与另一个外部状态之间是相互独立的。如字符的颜色，可以在不同的地方有不同的颜色，例如有的“a”是红色的，有的“a”是绿色的；字符的大小也是如此，有的“a”是五号字，有的“a”是四号字。而且字符的颜色和大小是两个独立的外部状态，它们可以独立变化，相互之间没有影响，客户端可以在使用时将外部状态注入享元对象中。
正因为区分了内部状态和外部状态，可以将具有相同内部状态的对象存储在享元池中，享元池中的对象是可以实现共享的，需要的时候就将对象从享元池中取出，实现对象的复用。通过向取出的对象注入不同的外部状态，可以得到一系列相似的对象，而这些对象在内存中实际上只存储一份。
享元模式定义如下：
享元模式（Flyweight Pattern）：运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，是一种对象结构型模式。
享元模式结构较为复杂，一般结合工厂模式一起使用，在其结构图中包含了一个享元工厂类
@startuml class FlyWeightFactory { - flyWeights: HashMap + getFlyWeight(String key): FlyWeight } note left of FlyWeightFactory::getFlyWeight if(!flyWeights.containsKey(key)) { flyWeights.put(key, new ConcreteFlyWeight); } return flyWeights.get(key); end note interface FlyWeight { + operation(extrinsicState) } class ConcreteFlyWeight implements FlyWeight { - intrinsicState + operation(extrinsicState) } class UnsharedConcreteFlyWeight implements FlyWeight { - allState + operation(extrinsicState) } FlyWeightFactory *-right-> FlyWeight: flyWeights @enduml
在享元模式结构图中包含以下4个角色。
（1）Flyweight（抽象享元类）：是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）。
（2）ConcreteFlyweight（具体享元类）：它实现了抽象享元类，其实例称为享元对象。在具体享元类中为内部状态提供了存储空间。通常，可以结合单例模式来设计具体享元类，为每个具体享元类提供唯一的享元对象。
（3）UnsharedConcreteFlyweight（非共享具体享元类）：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类。当需要一个非共享具体享元类的对象时可以直接通过实例化创建。
（4）FlyweightFactory（享元工厂类）：享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中。享元池一般设计为一个存储“键值对”的集合（也可以是其他类型的集合），可以结合工厂模式进行设计。当用户请求一个具体享元对象时，享元工厂提供一个存储在享元池中已创建的实例，或者创建一个新的实例（如果不存在的话)并返回新创建的实例，同时将其存储在享元池中。
在享元模式中引入了享元工厂类。享元工厂类的作用在于提供一个用于存储享元对象的享元池。当用户需要对象时，首先从享元池中获取，如果享元池中不存在，则创建一个新的享元对象返回给用户，并在享元池中保存该新增对象。
简单代码实现
package struct; import java.util.HashMap; import java.util.Map; public class FlyWeightDemo { // FlyWeightFactory class public static class FlyWeightFactory { private final Map<String, FlyWeight> flyWeights = new HashMap<>(); public FlyWeight getFlyWeight(String key) { if (!flyWeights.containsKey(key)) { flyWeights.put(key, new ConcreteFlyWeight(key)); } return flyWeights.get(key); } } // FlyWeight interface public interface FlyWeight { void operation(String extrinsicState); } // ConcreteFlyWeight class public static class ConcreteFlyWeight implements FlyWeight { private final String intrinsicState; public ConcreteFlyWeight(String key) { this.intrinsicState = key; } // 外部状态由外部设置，内部状态复用 @Override public void operation(String extrinsicState) { // Implementation of the operation method // intrinsicState can be used here System.out.println("ConcreteFlyWeight operation: intrinsicState=" + intrinsicState + ", extrinsicState=" + extrinsicState); } } // UnsharedConcreteFlyWeight class public static class UnsharedConcreteFlyWeight implements FlyWeight { private final String allState; public UnsharedConcreteFlyWeight(String allState) { this.allState = allState; } @Override public void operation(String extrinsicState) { // Implementation of the operation method // allState can be used here System.out.println("UnsharedConcreteFlyWeight operation: allState=" + allState + ", extrinsicState=" + extrinsicState); } } // Client using FlyWeightFactory public static void main(String[] args) { FlyWeightFactory flyWeightFactory = new FlyWeightFactory(); FlyWeight flyWeight1 = flyWeightFactory.getFlyWeight("毛笔"); flyWeight1.operation("红色"); FlyWeight flyWeight2 = flyWeightFactory.getFlyWeight("毛笔"); flyWeight2.operation("黑色"); // UnsharedConcreteFlyWeight is created here FlyWeight unsharedFlyWeight = new UnsharedConcreteFlyWeight("uniqueState"); unsharedFlyWeight.operation("uniqueExtrinsicState"); } }
输出
ConcreteFlyWeight operation: intrinsicState=毛笔, extrinsicState=红色 ConcreteFlyWeight operation: intrinsicState=毛笔, extrinsicState=黑色 UnsharedConcreteFlyWeight operation: allState=uniqueState, extrinsicState=uniqueExtrinsicState
单纯享元模式和复合享元模式
标准的享元模式结构图中既包含可以共享的具体享元类，也包含不可以共享的非共享具体享元类。但是在实际使用过程中，有时候会用到两种特殊的享元模式：单纯享元模式和复合享元模式。下面对这两种特殊的享元模式进行简单介绍。
单纯享元模式
在单纯享元模式中，所有的具体享元类都是可以共享的，不存在非共享具体享元类。单纯享元模式的结构如图14-6所示。
@startuml class FlyWeightFactory { - flyWeights: HashMap + getFlyWeight(String key): FlyWeight } note left of FlyWeightFactory::getFlyWeight if(!flyWeights.containsKey(key)) { flyWeights.put(key, new ConcreteFlyWeight); } return flyWeights.get(key); end note interface FlyWeight { + operation(extrinsicState) } class ConcreteFlyWeight implements FlyWeight { - intrinsicState + operation(extrinsicState) } FlyWeightFactory *-right-> FlyWeight: flyWeights @enduml
复合享元模式
将一些单纯享元对象使用组合模式加以组合，还可以形成复合享元对象。这样的复合享元对象本身不能共享，但是它们可以包括单纯享元对象，而后者则可以共享。
@startuml class FlyWeightFactory { - flyWeights: HashMap + getFlyWeight(String key): FlyWeight } note left of FlyWeightFactory::getFlyWeight if(!flyWeights.containsKey(key)) { flyWeights.put(key, new ConcreteFlyWeight); } return flyWeights.get(key); end note interface FlyWeight { + operation(extrinsicState) } class ConcreteFlyWeight implements FlyWeight { - intrinsicState + operation(extrinsicState) } class CompositeConcreteFlyWeight implements FlyWeight { - flyWeights + operation(extrinsicState) + add(FlyWeight flyWeight) + remove(FlyWeight flyWeight) } CompositeConcreteFlyWeight *--> FlyWeight: 组合享元 FlyWeightFactory *-right-> FlyWeight: flyWeights @enduml
扩展
与其他模式的联用
享元模式通常需要和其他模式一起联用，几种常见的联用方式如下：
（1）在享元模式的享元工厂类中通常提供一个静态的工厂方法用于返回享元对象，使用简单工厂模式来生成享元对象。
（2）在一个系统中，通常只有唯一一个享元工厂，因此可以使用单例模式进行享元工厂类的设计。
（3）享元模式可以结合组合模式形成复合享元模式，统一对多个享元对象设置外部状态。
享元模式与String类
JDK类库中的String类使用了享元模式，通过如下代码来加以说明：
public class StringTest { public static void main(String[] args) { String str1 = "abcd"; String str2 = "abcd"; String str3 = "ab"+"cd"; String str4 = "ab"; str4 += "cd"; System.out.println(str1 == str2); // true System.out.println(str1 == str3); // true System.out.println(str1 == str4); // false str2 += "e"; System.out.println(str1 == str2); // false } }
在Java语言中，如果每次执行类似String str1＝＂abcd＂的操作时都创建一个新的字符串对象，将导致内存开销很大。因此，如果第一次创建了内容为＂abcd＂的字符串对象str1，下一次再创建内容相同的字符串对象str2时会将它的引用指向＂abcd＂，不会重新分配内存空间，从而实现了＂abcd＂在内存中的共享。上述代码输出结果如下：true true false false
可以看出，前两个输出语句均为true，说明str1、str2、str3在内存中引用了相同的对象。如果有一个字符串str4，其初值为＂ab＂，再对它进行str4+＝＂cd＂操作，此时虽然str4的内容与str1相同，但是由于str4的初始值不同，在创建str4时重新分配了内存，所以第3个输出语句结果为false。最后一个输出语句结果也为false，说明当对str2进行修改时将创建一个新的对象，修改工作在新对象上完成，而原来引用的对象并没有发生任何改变，str1仍然引用原有对象，而str2引用新对象，str1与str2引用了两个完全不同的对象。
Java String类这种在修改享元对象时，先将原有对象复制一份，然后在新对象上再实施修改操作的机制称为“Copy On Write”。
总结
当系统中存在大量相同或者相似的对象时，享元模式是一种较好的解决方案。它通过共享技术实现相同或相似的细粒度对象的复用，从而节约了内存空间，提高了系统性能。相比其他结构型设计模式，享元模式的使用频率并不算太高，但是作为一种以“节约内存，提高性能”为出发点的设计模式，它在软件开发中还是得到了一定程度的应用。
主要优点
享元模式的主要优点如下：
（1）可以极大减少内存中对象的数量，使得相同或相似对象在内存中只保存一份，从而可以节约系统资源，提高系统性能。
（2）享元模式的外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享。
主要缺点
享元模式的主要缺点如下：
（1）享元模式需要分离出内部状态和外部状态，从而使得系统变得复杂，这使得程序的逻辑复杂化。
（2）为了使对象可以共享，享元模式需要将享元对象的部分状态外部化，而读取外部状态将使得运行时间变长。
适用场景
在以下情况下可以考虑使用享元模式：
（1）一个系统有大量相同或者相似的对象，造成内存的大量耗费。
（2）对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。
（3）在使用享元模式时需要维护一个存储享元对象的享元池，而这需要耗费一定的系统资源。因此，在需要多次重复使用同一享元对象时才值得使用享元模式。
🚀 作者简介：作为某云服务提供商的后端开发人员，我将在这里与大家简要分享一些实用的开发小技巧。在我的职业生涯中积累了丰富的经验，希望能通过这个博客与大家交流、学习和成长。技术栈：Java、Golang、PHP、Python、Vue、React
![[Java]23种设计模式](https://ucc.alicdn.com/3mfxe2r26qbaq/developer-article1631534/20241030/75e0b318e301432d84f68edea4a889c7.png?x-oss-process=image/resize,h_160,m_lfit)
