AI创造的视频中的各种“生命体”在现实世界中是不存在的，如果他们有所谓的“意识”真的可以称之为“生命”的话。他们的世界是我们世界的投影，在那个世界里“生活”的“人”其实并不清楚他们的世界是怎么来的，就像现在的我们一样。
就像电影《异次元骇客》所描述的一样，每个世界都是更高一级世界的投影，每个人都是NPC，每当上层世界的玩家“登录”，下层的意识就会被抢占。所以有些人会突然发神经仿佛人格分裂一样，就好比GTA5中的老麦在你打开游戏前是一个好父亲，而在你打开游戏后变成了砍天砍地的恶棍。时不时他还会冒出来一句：“Oh, my goodness, what have I done？！”
幻想总是能让人思绪飞扬，今天我想从“夺舍”这个角度来讲一讲设计模式中的享元模式。
一言
享元模式，旨在通过共享对象来减少内存使用量并提高性能。它适用于那些由于对象内部状态重复而导致大量内存消耗的场景。
对下一层世界的秩序设计
我们假定你的几行代码就可以设计出一个比你低一个层次的世界，那么你打算如何实现“每个人都是NPC，每当上层世界的玩家登录，下层的意识就会被抢占”这一需求呢？
核心代码Ctrl CV？
“欸，我直接copy走起”，相信大家第一时间想到的都是这个设计。
的确是通俗易懂，传统的定制化编程实现，但也确实存在很多的隐患。
分析
几个玩家操控的NPC相似度这么高，如果分多个虚拟空间来处理，相当于一个NPC占用了多个实例，造成了极大的内存浪费。
那么有没有一种可能，我们将这些NPC实例整合到一个NPC中（让他拥有多个人格），对于硬盘、内存、CPU、数据库空间等服务器资源都可以达成共享，是不是就减少了服务器资源的浪费呢？
对于代码而言，我们也后期也只需要维护和扩展一份，这样的思路是不是更好呢？
享元模式
也许乍一听这个名词很多朋友会一愣，觉得自己从未接触过这个设计模式，实际上它非常的常见。比如说数据库连接池的设计，里面都是创建好的连接对象，在这些连接对象中有我们需要的就直接拿来用，没有就创建一个。
在这种思路下，解决了重复对象的内存浪费问题，当系统中存在大量相似对象，需要缓冲池时，不再需要创建新对象，而是直接在缓冲池里拿。
不光是数据库连接池，String 常量池 ，缓冲池等等都是享元模式的应用，也是池技术的重要实现方式。
设计
- FlyWeight 是抽象的享元角色，它是产品的抽象类，同时定义出对象的外部状态和内部状态的接口或实现；
- ConcreteFlyWeight 是具体的享元角色，是具体的产品类，实现抽象角色自定义相关业务；
- UnsharedConcreteFlyWeight 是不可共享的角色，一般不会出现在享元工厂中；
- FlyWeightFactory 享元工厂类，用于构建一个池容器（集合），同时提供从池中获取对象的方法；
内部状态与外部状态
享元模式有两个要求：细粒度和共享对象。这里就涉及到内部状态和外部状态了。那么什么是内部状态和外部状态呢？
通俗的讲，大家都玩过王者荣耀或者英雄联盟这类的MOBA游戏，召唤师峡谷的地图信息和地图资源是基本固定的，而每局游戏参战的英雄，英雄的位置、状态、技能等信息则是千变万化的。在这个例子中：
- 地图是内部状态，地图上野怪的属性和状态是外部状态
- 英雄模型是内部状态，英雄的血量、等级等变化的是外部状态
内部状态指对象共享出来的信息，存储在享元对象内部且不会随环境的改变而改变。外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。
可以试想以下，如果不采用享元模式，类似的游戏（PUBG、棋牌类游戏等）每一局都构建一整套资源有多么恐怖。
代码实现
现在我们开始编辑对NPC人格的入侵程序：
玩家
public class User {
private String name;
public User(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
NPC
public abstract class NPC {
public abstract void use(User user);//抽象方法
}
NPC享元角色
public class ConcreteNPC extends NPC{
private String type = "";
public ConcreteNPC(String type) {
this.type = type;
}
@Override
public void use(User user) {
System.out.println("NPC的人格切换为："+type+"，在使用中.. 使用者为："+user.getName());
}
}
NPC享元工厂
public class NPCFactory {
private HashMap<String,ConcreteNPC> pool = new HashMap<>();
public NPC getNpcCategory(String type){
if (!pool.containsKey(type)){
pool.put(type,new ConcreteNPC(type));
}
return (NPC) pool.get(type);
}
public int getNpcCount(){
return pool.size();
}
}
客户端
public class Client {
public static void main(String[] args) {
NPCFactory factory = new NPCFactory();
NPC npc1 = factory.getNpcCategory("圣人");
npc1.use(new User("Tom"));
NPC npc2 = factory.getNpcCategory("狂徒");
npc2.use(new User("Jack"));
NPC npc3 = factory.getNpcCategory("学者");
npc3.use(new User("Linda"));
NPC npc4 = factory.getNpcCategory("学者");
npc4.use(new User("Lucy"));
NPC npc5 = factory.getNpcCategory("学者");
npc5.use(new User("Amanda"));
System.out.println("NPC人格分类共："+factory.getNpcCount());
}
}
执行
可以看到，在当前的设计下，NPC的人格集中管理在享元工厂的池子中，当有新的玩家注入新的人格则会扩充这个池子的容量，如果没有新的人格加入，则会从池子中提取已有的人格注入到NPC体内。
享元模式在JDK-Integer源码中的应用
之前网上有这样一种论调：“国内IT行业程序员的面试已经越来越朝向八股化发展了。
面试造火箭，工作打螺丝”。
从某种角度来看，似乎说的是行业面试的现状。但从编程基础的角度考虑，有些八股本身不是问题，问题是很多朋友没有真正理解八股描述的底层原理，全靠死记硬背。
比如说下面这个面试题：
Integer a = Integer.valueOf(127);
Integer b = new Integer(127);
Integer c = Integer.valueOf(127);
Integer d = new Integer(127);
System.out.println(a.equals(b));
System.out.println(a==b);
System.out.println(a==c);
System.out.println(d==a);
System.out.println(d==b);
八股文只会告诉你，上面的结果是：
但我觉得这不是我们要去背的东西，我们要理解为什么是这样的结果。这个结果其实就源自Integer的享元模式，我们先看下源码。
相关源码片
/**
* Cache to support the object identity semantics of autoboxing for values between
* -128 and 127 (inclusive) as required by JLS.
*
* The cache is initialized on first usage. The size of the cache
* may be controlled by the {@code -XX:AutoBoxCacheMax=<size>} option.
* During VM initialization, java.lang.Integer.IntegerCache.high property
* may be set and saved in the private system properties in the
* sun.misc.VM class.
*/
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
try {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
} catch( NumberFormatException nfe) {
// If the property cannot be parsed into an int, ignore it.
}
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
// range [-128, 127] must be interned (JLS7 5.1.7)
assert IntegerCache.high >= 127;
}
private IntegerCache() {}
}
/**
* Returns an {@code Integer} instance representing the specified
* {@code int} value. If a new {@code Integer} instance is not
* required, this method should generally be used in preference to
* the constructor {@link #Integer(int)}, as this method is likely
* to yield significantly better space and time performance by
* caching frequently requested values.
*
* This method will always cache values in the range -128 to 127,
* inclusive, and may cache other values outside of this range.
*
* @param i an {@code int} value.
* @return an {@code Integer} instance representing {@code i}.
* @since 1.5
*/
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
源码分析
- 在valueOf方法中，先判断值是否在IntegerCache中，如果不在，就创建新的Integer(new),否则，就直接从缓存池返回；
- valueOf方法就使用到了享元模式；
- 如果使用valueOf方法得到一个Integer实例范围在-128~127之间，执行速度比 new 快；
所以，以-128~127为界，比较Integer是否是同一个对象时会有不同的表现结果。
结
“享”即共享，“元”即对象，如果系统中有大量对象占用缓存，并且对象状态大都可以外部化时，我们就可以考虑选用享元模式。
但是也要清楚的看到，享元模式在提高了效率的同时也提高了系统复杂度，而且，外部状态具有固化特性不会随着内部状态的改变而改变，这也会在一定程度上增加编码逻辑的理解难度。
关注我，共同进步，每周至少一更。——Wayne