享元模式（分离与共享细粒度对象）

0、提纲

目录： 1、由 HTTP 协议 联想到 对享元模式的思考 2、引入礼盒问题，作为享元模式的逆向思考 3、享元模式的实现 4、享元模式总结 5、感谢帮助勘误的简书作者们

需要查看其它设计模式描述可以查看我的文章《设计模式开篇》。

1、由 HTTP 协议 联想到 对享元模式的思考

了解享元模式有一段时间了，但到目前为止还没有自己应用过，所以也就一直没有提笔写享元模式，怕不能写出享元模式的精髓。

昨天在读《HTTP权威指南》的时候，书中提到了数据聚集的 Nagle 算法。

TCP 有一个数据流接口，应用程序可以通过它将任意尺寸的数据放入 TCP 栈中（即使一次只放一个一个字节也可以）。但是每个 TCP 段中都至少装载了40个字节的标记和首部。这意味着如果发送大量包含少量数据的 TCP 分组，网络性能就会严重下降。

尝试发送大量包含少量数据的 TCP 分组

Nagle 算法试图在发送一个分组之前，将 TCP 数据绑定在一起，以提高网络效率。Nagle 算法鼓励发送全尺寸（LAN 上分组最大约1500字节，WAN 上分组则是几百字节）的段。只有当其他分组都被确认过后，Nagle 算法才允许发送非全尺寸的分组。这意味着当其它分组在传输过程中，就将已接收到的数据缓存起来。只有当挂起的分组被确认，或缓存中积累了足够发送一个全尺寸的数据时，才允许将缓存的数据发送出去。

启用 Nagle 算法

拓展：Nagle 算法在现代的服务器上并不推荐使用，因为它解决了细粒度对象的同时也带入了不少新的问题。最显著的是因为引入延迟确认算法，导致的自身被延迟1-200毫秒的情况。

对比上一张图，差一点：移除了两个 TCP 分组容器（节省约80字节），由三次TCP 段应答降至一次应答。当然这些都是在 TCP 层次上优化，似乎与本期主题（享元模式）扯不上关系，但细细品味实则不然。

Nagle 算法通过缓冲[buffer]（注意不是缓存[cache]）数据应用延迟确认算法，将多个细粒度对象组合成较大的对象放入一个TCP 分段中，以减少创建多余的 TCP 分段。

• 文章用较多的篇幅说明 Nagle 算法，似乎有些本末倒置。我们暂先忽略Nagle 算法利用缓冲区将细粒度数据拼装成粗粒度数据的过程，着重关心其结果 。
• 如上图中的三个包含内容长度为1字节的 TCP 分段，采用 Nagle 算法后将三个 TCP 分段的公共首部提取到一个TCP分段中（其实内部的 TCP 校验码是需要重新计算的），然后将内容归并放入提取出的 TCP 分段中，达到优化性能的效用。

注意： 虽然已经讲了很多，但不得不纠正的一点是 —— Nagle 算法并不是享元模式实现，但它确确实实解决了细粒度对象问题。这对正确理解享元模式，起到了不少启发作用。

2、引入礼盒问题，作为享元模式的逆向思考

漂亮的礼盒

我们换个视角来看待包裹与包裹中的内容，生活中的典型例子是出礼品包装盒与礼物。你可以再没有想好要买什么礼物之前，先买一个漂亮的礼盒（如果我们用心准备礼物的话），用心的你选择了一只钢笔作为礼物。

我们很用心的将礼物放进礼盒中系好丝带 ~~（背景音乐响起） 完整的礼物出现了！

注意：直到目前为止，我们都在拿组合的思想说事。无论是TCP 分段（标记首部&内容），还是礼物（礼盒+钢笔）。因为我们是先有细粒度的对象，再使用细粒度的对象组合成一个粗粒度对象。而享元模式的思想则恰恰相反，它将粗粒度对象划分成细粒度对象。

3、享元模式的实现

享元模式可以优化大量包含重复数据的细粒度对象的场景，典型的场景比如：权限控制。

比如下表，假设每字符代表一种权限，而一长串则表示一串组合权限。现在需要你把下面这张表 mapping 成数据结构，你会怎么干呢？

一般情况下我们会这么干（如果权限只是有限的字符串这样干并没有什么坏处）。

public class User{
    
    public String name;
    public String permissions;

}

（甲方的新需求）：明确告知每个权限串会非常的长，大约几 MB大小（为了切换思考角度容易一些，我不得不这样夸张的说）。

这种时候显然上面的User结构就无法支撑了，因为我们拥有一大串的User列表。把他们都加载到内存中，会造成很大的开销，这个时候我们不得不思考更好的解决方案。

我们观察到权限串有大量的重复单元，如上表中的每个用户都有听这个权限。所以我们不妨将permissions拆分成：听、说、读、写、练、看的单个权限。然后user引用对应权限的对象即可。

public class User{
    
    public String name;
    public Permission[] permissions;

    public User(String name,Permission... permissions){
        this.name = name;
        this.permissions = permission;
    }

}

public class Permission{

    public Permission(String permission){
        this.permission = permission;
    }
    public String permission;
}

public class Main{
    
    public static void main(String[] args){
        
        // 提供权限
        Permission hear = new Permission("听");
        Permission say = new Permission("说");
        Permission read = new Permission("读");
        Permission write = new Permission("写");
        Permission view = new Permission("看");
        Permission work = new Permission("练");

        // 创建用户

        User robert = new User("robert",hear,say,read,write,view,work);
        User staff = new User("staff",hear,read,view,work);
        User jeff = new User("jeff",hear,read,write,view,work);
        User john = new User("john",hear);

    }

}

注意：代码并不是享元模式的实现结构。但我认为已经足够说明问题，相比于第一个方案(String)permissions，下面的方案：权限部分已经做到细粒度的复用，而那些的确无法复用的（如：用户与权限的绑定关系）也的确无法复用了。 当然第二个方案，有太多可优化的地方（比如建个权限工厂）就不再这里体现了。

4、享元模式总结

享元模式实质上将粗粒度的对象拆分成：动 与 静 的部分。 动：意味着 变化、联结、联系，是无法被分割出来的关系。 静：意味着 重复、可模板化的内容。

将那些不会变化的内容提取出来，也即共享模式的本质：共享细粒度对象。

是的，全文没有提到一点如何实现享元模式的结构，如果你有需要不妨Google 之。我相信在领悟了其思想的前提下，看任何一篇享元模式实现的文章都是很容易读懂的。

5、感谢帮助勘误的简书作者们

1、感谢简书作者 远伯 的勘误

• 纠正了 Nagle 算法是基于 buffer 而非 cache 的数据延迟算法。
• 提出 Nagle 的模式与享元模式思想 略有差异的事实。

2、感谢简书作者九彩拼盘的勘误

• 由享元模式联想到 配合与逻辑的 抽象层次的享元理解。