凡隐的博客

引入

之前每次入门Disruptor对此部分总是泛泛看过，主要关注点在如何应用上，急于按照文档完成第一个Demo，怠慢了其实现的核心思想及其要解决的主要问题，导致虽然入门过几次Disruptor，仍对其认识十分浅薄。最近有空再次入门Disruptor时，不出意外的又遇到了难以规避的问题–内存的伪共享。

前车之鉴，后事之师。这次花了一些时间先去了解下久闻其名的伪共享。

引入

之前简单看过Dubbo基于SPI的“微核+插件”形式的架构模式，Dubbo因为这种架构模式使得扩展十分简单，另外Dubbo的框架分层十分清晰，看起源码来相对轻松不少。

在使用Dubbo时突然想到几个问题，Dubbo默认使用tcp长链接，消费者们可能同时发起调用，提供者是怎样处理这些请求的？消费者和生产者之间链接如何复用？消费者和提供者之间几个长链接？要搞清楚这几个问题要从Dubbo的exchange和transport层来找答案。

背景

业务中涉及到一些关于单据的操作，每种单据单据都会有自己的状态，单据的一些行为受限于当前订单的状态，单据的状态直接用常量表示，业务进行前的检查部分通过if判断来检测当前单据是否可以流转到目标状态。

痛点

业务发展的比较快，某些单据状态不停的增加，每一次增加都需要改动业务中使用到状态的相关代码，更糟的的是这些代码可能遍布于多个类的多个方法中（散弹枪一样），不仅增加发布的风险也同时增加了测试的回归任务。

意图

Visitor是行为模式的一种，允许你在不改变要操作对象类的情况下定义一个新操作。

问题

你的团队正在开发一款地理信息结构地图的app。图的节点不仅表示城镇也有其他诸如景点，行业等信息。节点间通过道路关联。在引擎中，每个节点都是一个对象，他们的类型由他们自己的类来表示。

你接到一个任务，要把地图导出为XML。乍看之下很容易实现。你需要为每个类型的节点添加一个导出方法，然后遍历地图并为每个节点执行导出方法。这个方法不仅简单而且优雅，因为你可以使用多态来避免和具体的节点类耦合。

但不幸的是，系统架构师不允许修改已存在的node类。这些代码已经在生产环境，没有人希望冒着风险修改他。

另外，他质疑节点类中的XML导出是否有意义。这些类的主要工作是和地理数据协作。导出行为放在这里看起来很不合适。

还有另一个拒绝的原因。在此之后，市场部门的人可能会要求你导出其他格式或添加其他一些奇怪的功能。这会迫使你再次修改那些珍贵的代码。

意图

Template Method 时行为模式的一种，让你定义一个算法的骨架，允许子类重新定义在不改变结构的情况下重新定义算法的某些步骤。

问题

假设你正在写一个挖掘办公文档数据的应用程序。用户想要输入各种格式的文件（PDF，DOC，CSV），程序输出给他们有用的格式化数据。

第一个版本你仅支持DOC文件。下一个版本支持CSV格式文件。一个月后，你又增加了从PDF中分析数据的功能。

这时候，你注意到这三种转换算法有很多相似之处。他们除了处理不同的文件格式外，对数据的萃取和分析都是一致的。这点对减少重复代码和算法独立很有帮助。

客户端代码使用这些算法还有另一个问题。选择合适的行为的许多条件都需要依赖选择的算法。如果这三个转换类都遵循一个通用接口或者一个基类，这些条件就可以用多态消灭掉。

意图

Strategy是行为模式的一种，让你定义一组算法，各自封装，并且他们可替换。Strategy让这些算法独立与使用他们的客户端。

问题

一天你决定写一个给驴友使用的导航应用。这个应用以漂亮的地图为中心，允许用户在任何城市快速的定位。应用最大的特点是能够自动规划路线，所以你决定特别关注这点。用户可以输入一个期望的目的地，能够快速在屏幕上画出路线。

第一个版本的应用只能规划道路上的路线，适合汽车旅客。但显然不是所有的人都喜欢在休假时开车。所以下一次更新，你添加了规划步行路线的选项。之后，你又增加了一个选项，允许用户规划基于公共交通的路线。

但这仅是一个开始。最近的版本中你计划增加一个可以规划自行车路线的特性。之后，根据沿途景点规划路线成为可选项。

这款应用的业务是成功的，但是技术部分让你头疼不已。

意图

State是行为模式的一种，它允许你在对象内部状态发生变化时改变其行为。这个对象会改变它的类。

问题

状态模式和有限状态机很相似。

它主要的思想是程序是几个状态之一，这些状态相互关联。状态的数量和它们之间的转换是有限的并且是预先定义的。根据当前的状态，程序对相同的事件会有不同的响应。

类似的方法可以应用到对象上。比如，Document（提案）对象可以是以下三种状态之一：Draft（草案），Moderations（待审）和Publish（发布）。对每种状态而言，publish方法会有不同的处理方式：

意图

Observer是行为模式的一种，允许你定义对象间一对多的关系，以便一个对象状态改变后，它的依赖者可以被通知并可以自动更新。

问题

假设你有两个对象，Customer和Store。商店采购了一批新产品，一些客户对这些产品很感兴趣。

客户可能每天都来商店看下是否有感兴趣的产品售卖，但大多情况下的是无意义的，因为产品还在路上。

另一方面，商店可以给所有的客户发送上新的邮件。但是对那些不关心这类产品的用户来说是不必要的。

因此，我们遇到了一个冲突：是客户浪费时间来顶起检查还是商店浪费时间来通知到错误的客户。

意图

Meditor是行为模式的一种，允许你定一个对象来封装一些对象的关联关系，以使这些对象相互独立。

问题

你有一个对话框用来编辑用户的配置。它是由TextEdit、Checkboxes、Button等组成的表单。

表单中元素会相互影响。比如，“我有一条狗”的复选框应当展示隐藏的文本框用来输入狗的名字。另外一个例子是提交按钮在保存数据钱必须娇艳所有字段的数据。

把这些逻辑直接放在表单元素代码中，使得这些类难以被app其他表单复用。比如，你不能使用另一个表单中的复选框，因为它和狗名字的文本框紧密耦合。

意图

Iterator是行为模式的一种，允许在不暴露底层结构的情况下顺序访问聚合对象中的元素。

问题

集合是编程中最常用的数据结构。它把一组对象放到一个单独的容器中。

大多集合看起来都像元素的列表。然而，一些集合以树、图或者其他复杂数据结构组织数据。并且每个集合都必须提供一个方法让用户可以按照顺序处理集合中的元素。

但是，要怎么顺序遍历一个复杂结构呢？必须有几个方法来做到这一点。比如，今天想要深度优先来遍历树。但是，明天又想宽度优先来遍历。下周，又可能需要随机访问集合元素。