Hadoop中HDFS的存储机制
 
HDFS（Hadoop Distributed File System）是Hadoop分布式计算中的数据存储系统，是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念，然后介绍HDFS中读写操作的过程，最后分析了HDFS的优缺点。
 
1. HDFS中的基础概念
 
Block：HDFS中的存储单元是每个数据块block，HDFS默认的最基本的存储单位是64M的数据块。和普通的文件系统相同的是，HDFS中的文件也是被分成64M一块的数据块存储的。不同的是，在HDFS中，如果一个文件大小小于一个数据块的大小，它是不需要占用整个数据块的存储空间的。
 
NameNode：元数据节点。该节点用来管理文件系统中的命名空间，是master。其将所有的为了见和文件夹的元数据保存在一个文件系统树中，这些信息在硬盘上保存为了：命名空间镜像（namespace image）以及修改日志（edit log），后面还会讲到。此外，NameNode还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而，这些信息不存放在硬盘上，而是在系统启动的时候从数据节点收集而成的。
 
DataNode：数据节点。是HDFS真正存储数据的地方。客户端（client）和元数据节点（NameNode）可以向数据节点请求写入或者读出数据块。此外，DataNode需要周期性的向元数据节点回报其存储的数据块信息。
 
Secondary NameNode:从元数据节点。从元数据节点并不是NameNode出现问题时候的备用节点，它的主要功能是周期性的将NameNode中的namespace image和edit log合并，以防log文件过大。此外，合并过后的namespace image文件也会在Secondary NameNode上保存一份，以防NameNode失败的时候，可以恢复。
 
edit log：修改日志。当文件系统客户端client进行------写------操作的时候，我们就要把这条记录放在修改日志中。在记录了修改日志后，NameNode则修改内存中的数据结构。每次写操作成功之前，edit log都会同步到文件系统中。
 
fsimage：命名空间镜像。它是内存中的元数据在硬盘上的checkpoint。当NameNode失败的时候，最新的checkpoint的元数据信息就会从fsimage加载到内存中，然后注意重新执行修改日志中的操作。而Secondary NameNode就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的。
 
2. HDFS中文件读写操作流程
 
在HDFS中，文件的读写过程就是client和NameNode以及DataNode一起交互的过程。我们已经知道NameNode管理着文件系统的元数据，DataNode存储的是实际的数据，那么client就会联系NameNode以获取文件的元数据，而真正的文件读取操作是直接和DataNode进行交互的。
 
写文件的过程：
 
客户端调用create()来创建文件DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件。元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。DistributedFileSystem返回DFSOutputStream，客户端用于写数据。客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。如果数据节点在写入的过程中失败：
 
关闭pipeline，将ack queue中的数据块放入data queue的开始。
 当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。
 失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。
 元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
 当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。
 
读取文件的过程：
 
客户端(client)用FileSystem的open()函数打开文件DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息。对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。客户端调用stream的read()函数开始读取数据。DFSInputStream连接保存此文件第一个数据块的最近的数据节点。Data从数据节点读到客户端(client)当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。 在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录，以后不再连接。
 
3. HDFS的优缺点分析
 
优点：
 
1）能够处理超大的文件；
 
2）流式访问数据。HDFS能够很好的处理“一次写入，多次读写”的任务。也就是说，一个数据集一旦生成了，就会被复制到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及到数据集中的大部分数据。所以，HDFS请求读取整个数据集要比读取一条记录更加高效。
 
3）可以运行在比较廉价的商用机器集群上。
 
缺点和改进策略：
 
1）不适合低延迟数据访问：HDFS是为了处理大型数据集分析任务的，主要是为达到大数据分析，所以延迟时间可能会较高。改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了。
 
2）无法高效存储大量小文件：因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。改进策略：要想让HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
 附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。
 
3）不支持多用户写入以及任意修改文件：在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

1）、内嵌模式：将元数据保存在本地内嵌的derby数据库中，内嵌的derby数据库每次只能访问一个数据文件，也就意味着它不支持多会话连接。
 
 
 
2）. 本地模式：将元数据保存在本地独立的数据库中（一般是mysql），这可以支持多会话连接。
 
 
 
3）. 远程模式：把元数据保存在远程独立的mysql数据库中，避免每个客户端都去安装mysql数据库。
 
 
 
Hive Metastore有三种配置方式，分别是：
 
Embedded Metastore Database (Derby) 内嵌模式
Local Metastore Server 本地元存储
Remote Metastore Server 远程元存储
Metadata、Metastore作用
 
metadata即元数据。元数据包含用Hive创建的database、tabel等的元信息。
 元数据存储在关系型数据库中。如Derby、MySQL等。
Metastore的作用是：客户端连接metastore服务，metastore再去连接MySQL数据库来存取元数据。有了metastore服务，就可以有多个客户端同时连接，而且这些客户端不需要知道MySQL数据库的用户名和密码，只需要连接metastore 服务即可。
三种配置方式区别
 
内嵌模式使用的是内嵌的Derby数据库来存储元数据，也不需要额外起Metastore服务。这个是默认的，配置简单，但是一次只能一个客户端连接，适用于用来实验，不适用于生产环境。
本地元存储和远程元存储都采用外部数据库来存储元数据，目前支持的数据库有：MySQL、Postgres、Oracle、MS SQL Server.在这里我们使用MySQL。
本地元存储和远程元存储的区别是：本地元存储不需要单独起metastore服务，用的是跟hive在同一个进程里的metastore服务。远程元存储需要单独起metastore服务，然后每个客户端都在配置文件里配置连接到该metastore服务。远程元存储的metastore服务和hive运行在不同的进程
 
 
 
 
hive有哪些保存元数据的方式，各有什么特点。
 
1.内存数据库derby，安装小，但是数据存在内存，不稳定
 
2.mysql数据库，数据存储模式可以自己设置，持久化好，查看方便。

所谓的大端模式，是指数据的低位（就是权值较小的后面那几位）保存在内存的高地址中，而数据的高位，保存在内存的低地址中，这样的存储模式有点儿类似于把数据当作字符串顺序处理：地址由小向大增加，而数据从高位往低位放；
 
 所谓的小端模式，是指数据的低位保存在内存的低地址中，而数 据的高位保存在内存的高地址中，这种存储模式将地址的高低和数据位权有效地结合起来，高地址部分权值高，低地址部分权值低，和我们的逻辑方法一致。 
 
为什么会有大小端模式之分呢？这是因为在计算机系统中，我们是以字节为单位的，每个地址单元都对应着一个字节，一个字节为 8bit。但是在C语言中除了8bit的char之外，还有16bit的short型，32bit的long型（要看具体的编译器），另外，对于位数大于 8位的处理器，例如16位或者32位的处理器，由于寄存器宽度大于一个字节，那么必然存在着一个如果将多个字节安排的问题。因此就导致了大端存储模式和小 端存储模式。例如一个16bit的short型x，在内存中的地址为0x0010，x的值为0x1122，那么0x11为高字节，0x22为低字节。对于 大端模式，就将0x11放在低地址中，即0x0010中，0x22放在高地址中，即0x0011中。小端模式，刚好相反。我们常用的X86结构是小端模 式，而KEIL C51则为大端模式。很多的ARM，DSP都为小端模式。有些ARM处理器还可以由硬件来选择是大端模式还是小端模式。 下面这段代码可以用来测试一下你的编译器是大端模式还是小端模式： short int x; char x0,x1; x=0x1122; x0=((char*)&x)[0]; //低地址单元 x1=((char*)&x)[1]; //高地址单元 若x0=0x11,则是大端; 若x0=0x22,则是小端...... 上面的程序还可以看出，数据寻址时，用的是低位字节的地址。

 一、设计模式总述：
 
1、什么是设计模式：
 
        设计模式是一套经过反复使用的代码设计经验，目的是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式于己于人于系统都是多赢的，它使得代码编写真正工程化，它是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。总体来说，设计模式分为三大类：
 
 
 
创建型模式：共5种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
结构型模式：共7种：适配器模式、装饰器模式、代理模式、桥接模式、外观模式、组合模式、享元模式
行为型模式：共11种：策略模式、模板方法模式、观察者模式、责任链模式、访问者模式、中介者模式、迭代器模式、命令模式、状态模式、备忘录模式、解释器模式
 
其实还有两类：并发型模式和线程池模式，用一个图片来整体描述一下：
 
 
 
2、设计模式的六大原则：
 
（1）开闭原则 (Open Close Principle) ：
 
        开闭原则指的是对扩展开放，对修改关闭。在对程序进行扩展的时候，不能去修改原有的代码，想要达到这样的效果，我们就需要使用接口或者抽象类
 
（2）依赖倒转原则 (Dependence Inversion Principle)：
 
        依赖倒置原则是开闭原则的基础，指的是针对接口编程，依赖于抽象而不依赖于具体
 
（3）里氏替换原则 (Liskov Substitution Principle) ：
 
        里氏替换原则是继承与复用的基石，只有当子类可以替换掉基类，且系统的功能不受影响时，基类才能被复用，而子类也能够在基础类上增加新的行为。所以里氏替换原则指的是任何基类可以出现的地方，子类一定可以出现。
 
        里氏替换原则是对 “开闭原则” 的补充，实现 “开闭原则” 的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。
 
（4）接口隔离原则 (Interface Segregation Principle)：
 
        使用多个隔离的接口，比使用单个接口要好，降低接口之间的耦合度与依赖，方便升级和维护方便
 
（5）迪米特原则 (Demeter Principle)：
 
        迪米特原则，也叫最少知道原则，指的是一个类应当尽量减少与其他实体进行相互作用，使得系统功能模块相对独立，降低耦合关系。该原则的初衷是降低类的耦合，虽然可以避免与非直接的类通信，但是要通信，就必然会通过一个“中介”来发生关系，过分的使用迪米特原则，会产生大量的中介和传递类，导致系统复杂度变大，所以采用迪米特法则时要反复权衡，既要做到结构清晰，又要高内聚低耦合。
 
（6）合成复用原则 (Composite Reuse Principle)：
 
        尽量使用组合/聚合的方式，而不是使用继承。
 
 
 
二、Java的23种设计模式：
 
        接下来我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析
 
1、创建型-工厂方法模式：
 
工厂方法模式分为三种：
 
（1）简单工厂模式：
 
建立一个工厂类，并定义一个接口对实现了同一接口的产品类进行创建。首先看下关系图：
 
 
（2）工厂方法模式：
 
工厂方法模式是对简单工厂模式的改进，简单工厂的缺陷在于不符合“开闭原则”，每次添加新产品类就需要修改工厂类，不利于系统的扩展维护。而工厂方法将工厂抽象化，并定义一个创建对象的接口。每增加新产品，只需增加该产品以及对应的具体实现工厂类，由具体工厂类决定要实例化的产品是哪个，将对象的创建与实例化延迟到子类，这样工厂的设计就符合“开闭原则”了，扩展时不必去修改原来的代码。UML关系图如下：
 
 
 （3）静态工厂方法模式：
 
静态工厂模式是将工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。
 
 
 
工厂方法模式详情文章：Java设计模式之创建型：工厂模式详解（简单工厂+工厂方法+抽象工厂）
 
 
 
2、创建型-抽象工厂模式：
 
        抽象工厂模式主要用于创建相关对象的家族。当一个产品族中需要被设计在一起工作时，通过抽象工厂模式，能够保证客户端始终只使用同一个产品族中的对象；并且通过隔离具体类的生成，使得客户端不需要明确指定具体生成类；所有的具体工厂都实现了抽象工厂中定义的公共接口，因此只需要改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
 
        但该模式的缺点在于添加新的行为时比较麻烦，如果需要添加一个新产品族对象时，需要更改接口及其下所有子类，这必然会带来很大的麻烦。
 
        UML结构图如下：
 
 
 
 
抽象工厂模式详情：Java设计模式之创建型：工厂模式详解（简单工厂+工厂方法+抽象工厂）
 
 
 
3、创建型-建造者模式：
 
         建造者模式将复杂产品的创建步骤分解在在不同的方法中，使得创建过程更加清晰，从而更精确控制复杂对象的产生过程；通过隔离复杂对象的构建与使用，也就是将产品的创建与产品本身分离开来，使得同样的构建过程可以创建不同的对象；并且每个具体建造者都相互独立，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。UML结构图如下：
 
 
 
 
 建造者模式详情：Java设计模式之创建型：建造者模式
 
 
 
4、创建型-单例模式：
 
        单例模式可以确保系统中某个类只有一个实例，该类自行实例化并向整个系统提供这个实例的公共访问点，除了该公共访问点，不能通过其他途径访问该实例。单例模式的优点在于：
 
系统中只存在一个共用的实例对象，无需频繁创建和销毁对象，节约了系统资源，提高系统的性能
可以严格控制客户怎么样以及何时访问单例对象。
单例模式的写法有好几种，主要有三种：懒汉式单例、饿汉式单例、登记式单例。
 
 
 
单例模式详情：Java设计模式之创建型：单例模式
 
 
 
5、创建型-原型模式：
 
        原型模式也是用于对象的创建，通过将一个对象作为原型，对其进行复制克隆，产生一个与源对象类似的新对象。UML类图如下：
 
 
 在 Java 中，原型模式的核心是就是原型类 Prototype，Prototype 类需要具备以下两个条件：
 
实现 Cloneable 接口：
重写 Object 类中的 clone() 方法，用于返回对象的拷贝；
Object 类中的 clone() 方法默认是浅拷贝，如果想要深拷贝对象，则需要在 clone() 方法中自定义自己的复制逻辑。
 
浅复制：将一个对象复制后，基本数据类型的变量会重新创建，而引用类型指向的还是原对象所指向的内存地址。
深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。
        使用原型模式进行创建对象不仅简化对象的创建步骤，还比 new 方式创建对象的性能要好的多，因为 Object 类的 clone() 方法是一个本地方法，直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显；
 
 
 
原型模式详情：Java设计模式之创建型：原型模式
 
 
        
 
        上面我们介绍了5种创建型模式，下面我们就开始介绍下7种结构型模式：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。其中对象的适配器模式是各种模式的起源，如下图：
 
 
 
6、结构型-适配器模式：
 
        适配器模式主要用于将一个类或者接口转化成客户端希望的格式，使得原本不兼容的类可以在一起工作，将目标类和适配者类解耦；同时也符合“开闭原则”，可以在不修改原代码的基础上增加新的适配器类；将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性，但是缺点在于更换适配器的实现过程比较复杂。
 
        所以，适配器模式比较适合以下场景：
 
（1）系统需要使用现有的类，而这些类的接口不符合系统的接口。
（2）使用第三方组件，组件接口定义和自己定义的不同，不希望修改自己的接口，但是要使用第三方组件接口的功能。
下面有个非常形象的例子很好地说明了什么是适配器模式：
 
 
适配器模式的主要实现有三种：类的适配器模式、对象的适配器模式、接口的适配器模式。三者的使用场景如下：
 
类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。
对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。
接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。
 
 
适配器模式详情：Java设计模式之结构型：适配器模式
 
 
 
7、结构型-装饰器模式：
 
        装饰器模式可以动态给对象添加一些额外的职责从而实现功能的拓展，在运行时选择不同的装饰器，从而实现不同的行为；比使用继承更加灵活，通过对不同的装饰类进行排列组合，创造出很多不同行为，得到功能更为强大的对象；符合“开闭原则”，被装饰类与装饰类独立变化，用户可以根据需要增加新的装饰类和被装饰类，在使用时再对其进行组合，原有代码无须改变。装饰器模式的UML结构图如下：
 
 
        但是装饰器模式也存在缺点，首先会产生很多的小对象，增加了系统的复杂性，第二是排错比较困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐。
 
 
 
装饰器模式详情：Java设计模式之结构型：装饰器模式
 
 
 
8、结构型-代理模式：
 
        代理模式的设计动机是通过代理对象来访问真实对象，通过建立一个对象代理类，由代理对象控制原对象的引用，从而实现对真实对象的操作。在代理模式中，代理对象主要起到一个中介的作用，用于协调与连接调用者(即客户端)和被调用者(即目标对象)，在一定程度上降低了系统的耦合度，同时也保护了目标对象。但缺点是在调用者与被调用者之间增加了代理对象，可能会造成请求的处理速度变慢。UML结构图如下：
 
 
 
 
代理模式详情：Java设计模式之结构型：代理模式
 
 
 
9、结构型-桥接模式：
 
        桥接模式将系统的抽象部分与实现部分分离解耦，使他们可以独立的变化。为了达到让抽象部分和实现部分独立变化的目的，桥接模式使用组合关系来代替继承关系，抽象部分拥有实现部分的接口对象，从而能够通过这个接口对象来调用具体实现部分的功能。也就是说，桥接模式中的桥接是一个单方向的关系，只能够抽象部分去使用实现部分的对象，而不能反过来。 
 
        桥接模式符合“开闭原则”，提高了系统的可拓展性，在两个变化维度中任意扩展一个维度，都不需要修改原来的系统；并且实现细节对客户不透明，可以隐藏实现细节。但是由于聚合关系建立在抽象层，要求开发者针对抽象进行编程，这增加系统的理解和设计难度。桥接模式的UML结构图如下：
 
 
        就像在Java中我们使用 JDBC 连接数据库时，在各个数据库之间进行切换，基本不需要动太多的代码，原因就是使用了桥接模式，JDBC 提供统一接口，每个数据库提供各自的实现，然后由桥接类创建一个连接数据库的驱动，使用某一个数据库的时候只需要切换一下就行。JDBC 的结构图如下：
 
 
         在 JDBC 中，桥接模式的实现化角色 (Implementor) 为的 Driver 接口，具体实现化 (Concrete Implementor) 角色对应 MysqlDriver、OracleDriver 和 MariadbDriver，扩展抽象化 (Refined Abstraction) 角色对应 DriverManager，不具有抽象化 (Abstraction) 角色作为扩展抽象化角色的父类。
 
 
 
桥接模式详情：Java设计模式之结构型：桥接模式
 
 
 
10、结构型-外观模式：
 
        外观模式通过对客户端提供一个统一的接口，用于访问子系统中的一群接口。使用外观模式有以下几点好处：
 
（1）更加易用：使得子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟外观类交互就可以了；
 
（2）松散耦合：将客户端与子系统解耦，让子系统内部的模块能更容易扩展和维护。
 
（3）更好的划分访问层次：通过合理使用 Facade，可以更好地划分访问的层次，有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。
 
        但是如果外观模式对子系统类做太多的限制则减少了可变性和灵活性，所以外观模式适用于为复杂子系统提供一个简单接口，提高系统的易用性场景 以及 引入外观模式将子系统与客户端进行解耦，提高子系统的独立性和可移植性。
 
        外观模式的UML结构图如下：
 
 
 
 
外观模式详情： Java设计模式之结构型：外观模式
 
 
 
11、结构型-组合模式：
 
        组合模式将叶子对象和容器对象进行递归组合，形成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性，能够像处理叶子对象一样来处理组合对象，无需进行区分，从而使用户程序能够与复杂元素的内部结构进行解耦。
 
        组合模式最关键的地方是叶子对象和组合对象实现了相同的抽象构建类，它既可表示叶子对象，也可表示容器对象，客户仅仅需要针对这个抽象构建类进行编程，这就是组合模式能够将叶子节点和对象节点进行一致处理的原因。组合模式的UML结构图如下：
 
 
 
 
组合模式详情： Java设计模式之结构型：组合模式
 
 
 
12、结构型-享元模式：
 
        享元模式通过共享技术有效地支持细粒度、状态变化小的对象复用，当系统中存在有多个相同的对象，那么只共享一份，不必每个都去实例化一个对象，极大地减少系统中对象的数量，从而节省资源。
 
        享元模式的核心是享元工厂类，享元工厂类维护了一个对象存储池，当客户端需要对象时，首先从享元池中获取，如果享元池中存在对象实例则直接返回，如果享元池中不存在，则创建一个新的享元对象实例返回给用户，并在享元池中保存该新增对象，这点有些单例的意思。
 
        工厂类通常会使用集合类型来保存对象，如 HashMap、Hashtable、Vector 等等，在 Java 中，数据库连接池、线程池等都是用享元模式的应用。
 
        享元模式的UML结构图如下：
 
 
         Java 中，String 类型就是使用享元模式，String 对象是 final 类型，对象一旦创建就不可改变。而 Java 的字符串常量都是存在字符串常量池中的，JVM 会确保一个字符串常量在常量池中只有一个拷贝。
 
        而且提到共享池，我们也很容易联想到 Java 里面的JDBC连接池，通过连接池的管理，实现了数据库连接的共享，不需要每一次都重新创建连接，节省了数据库重新创建的开销，提升了系统的性能！
 
 
 
享元模式详情：Java设计模式之结构型：享元模式
 
 
 
        前面我们介绍了7种结构型设计模式，接下来我们介绍一下11种行为型设计模式：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。先来张图，看看这11中模式的关系：
 
 
 13、行为型-策略模式：
 
        将类中经常改变或者可能改变的部分提取为作为一个抽象策略接口类，然后在类中包含这个对象的实例，这样类实例在运行时就可以随意调用实现了这个接口的类的行为。
 
        比如定义一系列的算法，把每一个算法封装起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化，这就是策略模式。UML结构图如下：
 
 
        策略模式的优点在于可以动态改变对象的行为；但缺点是会产生很多策略类，并且策略模式的决定权在用户，系统只是提供不同算法的实现，所以客户端必须知道所有的策略类，并自行决定使用哪一个策略类； 
 
        策略模式适用用于以下几种场景：
 
（1）应用程序需要实现特定的功能服务，而该程序有多种实现方式使用，所以需要动态地在几种算法中选择一种
（2）一个类定义了多种行为算法，并且这些行为在类的操作中以多个条件语句的形式出现，就可以将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
 
 
策略模式详情：Java设计模式之行为型：策略模式
 
 
 
14、行为型-模板方法：
 
        模板方法是基于继承实现的，在抽象父类中声明一个模板方法，并在模板方法中定义算法的执行步骤（即算法骨架）。在模板方法模式中，可以将子类共性的部分放在父类中实现，而特性的部分延迟到子类中实现，只需将特性部分在父类中声明成抽象方法即可，使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤，不同的子类可以以不同的方式来实现这些逻辑。
 
        模板方法模式的优点在于符合“开闭原则”，也能够实现代码复用，将不变的行为转移到父类，去除子类中的重复代码。但是缺点是不同的实现都需要定义一个子类，导致类的个数的增加使得系统更加庞大，设计更加抽象。模板方法模式的UML图如下：
 
 
 
 
模板方法详情：Java设计模式之行为型：模板方法模式
 
 
 
15、行为型-责任链模式：
 
        职责链可以将请求的处理者组织成一条链，并将请求沿着链传递，如果某个处理者能够处理请求则处理，否则将该请求交由上级处理。客户端只需将请求发送到职责链上，无须关注请求的处理细节，通过职责链将请求的发送者和处理者解耦了，这也是职责链的设计动机。        
 
       职责链模式可以简化对象间的相互连接，因为客户端和处理者都没有对方明确的信息，同时处理者也不知道职责链中的结构，处理者只需保存一个指向后续者的引用，而不需要保存所有候选者的引用。
 
        另外职责链模式增加了系统的灵活性，我们可以任意增加或更改处理者，甚至更改处理者的顺序，不过有可能会导致一个请求无论如何也得不到处理，因为它可能被放置在链末端。
 
 
 
所以责任链模式有以下几个优点：
 
 
（1）降低耦合度，将请求的发送者和接收者解耦。反映在代码上就是不需要在类中写很多丑陋的 if….else 语句，如果用了职责链，相当于我们面对一个黑箱，只需将请求递交给其中一个处理者，然后让黑箱内部去负责传递就可以了。
（2）简化了对象，使得对象不需要链的结构。
（3）增加系统的灵活性，通过改变链内的成员或者调动他们的次序，允许动态地新增或者删除处理者
（4）增加新的请求处理类很方便。
 
但是责任链模式也存在一些缺点：
 
 
（1）不能保证请求一定被成功处理
（2）系统性能将受到一定影响，并且可能会造成循环调用。
（3）可能不容易观察运行时的特征，而且在进行代码调试时不太方便，有碍于除错。
 
        责任链模式的UML结构图如下：
 
 
 
 
责任链模式详情：Java设计模式之行为型：责任链模式
 
 
 
16、行为型-观察者模式：
 
        观察者模式又称为 发布-订阅模式，定义了对象之间一对多依赖关系，当目标对象(被观察者)的状态发生改变时，它的所有依赖者(观察者)都会收到通知。一个观察目标可以对应多个观察者，而这些观察者之间没有相互联系，所以能够根据需要增加和删除观察者，使得系统更易于扩展，符合开闭原则；并且观察者模式让目标对象和观察者松耦合，虽然彼此不清楚对方的细节，但依然可以交互，目标对象只知道一个具体的观察者列表，但并不认识任何一个具体的观察者，它只知道他们都有一个共同的接口。
 
        但观察者模式的缺点在于如果存在很多个被观察者的话，那么将需要花费一定时间通知所有的观察者，如果观察者与被观察者之间存在循环依赖的话，那么可能导致系统崩溃，并且观察者模式没有相应的机制让观察者知道被观察对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。观察者模式的UML结构图如下：
 
 
 
 
 观察者模式详情：Java设计模式之行为型：观察者模式
 
 
 
17、行为型-访问者模式：
 
        访问者模式就是一种分离对象数据结构与行为 (基于数据结构的操作) 的方法，通过这种分离，达到为一个被访问者动态添加新的操作而无需做其它修改的效果，使得添加作用于这些数据结构的新操作变得简单，并且不需要改变各数据结构，为不同类型的数据结构提供多种访问操作方式，这样是访问者模式的设计动机。
 
        除了使新增访问操作变得更加简单，也能够在不修改现有类的层次结构下，定义该类层次结构的操作，并将有关元素对象的访问行为集中到一个访问者对象中，而不是分散搞一个个的元素类中。
 
       但访问者模式的缺点在于让增加新的元素类变得困难，每增加一个新的元素类都意味着要在抽象访问者角色中增加一个新的抽象操作，并在每一个具体访问者类中增加相应的具体操作，违背了“开闭原则”的要求；
 
        所以访问者模式适用于对象结构中很少改变，但经常需要在此对象结构上定义新的操作的系统，使得算法操作的增加变得简单；或者需要对一个对象结构中进行很多不同并且不相关的操作，并且需要避免让这些操作污染这些对象，也不希望在增加新操作时修改这些类的场景。
 
        访问者模式的UML结构图如下：
 
 
        从上面的 UML 结构图中我们可以看出，访问者模式主要分为两个层次结构，一个是访问者层次结构，提供了抽象访问者和具体访问者，主要用于声明一些操作；一个是元素层次结构，提供了抽象元素和具体元素，主要用于声明 accept 操作；而对象结构 ObjectStructure 作为两者的桥梁，存储了不同类型的对象，以便不同的访问者来访问，相同访问者可以以不同的方式访问不同的元素，所以在访问者模式中增加新的访问者无需修改现有代码，可扩展行强。
 
        在访问者模式使用了双分派技术，所谓双分派技术就是在选择方法的时候，不仅仅要根据消息接收者的运行时区别，还要根据参数的运行时区别。在访问者模式中，客户端将具体状态当做参数传递给具体访问者，这里完成第一次分派，然后具体访问者作为参数的“具体状态”中的方法，同时也将自己this作为参数传递进去，这里就完成了第二次分派。双分派意味着得到的执行操作决定于请求的种类和接受者的类型。
 
 
 
 访问者模式详情：Java设计模式之行为型：访问者模式
 
 
 
18、行为型-中介者模式：
 
         中介者模式通过中介者对象来封装一系列的对象交互，将对象间复杂的关系网状结构变成结构简单的以中介者为核心的星形结构，对象间一对多的关联转变为一对一的关联，简化对象间的关系，便于理解；各个对象之间的关系被解耦，每个对象不再和它关联的对象直接发生相互作用，而是通过中介者对象来与关联的对象进行通讯，使得对象可以相对独立地使用，提高了对象的可复用和系统的可扩展性。
 
        在中介者模式中，中介者类处于核心地位，它封装了系统中所有对象类之间的关系，除了简化对象间的关系，还可以对对象间的交互进行进一步的控制。中介者模式的UML结构图如下：
 
 
        但是，中介者对象封装了对象之间的关联关系，导致中介者对象变得比较庞大复杂，所承担的责任也比较多，维护起来也比较困难，它需要知道每个对象和他们之间的交互细节，如果它出问题，将会导致整个系统都会出问题。
 
 
 
中介者模式详情：Java设计模式之行为型：中介者模式
 
 
 
19、行为型-命令模式：
 
        命令模式的本质是将请求封装成对象，将发出命令与执行命令的责任分开，命令的发送者和接收者完全解耦，发送者只需知道如何发送命令，不需要关心命令是如何实现的，甚至是否执行成功都不需要理会。命令模式的关键在于引入了抽象命令接口，发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
 
        使用命令模式的优势在于降低了系统的耦合度，而且新命令可以很方便添加到系统中，也容易设计一个组合命令。但缺点在于会导致某些系统有过多的具体命令类，因为针对每一个命令都需要设计一个具体命令类。
 
        命令模式的UML结构图如下：
 
 
 
 
命令模式详情： Java设计模式之行为型：命令模式
 
 
 
20、行为型-状态模式：
 
        状态模式，就是允许对象在内部状态发生改变时改变它的行为，对象看起来就好像修改了它的类，也就是说以状态为原子来改变它的行为，而不是通过行为来改变状态。
 
        当对象的行为取决于它的属性时，我们称这些属性为状态，那该对象就称为状态对象。对于状态对象而言，它的行为依赖于它的状态，比如要预订房间，只有当该房间空闲时才能预订，想入住该房间也只有当你预订了该房间或者该房间为空闲时。对于这样的一个对象，当它的外部事件产生互动的时候，其内部状态就会发生变化，从而使得他的行为也随之发生变化。
 
        状态模式的UML结构图如下：
 
 
 从上面的UML结构图我们可以看出状态模式的优点在于：
 
（1）封装了转换规则，允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块
 
（2）将所有与状态有关的行为放到一个类中，可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 
 
但是状态模式的缺点在于：
 
（1）需要在枚举状态之前需要确定状态种类
 
（2）会导致增加系统类和对象的个数。
 
（3）对 “开闭原则” 的支持并不友好，新增状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。
 
所以状态模式适用于：代码中包含大量与对象状态有关的条件语句，以及对象的行为依赖于它的状态，并且可以根据它的状态改变而改变它的相关行为。
 
 
 
状态模式详情：Java设计模式之行为型：状态模式
 
 
 
21、行为型-备忘录模式：
 
        备忘录模式提供了一种恢复状态的机制，在不破坏封装的前提下，捕获对象的某个时刻内部状态，并保存在该对象之外，保证该对象能够恢复到某个历史状态；备忘录模式将保存的细节封装在备忘录中，除了创建它的创建者之外其他对象都不能访问它，并且实现了即使要改变保存的细节也不影响客户端。但是备忘录模式都是多状态和多备份的，会早用较多的内存，消耗资源。备忘录模式的额UML结构图如下：
 
 
         备忘录模式的核心就是备忘录 Memento，在备忘录中存储的就是原发器 Originator 的部分或者所有的状态信息，而这些状态信息是不能够被其他对象所访问的，也就是说我们是不能使用备忘录之外的对象来存储这些状态信息，如果暴漏了内部状态信息就违反了封装的原则，故备忘录除了原发器外其他对象都不可以访问。所以为了实现备忘录模式的封装，我们需要对备忘录的访问做些控制：
 
（1）对原发器：可以访问备忘录里的所有信息。
 
（2）对负责人 caretaker：不可以访问备忘录里面的数据，但是他可以保存备忘录并且可以将备忘录传递给其他对象。
 
（3）其他对象：不可访问也不可以保存，它只负责接收从负责人那里传递过来的备忘录同时恢复原发器的状态。
 
 
 
备忘录模式详情：Java设计模式之行为型：备忘录模式
 
 
 
22、行为型-迭代器模式：
 
        迭代器模式提供一种访问集合中的各个元素，而不暴露其内部表示的方法。将在元素之间游走的职责交给迭代器，而不是集合对象，从而简化集合容器的实现，让集合容器专注于在它所应该专注的事情上，更加符合单一职责原则，避免在集合容器的抽象接口层中充斥着各种不同的遍历操作。迭代器模式的UML结构图如下：
 
 
 
 
迭代器模式详情：Java设计模式之行为型：迭代器模式
 
 
 
23、行为型-解释器模式：
 
        解释器模式，就是定义语言的文法，并建立一个解释器来解释该语言中的句子，通过构建解释器，解决某一频繁发生的特定类型问题实例。
 
        解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言开发的编译器中，它描述了如何为简单的语言定义一个文法，如何在该语言中表示一个句子，以及如何解释这些句子。    
 
        解释器模式中除了能够使用文法规则来定义一个语言，还能通过使用抽象语法树来更加直观表示、更好地地表示一个语言的构成，每一颗抽象语法树对应一个语言实例。抽象语法树描述了如何构成一个复杂的句子，通过对抽象语法树的分析，可以识别出语言中的终结符和非终结符类。 在解释器模式中由于每一种终结符表达式、非终结符表达式都会有一个具体的实例与之相对应，所以系统的扩展性比较好。
 
        解释器模式的UML如下：
 
 
 
 
 解释器模式详情：Java设计模式之行为型：解释器模式
 
 
 
 

 
 
相关推荐阅读：
 
 
Spring常见面试题总结
 
 
SpringMVC常见面试题总结
 
 
Mybatis常见面试题总结
 
 
MySQL常见面试题总结
 
 
Redis常见面试题总结
 
 
RabbitMQ消息队列常见面试题总结
 
 
ElasticSearch搜索引擎常见面试题总结
 
 
计算机网络常见面试题总结
 
 
操作系统常见面试题总结
 
 
Java基础、集合、多线程常见面试题总结
 
 
Java虚拟机常见面试题总结
 
 
Java常见设计模式总结
 
 
海量数据处理的方法总结
 
 

参考文章：
 
Java之美[从菜鸟到高手演变]之设计模式
 
Java之美[从菜鸟到高手演变]之设计模式二
 
Java之美[从菜鸟到高手演变]之设计模式三
 
Java之美[从菜鸟到高手演变]之设计模式四