本篇是讲述之前学习设计模式的一个总结篇，其目的是为了对这些设计模式的进行一个提炼总结，能够通过查看看此篇就可以理解一些设计模式的核心思想。
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。
使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式有23种类型。按照主要分类可以分为三大类:
一、创建型模式
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
二、结构型模式
这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
三、行为型模式
这些设计模式特别关注对象之间的通信。
设计模式的六大原则
设计模式之间的关系图:
设计模式总概况:
设计模式相关文章:
核心就是保证一个系统中的某个类只有一个实例而且该实例易于外界访问。
在程序中比较常用的是数据库连接池、线程池、日志对象等等。
单例模式的写法主要有5种，分别是：
工厂模式主要有三种，简单工厂模式、工厂方法模式和抽象工厂模式。但是一般的情况下我们主要用到的是工厂方法模式和抽象工厂模式。
其核心是定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
比如生活中的汽车制造，大名鼎鼎的hibernate框架在选择数据库方言这块。
主要核心是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
比如生活中的服装制造厂，可以单独制造衣服、裤子、袜子等等，也可以生产一套服装。
使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
简单的来说就是将一个复杂的东西抽离出来，对外提供一个简单的调用，可以在同样的构建过程创建不同的表示。和工厂模式很相似，不过相比而言更加注重组件的装配。
适用一些基本组件不便，但是组合经常变化的时候。比如超市促销的大礼包。
Builder：指定一个抽象的接口，规定该产品所需实现部件的创建，并不涉及具体的对象部件的创建。
ConcreteBuilder：需实现Builder接口，并且针对不同的逻辑，进行不同方法的创建，最终提供该产品的实例。
Director：用来创建复杂对象的部分，对该部分进行完整的创建或者按照一定的规则进行创建。
Product：示被构造的复杂对象。
优点:
缺点
用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。核心是克隆。
优点:
1.可以提升性能；
缺点:
1.因为必须实现Cloneable 接口，所以用起来可能不太方便。
适配器模式是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。简单的来说就是通过某个接口将不兼容的两个类进行兼容，俗称转换器。
适配器模式主要有两种类型，一种是类适配器模式，主要通过继承来实现适配器功能；一种是对象适配器模式，通过组合来实现适配器功能。
电器的电压，经典的jdbc使用。
优点:
提升了类的复用和灵活度。
缺点:
使用过多，系统会比较杂乱，难以把握。
桥接是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。通过一个中间的桥梁对两边的东西进行关联起来，但是关联的两者之间又不相互影响。
一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。
优点:
1、抽象和实现的分离，实现了解耦；
2、提升的扩展能力。
缺点:
会使系统看起复杂，对新手不友好，没有一定的抽象进行设计能力难以理解。
外观模式隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。它向现有的系统添加一个接口，来隐藏系统的复杂性。对外提供一个简单接口，隐藏实现的逻辑。
系统中有多个复杂的模块或者子系统的时候。
优点:
降低了耦合，从某种方面来说也提升了安全性。
缺点:
不符合开闭原则，不易更改。
装饰器模式允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
把某个东西进行装饰起来，让它可以提供一些额外的功能。
原型不变，动态增加一些功能的时候。
优点:
装饰类和被装饰类可以独立发展，耦合度低，易于扩展，灵活方便。
缺点:
过多的对某个类进行装饰，会增加复杂度。
组合模式是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。
可以表示为 ‘部分-整体’的层级结构。
优点:
高层模块调用较为简单，增加某个节点方便。
缺点:
因为其子节点的声明都是实现类，而不是接口，违反了依赖倒置原则。
过滤器模式允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式，它结合多个标准来获得单一标准。
需要进行筛选的时候。
优点：
简单，解耦，使用方便。
缺点：
过多使用需要注意性能。
在jdk1.8以后可以使用steam的方法进行过滤分组，可以根据指定的条件进行过滤分组筛选。
享元模式主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。
享元模式的角色主要分为三大类，抽象享元类、具体享元类以及享元工厂类。
系统有大量相似对象。
优点：
极大的减少对象的创建，从而降低了系统的内存，提升了效率。
缺点：
提高了系统的复杂度，因为需要将状态进行分离成内部和外部，并且也使外部状态固有化，使得随着内部状态的变化而变化，会造成系统的混乱。
需要注意划分外部状态和内部状态，否则可能会引起线程安全问题。 这些类必须有一个工厂对象加以控制。
虽然它们在某些方面很像，但是实际上却是不同的东西，单例模式的目的是限制创建多个对象，避免冲突，比如使用数据库连接池。而享元模式享元模式的目的是共享，避免多次创建耗费资源，比如使用String类。
主要是通过一个类代表另一个类的功能。通常，我们创建具有现有对象的对象，以便向外界提供功能接口。
代理模式主要由这三个角色组成，抽象角色、代理角色和真实角色。
代理模式又分为静态代理、动态代理。
java.lang.reflect来进行开发。1、远程代理。
2、虚拟代理。
3、Copy-on-Write 代理。
4、保护（Protect or Access）代理。
5、Cache代理。
6、防火墙（Firewall）代理。
7、同步化（Synchronization）代理。
8、智能引用（SmartReference）代理。
优点：
1、职责清晰。
2、高扩展性。
3、智能化。
缺点：
1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
责任链模式顾名思义，就是为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。
简单的理解的话就是进行层级处理。
责任链模式主要由这三个角色组成，请求接收者接口(Handler)、请求实现者类(ConcreteHandler)和请求发送者(Client)。
需要动态指定处理某一组请求时，在不确定接受者的的情况下，向多个对象发送请求时。
优点：
耦合度低，请求者和执行者并没有必然的联系；
灵活度高，可以通过内部成员来进行更改它们执行的次序；
扩展性好，Handler的子类扩展非常方便。
缺点：
会在某程度上降低程序的性能，设置不当的话可能会出现循环调用。
在链过长时，会降低代码的阅读性以及增加代码的复杂度。
虽然责任链模式很灵活，但是牺牲的是一定的性能，因为责任链模式是层级处理，在处理数据的有一定的延迟，所所以需要低延迟的情况下，不推荐使用责任链模式。
命令模式顾名思义，是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
也就是将一个请求封装成一个对象，从而可以用不同的请求对客户进行参数化。
命令模式主要由这三个角色组成，命令对象(command)、命令执行对象(received)和命令请求对象(invoker)。
如果在有类似
命令需要指定的，就可以用命令模式，比如记录日志、撤销操作命令等。
优点：
耦合度低，请求者和执行者并没有必然的联系；
扩展性好，Command的子类可以非常容易地扩展。
缺点：
如果命令过多的话，会增加系统的复杂度 。
解释器模式顾名思义，就是对某事物进行解释。给定一个语言之后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。
解释器模式其实就是对某事物进行解释。
解释器模式主要由这四个角色组成，抽象表达式(Expression)角色、终结符表达式(Terminal Expression)角色、非终结符表达式(Nonterminal Expression)角色和环境(Context)角色。
一个简单的语法规则需要解释的场景，比如sql。
有重复的问题的时候。
优点：
扩展性好，子类扩展非常方便。
实现简单。
缺点：
可使用的场景比较少；
类过多的话，会使代码臃肿，难以维护；
迭代器模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示，属于行为型模式。 它提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
迭代器模式主要由这四个角色组成，迭代器角色（Iterator）、具体迭代器角色（Concrete Iterator）、容器角色（Container）和具体容器角色（Concrete Container）。
需要为聚合对象提供遍历的功能的时候。
优点：
灵活度高，可以通过不同的方式遍历对象；
扩展性好，可以很方便的增加新的聚合类和迭代器类而不用修改之前的代码。
缺点：
由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
访问者模式（VisitorPattern），顾名思义使用了这个模式后就可以在不修改已有程序结构的前提下，通过添加额外的访问者来完成对已有代码功能的提升，它属于行为模式。访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变。
其主要目的是将数据结构与数据操作分离。
访问者模式主要由这五个角色组成，抽象访问者(Visitor)、具体访问者(ConcreteVisitor)、抽象节点(Node)、具体节点(ConcreteNode)和结构对象(ObjectStructure)。
对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作；
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，也不希望在增加新操作时修改这些类。
访问者模式优点：
扩展性好，可以在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能；
符合单一职责原则，通过访问者将无关的行为分离，使职责单一；
访问者模式缺点：
违反了迪米特原则，因为具体元素对访问者公布细节；
违反了依赖倒置原则，依赖了具体类，没有依赖抽象；
对象结构变化困难，若对象结构发生了改变，访问者的接口和访问者的实现也都要发生相应的改变；
中介者模式（Mediator Pattern），定义了一个中介对象来封装一系列对象之间的交互关系。中介者使各个对象之间不需要显式地相互引用，从而使耦合性降低，而且可以独立地改变它们之间的交互行为，属于行为型模式。
其主要的目的是用来降低多个对象和类之间的通信复杂性。
中介者模式主要由这四个角色组成， 抽象中介者(Mediator)、具体中介者(ConcreteMediator)、 抽象同事类(Colleague)和具体同事类(ConcreteColleague) 。
通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
优点：
灵活性高，因为将同事类进行了解耦，使其不必有关联性；
降低了类的复杂度，将一对多转化成了一对一；
缺点：
中介者使用过多，会使系统变得复杂难以维护；
若不明确各个类的职责，那么就不要进行使用！
和外观模式、代理模式比较
中介者模式和外观模式、代理模式比较类似，但是又有不同。
和外观模式比较，中介者模式中，同事类必须依赖与中介者，中介者也知道同事类；但是外观模式中，子系统是不需要知道外观类的存在，并且子系统是可以脱离外观模式的。
和代理模式，代理模式的核心就是代理作用，主要还是对原先的类进行扩展或增加控制，比如进行权限控制；而中介者模式主要目的是为了减少对象之前的耦合，也就是同事类直接相互独立，互不影响。
策略模式（Strategy Pattern）属于对象的行为模式。其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
其主要目的是通过定义相似的算法，替换if else 语句写法，并且可以随时相互替换。
策略模式主要由这三个角色组成，环境角色(Context)、抽象策略角色(Strategy)和具体策略角色(ConcreteStrategy)。
如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为；
一个系统需要动态地在几种算法中选择一种;
如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现;
优点：
扩展性好，可以在不修改对象结构的情况下，为新的算法进行添加新的类进行实现；
灵活性好，可以对算法进行自由切换；
缺点：
使用策略类变多，会增加系统的复杂度。；
客户端必须知道所有的策略类才能进行调用；
模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。 这种类型的设计模式属于行为型模式。定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。
模板模式，其主要的的思想就是做一个模板，提供给客户端进行调用。
模板模式主要由抽象模板(Abstract Template)角色和具体模板(Concrete Template)角色组成。
抽象模板(Abstract Template): 定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤;定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。
具体模板(Concrete Template): 实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤;每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。
有多个子类共有逻辑相同的方法；
重要的、复杂的方法，可以考虑作为模板方法。
优点：
扩展性好，对不变的代码进行封装，对可变的进行扩展；
可维护性好，因为将公共代码进行了提取，使用的时候直接调用即可；
缺点：
因为每一个不同的实现都需要一个子类来实现，导致类的个数增加，会使系统变得复杂；
为防止恶意操作，一般模板方法都加上 final 关键词！
备忘录模式(Memento Pattern)用于保存一个对象的某个状态，以便在适当的时候恢复对象，该模式属于行为型模式。
其主要目的是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
其主要的的思想就是备份。
备忘录模式主要由这三个角色组成，备忘录角色(Memento)、发起人角色(Originator)和负责人(Caretaker)角色。
需要保存/恢复数据的相关状态场景；
优点
给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态；
实现了信息的封装，使得用户不需要关心状态的保存细节；
缺点
非常的消耗资源；
客户端必须知道所有的策略类才能进行调用；
状态模式（State Pattern）属于行为型模式，其状态的对象和一个行为随着状态对象改变而改变。
其主要目的解决的是当控制一个对象状态转换的条件表达式过于复杂是的情况。把状态的判断逻辑转移到表示不同状态一系列类中，可以把复杂的判断简单化。
主要的的思想就是提供一种状态，提供给客户端进行调用。
状态模式主要由环境角色（Context）、 抽象状态（State）和具体状态（Concrete State）组成。
环境角色（Context）: 它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的具体状态对象来处理。
具体状态角色（Concrete State）:实现抽象状态定义的接口。
行为随状态改变而改变的场景；
条件、分支语句的代替者。
优点：
扩展性好，将和状态有关的行为放到一起，增加新的的状态，只需要改变对象状态即可改变对象的行为即可；
复用性好，让多个环境对象共享一个状态对象，从而减少系统中对象的个数；
缺点：
使用状态模式会增加系统类和对象的个数，并且该模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱；
状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
在行为受状态约束的时候使用状态模式，而且状态不超过5个。
和策略模式比较
在学习状态模式的时候，很容易和策略模式搞混，因为它们实在是太像了，很难区分，在查阅一番资料之后，整理了如下的相同点和区别点。
相同点:
区别点
观察者模式又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。。
其主要目的是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
观察者模式主要由这四个角色组成，抽象主题角色（Subject）、具体主题角色（ConcreteSubject）、抽象观察者角色（Observer）和具体观察者角色（ConcreteObserver）。
需要关联行为的场景；
事件需要创建一个触发链的场景，比如监控；
跨系统的消息交换场景，比如消息队列、事件总线的处理机制。
优点:
解除耦合，让耦合的双方都依赖于抽象，从而使得各自的变换都不会影响另一边的变换。
缺点
如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间；
如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃；
观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
如果顺序执行，某一观察者错误会导致系统卡壳，建议采用异步方式。
空对象模式（NullObject Pattern）主要是通过一个空对象取代 NULL 对象实例的检查。Null 对象不是检查空值，而是反应一个不做任何动作的关系。 这样的Null 对象也可以在数据不可用的时候提供默认的行为。
其主要目的是在进行调用是不返回Null，而是返回一个空对象，防止空指针异常。
需要大量对空值进行判断的时候；
优点：
可以加强系统的稳固性，能有效防止空指针报错对整个系统的影响；
不依赖客户端便可以保证系统的稳定性；
缺点：
需要编写较多的代码来实现空值的判断，从某种方面来说不划算；
在学习设计模式的时候，主要参考书籍是《大话设计模式》以及菜鸟教程的设计模式介绍。
其实在我们学习了这么多的设计模式中，大部分可能只是听说了解过，真正经常使用的设计模式也无外乎就那几种，单例模式(数据库、线程池场景)、工厂模式(简单的crud操作中实例化的model)、策略模式(商城会员、优惠打折场景)、观察者模式(消息推送场景)、代理模式（主要是动态代理这块)、外观模式(一键调用)、装饰器模式(锦上添花场景)，但是也不全这样，使用设计模式最好根据实际的场景来使用，否则可能在不合适的场景使用了不适合的设计模式而导致代码混乱。
往期音乐推荐
一、
我们目送 那渐渐消失的行迹云 在晃眼间消逝 总是如此短暂 如像昨天起 不变的事 始终不会改变 不该存在的东西 带着遗憾消失在指间
那鸟儿还未能展翅高飞 但它总有一天会破风驰行 遥不可及的地方仍在远处 所以只能凝视深藏的愿望 孩子们走在盛夏的铁路上 流风轻抚着他们的赤脚 远离了童年
二、
这世上大部分失落，都是因为我们自己没成为更好的自己，却奢求别人成为更好的别人。
三、
平静孤寂的调子起头，两个人分开之后的沉寂 颓废，慢慢的音阶起伏，我意识到不能这样下去，我开始改变现状，变得积极。到高潮部分 我不在颓废，我走了新的目标 我迎着太阳前进。我想这就是You的含义，你是我的一段过去
四、
扶桑画师浅溪，居泰安，喜绘鲤。院前一方荷塘，锦鲤游曳，溪常与嬉戏。 其时正武德之乱，藩镇割据，战事频仍，魑魅魍魉，肆逆于道。兵戈逼泰安，街邻皆逃亡，独溪不舍锦鲤，未去。 是夜，院室倏火。有人入火护溪，言其本鲤中妖，欲取溪命，却生情愫，遂不忍为之。翌日天明，火势渐歇，人已不见。
五、
稚儿擎瓜柳棚下，细犬逐蝶窄巷中，人间繁华多笑语，惟我空余两鬓风。
六、
散落的花，火的碎片 诱人的夏夜终结
渐渐 天空闪耀，带着谁许的愿
突然绽放的烟花
美丽如梦幻，迟来脆弱的夏天
夜空中，火花舞动在今夜
枝头落下的仲夏夜之梦
愉快的凉风，热带的夜
天空飘着细雨，在喧闹的蝉鸣时节
夏末，秋天指向路边。
七、
论如何一个人在家嗨成狗。取下耳机无限的孤独感。带上耳机卧槽我是全世界。
八、
我渴望能见你一面，但请你记得，我不会开口要求见你。这不是因为骄傲，你知道我在你面前毫无骄傲可言，而是因为，唯有你也想见我的时候，我们见面才有意义。 ———《越洋情书》
九、
就算是Believe，中间也藏了一个lie；
就算是Friend，还是免不了end；
就算是Lover，还可能会over；
就算是Wife，心里也夹杂着if；
欣慰的是：即便是Forget，也曾经get，
就算impossible，但还藏着possible。
十、
人有三样东西是无法隐瞒的，咳嗽、穷困和爱；你想隐瞒越欲盖弥彰。人有三样东西是不该挥霍的，身体、金钱和爱；你想挥霍却得不偿失。人有三样东西是无法挽留的，时间、生命和爱；你想挽留却渐行渐远。人有三样东西是不该回忆的，灾难、死亡和爱；你想回忆却苦不堪言。 ——《洛丽塔》
十一、
简单，重复，毫无华丽旋律，也无厚重悲凉的伴奏。但心偏偏就被紧紧的抓住了。一种茫然却被迫紧凑的感觉。一种不知何所处的心虚。what for？
十二、
轻吟一句情话，执笔一副情画。 绽放一地情花，覆盖一片青瓦。 共饮一杯清茶，同研一碗青砂。
挽起一面轻纱，看清天边月牙。爱像水墨青花，何惧刹那芳华。
十三、
所有人和事，自己问心无愧就好，不是你的也别强求，反正离去的，都是风景，留下的，才是人生。
以上评论来自网易云！
java-study是本人在学习Java过程中记录的一些代码，也包括之前博文中使用的代码。如果感觉不错，希望顺手给个start，当然如果有不足，也希望提出。
github地址: https://github.com/xuwujing/java-study
原创不易，如果感觉不错，希望给个推荐！您的支持是我写作的最大动力！
版权声明:
作者：虚无境
博客园出处：http://www.cnblogs.com/xuwujing
CSDN出处：http://blog.csdn.net/qazwsxpcm
个人博客出处：http://www.panchengming.com
原文：https://www.cnblogs.com/xuwujing/p/10134494.html