享元模式(分离与共享细粒度对象)

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 成数据结构,你会怎么干呢?

权限 用户
听说读写练看 robert
听读练看 staff
听读练看写 jeff
john

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

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、感谢简书作者九彩拼盘的勘误

  • 由享元模式联想到 配合与逻辑的 抽象层次的享元理解。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容