）
+
+本文我们就来围绕这个问题来分析一下为什么JDK自身提供的构建线程池的方式并不建议使用？到底应该如何创建一个线程池呢？
+
+### Executors
+
+Executors 是一个Java中的工具类。提供工厂方法来创建不同类型的线程池。
+
+![][2]
+
+从上图中也可以看出，Executors的创建线程池的方法，创建出来的线程池都实现了ExecutorService接口。常用方法有以下几个：
+
+`newFiexedThreadPool(int Threads)`：创建固定数目线程的线程池。
+
+`newCachedThreadPool()`：创建一个可缓存的线程池，调用execute 将重用以前构造的线程（如果线程可用）。如果没有可用的线程，则创建一个新线程并添加到池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。
+
+`newSingleThreadExecutor()`创建一个单线程化的Executor。
+
+`newScheduledThreadPool(int corePoolSize)`创建一个支持定时及周期性的任务执行的线程池，多数情况下可用来替代Timer类。
+
+类看起来功能还是比较强大的，又用到了工厂模式、又有比较强的扩展性，重要的是用起来还比较方便，如：
+
+ExecutorService executor = Executors.newFixedThreadPool(nThreads) ;
+
+
+即可创建一个固定大小的线程池。
+
+但是为什么我说不建议大家使用这个类来创建线程池呢？
+
+我提到的是『不建议』，但是在阿里巴巴Java开发手册中也明确指出，而且用的词是『不允许』使用Executors创建线程池。
+

+
+### Executors存在什么问题
+
+在阿里巴巴Java开发手册中提到，使用Executors创建线程池可能会导致OOM(OutOfMemory ,内存溢出)，但是并没有说明为什么，那么接下来我们就来看一下到底为什么不允许使用Executors？
+
+我们先来一个简单的例子，模拟一下使用Executors导致OOM的情况。
+
+/**
+ * @author Hollis
+ */
+public class ExecutorsDemo {
+ private static ExecutorService executor = Executors.newFixedThreadPool(15);
+ public static void main(String[] args) {
+ for (int i = 0; i < Integer.MAX_VALUE; i++) {
+ executor.execute(new SubThread());
+ }
+ }
+}
+
+class SubThread implements Runnable {
+ @Override
+ public void run() {
+ try {
+ Thread.sleep(10000);
+ } catch (InterruptedException e) {
+ //do nothing
+ }
+ }
+}
+
+
+通过指定JVM参数：`-Xmx8m -Xms8m` 运行以上代码，会抛出OOM:
+
+Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
+ at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
+ at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
+ at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
+
+
+以上代码指出，`ExecutorsDemo.java`的第16行，就是代码中的`executor.execute(new SubThread());`。
+
+### Executors为什么存在缺陷
+
+通过上面的例子，我们知道了`Executors`创建的线程池存在OOM的风险，那么到底是什么原因导致的呢？我们需要深入`Executors`的源码来分析一下。
+
+其实，在上面的报错信息中，我们是可以看出蛛丝马迹的，在以上的代码中其实已经说了，真正的导致OOM的其实是`LinkedBlockingQueue.offer`方法。
+
+Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
+ at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
+ at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
+ at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
+
+
+如果读者翻看代码的话，也可以发现，其实底层确实是通过`LinkedBlockingQueue`实现的：
+
+public static ExecutorService newFixedThreadPool(int nThreads) {
+ return new ThreadPoolExecutor(nThreads, nThreads,
+ 0L, TimeUnit.MILLISECONDS,
+ new LinkedBlockingQueue<Runnable>());
+
+
+如果读者对Java中的阻塞队列有所了解的话，看到这里或许就能够明白原因了。
+
+Java中的`BlockingQueue`主要有两种实现，分别是`ArrayBlockingQueue` 和 `LinkedBlockingQueue`。
+
+`ArrayBlockingQueue`是一个用数组实现的有界阻塞队列，必须设置容量。
+
+`LinkedBlockingQueue`是一个用链表实现的有界阻塞队列，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为`Integer.MAX_VALUE`。
+
+这里的问题就出在：**不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。**也就是说，如果我们不设置`LinkedBlockingQueue`的容量的话，其默认容量将会是`Integer.MAX_VALUE`。
+
+而`newFixedThreadPool`中创建`LinkedBlockingQueue`时，并未指定容量。此时，`LinkedBlockingQueue`就是一个无边界队列，对于一个无边界队列来说，是可以不断的向队列中加入任务的，这种情况下就有可能因为任务过多而导致内存溢出问题。
+
+上面提到的问题主要体现在`newFixedThreadPool`和`newSingleThreadExecutor`两个工厂方法上，并不是说`newCachedThreadPool`和`newScheduledThreadPool`这两个方法就安全了，这两种方式创建的最大线程数可能是`Integer.MAX_VALUE`，而创建这么多线程，必然就有可能导致OOM。
+
+### 创建线程池的正确姿势
+
+避免使用Executors创建线程池，主要是避免使用其中的默认实现，那么我们可以自己直接调用`ThreadPoolExecutor`的构造函数来自己创建线程池。在创建的同时，给`BlockQueue`指定容量就可以了。
+
+private static ExecutorService executor = new ThreadPoolExecutor(10, 10,
+ 60L, TimeUnit.SECONDS,
+ new ArrayBlockingQueue(10));
+
+
+这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出`java.util.concurrent.RejectedExecutionException`，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。
+
+除了自己定义`ThreadPoolExecutor`外。还有其他方法。这个时候第一时间就应该想到开源类库，如apache和guava等。
+
+作者推荐使用guava提供的ThreadFactoryBuilder来创建线程池。
+
+public class ExecutorsDemo {
+
+ private static ThreadFactory namedThreadFactory = new ThreadFactoryBuilder()
+ .setNameFormat("demo-pool-%d").build();
+
+ private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
+ 0L, TimeUnit.MILLISECONDS,
+ new LinkedBlockingQueue<Runnable>(1024), namedThreadFactory, new ThreadPoolExecutor.AbortPolicy());
+
+ public static void main(String[] args) {
+
+ for (int i = 0; i < Integer.MAX_VALUE; i++) {
+ pool.execute(new SubThread());
+ }
+ }
+}
+
+
+通过上述方式创建线程时，不仅可以避免OOM的问题，还可以自定义线程名称，更加方便的出错的时候溯源。
+
+思考题，文中作者说：发生异常（Exception）要比发生错误（Error）好，为什么这么说？
+
+文中提到的《阿里巴巴Java开发手册》，请关注公众号Hollis，回复：手册。即可获得完整版PDF。
+
+ [1]: https://mp.weixin.qq.com/s/-89-CcDnSLBYy3THmcLEdQ
+ [2]: http://www.hollischuang.com/wp-content/uploads/2018/10/15406248096737.jpg
\ No newline at end of file
diff --git a/docs/basics/java-basic/CET-UTC-GMT-CST.md b/docs/basics/java-basic/CET-UTC-GMT-CST.md
index 37e0402b..86872a67 100644
--- a/docs/basics/java-basic/CET-UTC-GMT-CST.md
+++ b/docs/basics/java-basic/CET-UTC-GMT-CST.md
@@ -16,5 +16,7 @@
### 关系
CET=UTC/GMT + 1小时
+
CST=UTC/GMT +8 小时
-CST=CET+9
\ No newline at end of file
+
+CST=CET + 7 小时
diff --git a/docs/basics/java-basic/Runtime-Constant-Pool.md b/docs/basics/java-basic/Runtime-Constant-Pool.md
new file mode 100644
index 00000000..cb4d7531
--- /dev/null
+++ b/docs/basics/java-basic/Runtime-Constant-Pool.md
@@ -0,0 +1,37 @@
+运行时常量池（ Runtime Constant Pool）是每一个类或接口的常量池（ Constant_Pool）的运行时表示形式。
+
+它包括了若干种不同的常量：从编译期可知的数值字面量到必须运行期解析后才能获得的方法或字段引用。运行时常量池扮演了类似传统语言中符号表（ SymbolTable）的角色，不过它存储数据范围比通常意义上的符号表要更为广泛。
+
+每一个运行时常量池都分配在 Java 虚拟机的方法区之中，在类和接口被加载到虚拟机后，对应的运行时常量池就被创建出来。
+
+以上，是Java虚拟机规范中关于运行时常量池的定义。
+
+### 运行时常量池在JDK各个版本中的实现
+
+根据Java虚拟机规范约定：每一个运行时常量池都在Java虚拟机的方法区中分配，在加载类和接口到虚拟机后，就创建对应的运行时常量池。
+
+在不同版本的JDK中，运行时常量池所处的位置也不一样。以HotSpot为例：
+
+在JDK 1.7之前，方法区位于堆内存的永久代中，运行时常量池作为方法区的一部分，也处于永久代中。
+
+因为使用永久代实现方法区可能导致内存泄露问题，所以，从JDK1.7开始，JVM尝试解决这一问题，在1.7中，将原本位于永久代中的运行时常量池移动到堆内存中。（永久代在JDK 1.7并没有完全移除，只是原来方法区中的运行时常量池、类的静态变量等移动到了堆内存中。）
+
+在JDK 1.8中，彻底移除了永久代，方法区通过元空间的方式实现。随之，运行时常量池也在元空间中实现。
+
+### 运行时常量池中常量的来源
+
+运行时常量池中包含了若干种不同的常量：
+
+编译期可知的字面量和符号引用（来自Class常量池）
+运行期解析后可获得的常量（如String的intern方法）
+
+所以，运行时常量池中的内容包含：Class常量池中的常量、字符串常量池中的内容
+
+### 运行时常量池、Class常量池、字符串常量池的区别与联系
+
+
+虚拟机启动过程中，会将各个Class文件中的常量池载入到运行时常量池中。
+
+所以， Class常量池只是一个媒介场所。在JVM真的运行时，需要把常量池中的常量加载到内存中，进入到运行时常量池。
+
+字符串常量池可以理解为运行时常量池分出来的部分。加载时，对于class的静态常量池，如果字符串会被装到字符串常量池中。
\ No newline at end of file
diff --git a/docs/basics/java-basic/Wildcard-Character.md b/docs/basics/java-basic/Wildcard-Character.md
index b9e2a1b0..3c173ac0 100644
--- a/docs/basics/java-basic/Wildcard-Character.md
+++ b/docs/basics/java-basic/Wildcard-Character.md
@@ -1,10 +1,10 @@
`限定通配符`对类型进⾏限制， 泛型中有两种限定通配符：
-表示类型的上界，格式为：<？ extends T>，即类型必须为T类型或者T子类
-表示类型的下界，格式为：<？ super T>，即类型必须为T类型或者T的父类
+表示类型的上界，格式为：`<？ extends T>`，即类型必须为T类型或者T子类
+表示类型的下界，格式为：`<？ super T>`，即类型必须为T类型或者T的父类
泛型类型必须⽤限定内的类型来进⾏初始化，否则会导致编译错误。
-`⾮限定通配符`表⽰可以⽤任意泛型类型来替代，类型为
\ No newline at end of file
+`⾮限定通配符`表⽰可以⽤任意泛型类型来替代，类型为``
\ No newline at end of file
diff --git a/docs/basics/java-basic/_sidebar.md b/docs/basics/java-basic/_sidebar.md
deleted file mode 100644
index ca96911f..00000000
--- a/docs/basics/java-basic/_sidebar.md
+++ /dev/null
@@ -1,357 +0,0 @@
-
-* 基本数据类型
-
- * [8种基本数据类型](/basics/java-basic/basic-data-types.md)
-
- * [整型中byte、short、int、long的取值范围](/basics/java-basic/integer-scope.md)
-
- * [什么是浮点型？](/basics/java-basic/float.md)
-
- * [什么是单精度和双精度？](/basics/java-basic/single-double-float.md)
-
- * [为什么不能用浮点型表示金额？](/basics/java-basic/float-amount.md)
-
-* 自动拆装箱
-
- * [自动拆装箱](/basics/java-basic/boxing-unboxing.md)
-
- * [Integer的缓存机制](/basics/java-basic/integer-cache.md)
-
- * 如何正确定义接口的返回值(boolean/Boolean)类型及命名(success/Success)
-
-* String
-
- * [字符串的不可变性](/basics/java-basic/final-string.md)
-
- * [JDK 6和JDK 7中substring的原理及区别](/basics/java-basic/substring.md)
-
- * replaceFirst、replaceAll、replace区别
-
- * [String对“+”的重载](/basics/java-basic/string-append.md)
-
- * [字符串拼接的几种方式和区别](/basics/java-basic/string-concat.md)
-
- * [String.valueOf和Integer.toString的区别](/basics/java-basic/value-of-vs-to-string.md)
-
- * [switch对String的支持](/basics/java-basic/switch-string.md)
-
- * 字符串池
-
- * 常量池（运行时常量池、Class常量池）
-
- * intern
-
-* Java中各种关键字
-
- * transient
-
- * instanceof
-
- * volatile
-
- * synchronized
-
- * final
-
- * static
-
- * const
-
-* 集合类
-
- * [Collection和Collections区别](/basics/java-basic/Collection-vs-Collections.md)
-
- * 常用集合类的使用
-
- * [Set和List区别？](/basics/java-basic/set-vs-list.md)
-
- * [ArrayList和LinkedList和Vector的区别](/basics/java-basic/arraylist-vs-linkedlist-vs-vector.md)
-
- * [SynchronizedList和Vector的区别](/basics/java-basic/synchronizedlist-vector.md)
-
- * [Set如何保证元素不重复?](/basics/java-basic/set-repetition.md)
-
- * [HashMap、HashTable、ConcurrentHashMap区别](/basics/java-basic/HashMap-HashTable-ConcurrentHashMap.md)
-
- * Java 8中Map相关的红黑树的引用背景、原理等
-
- * HashMap的容量、扩容、hash等原理
-
- * [Java 8中stream相关用法](/basics/java-basic/stream.md)
-
- * Apache集合处理工具类的使用
-
- * 不同版本的JDK中HashMap的实现的区别以及原因
-
- * [Arrays.asList获得的List使用时需要注意什么](/basics/java-basic/Arrays-asList.md)
-
- * Collection如何迭代
-
- * [Enumeration和Iterator区别](/basics/java-basic/Enumeration-vs-Iterator.md)
-
- * 如何在遍历的同时删除ArrayList中的元素
-
- * [fail-fast 和 fail-safe](/basics/java-basic/fail-fast-vs-fail-safe.md)
-
- * [CopyOnWriteArrayList](/basics/java-basic/CopyOnWriteArrayList.md)
-
- * [ConcurrentSkipListMap](/basics/java-basic/ConcurrentSkipListMap.md)
-
-* 枚举
-
- * [枚举的用法](/basics/java-basic/enum-usage.md)
-
- * [枚举的实现](/basics/java-basic/enum-impl.md)
-
- * [枚举与单例](/basics/java-basic/enum-singleton.md)
-
- * Enum类
-
- * [Java枚举如何比较](/basics/java-basic/enum-compare.md)
-
- * [switch对枚举的支持](/basics/java-basic/enum-switch.md)
-
- * [枚举的序列化如何实现](/basics/java-basic/enum-serializable.md)
-
- * [枚举的线程安全性问题](/basics/java-basic/enum-thread-safe.md)
-
-* IO
-
- * [字符流、字节流](/basics/java-basic/byte-stream-vs-character-stream.md)
-
- * [输入流、输出流](/basics/java-basic/input-stream-vs-output-stream.md)
-
- * 字节流和字符流之间的相互转换
-
- * [同步、异步](/basics/java-basic/synchronized-vs-asynchronization.md)
-
- * [阻塞、非阻塞](/basics/java-basic/block-vs-non-blocking.md)
-
- * [Linux 5种IO模型](/basics/java-basic/linux-io.md)
-
- * [BIO、NIO和AIO的区别、三种IO的用法与原理](/basics/java-basic/bio-vs-nio-vs-aio.md)
-
- * netty
-
-* 反射
-
- * [反射](/basics/java-basic/reflection.md)与工厂模式、
-
- * [反射有什么作用](/basics/java-basic/usage-of-reflection.md)
-
- * [Class类](/basics/java-basic/Class.md)
-
- * `java.lang.reflect.*`
-
-* 动态代理
-
- * [静态代理](/basics/java-basic/static-proxy.md)
-
- * [动态代理](/basics/java-basic/dynamic-proxy.md)
-
- * [动态代理和反射的关系](/basics/java-basic/dynamic-proxy-vs-reflection.md)
-
- * [动态代理的几种实现方式](/basics/java-basic/dynamic-proxy-implementation.md)
-
- * [AOP](/basics/java-basic/aop-vs-proxy.md)
-
-* 序列化
-
- * [什么是序列化与反序列化](basics/java-basic/serialize.md)
-
- * [Java如何实现序列化与反序列化](basics/java-basic/serialize-in-java.md)
-
- * [Serializable 和 Externalizable 有何不同](basics/java-basic/diff-serializable-vs-externalizable.md)
-
- * 为什么序列化
-
- * [serialVersionUID](basics/java-basic/serialVersionUID.md)
-
- * [为什么serialVersionUID不能随便改](basics/java-basic/serialVersionUID-modify.md)
-
- * [transient](basics/java-basic/transient.md)
-
- * [序列化底层原理](basics/java-basic/serialize-principle.md)
-
- * [序列化如何破坏单例模式](basics/java-basic/serialize-singleton.md)
-
- * [protobuf](basics/java-basic/protobuf.md)
-
- * 为什么说序列化并不安全
-
-* 注解
-
- * [元注解](/basics/java-basic/meta-annotation.md)
-
- * [自定义注解](/basics/java-basic/custom-annotation.md)
-
- * Java中常用注解使用
-
- * 注解与反射的结合
-
- * [如何自定义一个注解？](/basics/java-basic/create-annotation.md)
-
- * [Spring常用注解](/basics/java-basic/annotation-in-spring.md)
-
-* 泛型
-
- * [什么是泛型](/basics/java-basic/generics.md)
-
- * [类型擦除](/basics/java-basic/type-erasue.md)
-
- * [泛型带来的问题](/basics/java-basic/generics-problem.md)
-
- * [泛型中K T V E ？ object等的含义](/basics/java-basic/k-t-v-e.md)
-
- * 泛型各种用法
-
- * [限定通配符和非限定通配符](/basics/java-basic/Wildcard-Character.md)
-
- * [上下界限定符extends 和 super](/basics/java-basic/extends-vs-super.md)
-
- * [`List
][5]
+
+## 用途
+
+抽象工厂模式和工厂方法模式一样，都符合开放-封闭原则。但是不同的是，工厂方法模式在增加一个具体产品的时候，都要增加对应的工厂。但是抽象工厂模式只有在新增一个类型的具体产品时才需要新增工厂。也就是说，工厂方法模式的一个工厂只能创建一个具体产品。而抽象工厂模式的一个工厂可以创建属于一类类型的多种具体产品。工厂创建产品的个数介于简单工厂模式和工厂方法模式之间。
+
+在以下情况下可以使用抽象工厂模式：
+
+> 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。
+>
+> 系统中有多于一个的产品族，而每次只使用其中某一产品族。
+>
+> 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
+>
+> 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。
+
+## 实现方式
+
+抽象工厂模式包含如下角色：
+
+> AbstractFactory(抽象工厂)：用于声明生成抽象产品的方法
+>
+> ConcreteFactory(具体工厂)：实现了抽象工厂声明的生成抽象产品的方法，生成一组具体产品，这些产品构成了一个产品族，每一个产品都位于某个产品等级结构中；
+>
+> AbstractProduct(抽象产品)：为每种产品声明接口，在抽象产品中定义了产品的抽象业务方法；
+>
+> Product(具体产品)：定义具体工厂生产的具体产品对象，实现抽象产品接口中定义的业务方法。
+
+本文的例子采用一个汽车代工厂造汽车的例子。假设我们是一家汽车代工厂商，我们负责给奔驰和特斯拉两家公司制造车子。我们简单的把奔驰车理解为需要加油的车，特斯拉为需要充电的车。其中奔驰车中包含跑车和商务车两种，特斯拉同样也包含跑车和商务车。
+
+[
][6]
+
+以上场景，我们就可以把跑车和商务车分别对待，对于跑车有单独的工厂创建，商务车也有单独的工厂。这样，以后无论是再帮任何其他厂商造车，只要是跑车或者商务车我们都不需要再引入工厂。同样，如果我们要增加一种其他类型的车，比如越野车，我们也不需要对跑车或者商务车的任何东西做修改。
+
+下面是抽象产品，奔驰车和特斯拉车：
+
+ public interface BenzCar {
+
+ //加汽油
+ public void gasUp();
+
+ }
+
+ public interface TeslaCar {
+
+ //充电
+ public void charge();
+ }
+
+
+下面是具体产品，奔驰跑车、奔驰商务车、特斯拉跑车、特斯拉商务车：
+
+ public class BenzSportCar implements BenzCar {
+ public void gasUp() {
+ System.out.println("给我的奔驰跑车加最好的汽油");
+ }
+ }
+
+ public class BenzBusinessCar implements BenzCar{
+ public void gasUp() {
+ System.out.println("给我的奔驰商务车加一般的汽油");
+ }
+ }
+
+ public class TeslaSportCar implements TeslaCar {
+ public void charge() {
+ System.out.println("给我特斯拉跑车冲满电");
+ }
+ }
+
+ public class TeslaBusinessCar implements TeslaCar {
+ public void charge() {
+ System.out.println("不用给我特斯拉商务车冲满电");
+ }
+ }
+
+
+下面是抽象工厂：
+
+ public interface CarFactory {
+
+ public BenzCar getBenzCar();
+ public TeslaCar getTeslaCar();
+ }
+
+
+下面是具体工厂：
+
+ public class SportCarFactory implements CarFactory {
+ public BenzCar getBenzCar() {
+ return new BenzSportCar();
+ }
+
+ public TeslaCar getTeslaCar() {
+ return new TeslaSportCar();
+ }
+ }
+
+ public class BusinessCarFactory implements CarFactory {
+ public BenzCar getBenzCar() {
+ return new BenzBusinessCar();
+ }
+
+ public TeslaCar getTeslaCar() {
+ return new TeslaBusinessCar();
+ }
+ }
+
+
+## “开闭原则”的倾斜性
+
+“开闭原则”要求系统对扩展开放，对修改封闭，通过扩展达到增强其功能的目的。对于涉及到多个产品族与多个产品等级结构的系统，其功能增强包括两方面：
+
+> 增加产品族：对于增加新的产品族，工厂方法模式很好的支持了“开闭原则”，对于新增加的产品族，只需要对应增加一个新的具体工厂即可，对已有代码无须做任何修改。
+>
+> 增加新的产品等级结构：对于增加新的产品等级结构，需要修改所有的工厂角色，包括抽象工厂类，在所有的工厂类中都需要增加生产新产品的方法，不能很好地支持“开闭原则”。
+
+抽象工厂模式的这种性质称为“开闭原则”的倾斜性，抽象工厂模式以一种倾斜的方式支持增加新的产品，它为新产品族的增加提供方便，但不能为新的产品等级结构的增加提供这样的方便。
+
+## 三种工厂模式之间的关系
+
+当抽象工厂模式中每一个具体工厂类只创建一个产品对象，也就是只存在一个产品等级结构时，抽象工厂模式退化成工厂方法模式；
+
+抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构。
+
+当工厂方法模式中抽象工厂与具体工厂合并，提供一个统一的工厂来创建产品对象，并将创建对象的工厂方法设计为静态方法时，工厂方法模式退化成简单工厂模式。
+
+## 总结
+
+抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。
+
+抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。
+
+抽象工厂模式的主要优点是隔离了具体类的生成，使得客户并不需要知道什么被创建，而且每次可以通过具体工厂类创建一个产品族中的多个对象，增加或者替换产品族比较方便，增加新的具体工厂和产品族很方便；主要缺点在于增加新的产品等级结构很复杂，需要修改抽象工厂和所有的具体工厂类，对“开闭原则”的支持呈现倾斜性。
+
+文中所有代码见[GitHub][7]
+
+## 参考资料
+
+[大话设计模式][8]
+
+[深入浅出设计模式][9]
+
+[抽象工厂模式(Factory Method Pattern)][10]
+
+ [1]: http://www.hollischuang.com/archives/category/%E7%BB%BC%E5%90%88%E5%BA%94%E7%94%A8/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F
+ [2]: http://www.hollischuang.com/archives/1401
+ [3]: http://www.hollischuang.com/archives/1408
+ [4]: http://www.hollischuang.com/archives/1391
+ [5]: http://www.hollischuang.com/wp-content/uploads/2016/04/QQ20160419-0.png
+ [6]: http://www.hollischuang.com/wp-content/uploads/2016/04/QQ20160419-1.png
+ [7]: https://github.com/hollischuang/DesignPattern
+ [8]: http://s.click.taobao.com/t?e=m=2&s=R5B/xd29JVMcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67jN2wQzI0ZBVHBMajAjK1gBpS4hLH/P02ckKYNRBWOBBey11vvWwHXSniyi5vWXIZkKWZZq7zWpCC8X3k5aQlui0qVGgqDL2o8YMXU3NNCg/&pvid=10_42.120.73.203_224_1460382841310
+ [9]: http://s.click.taobao.com/t?e=m%3D2%26s%3DObpq8Qxse2EcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67utJaEGcptl2kfkm8XrrgBtpS4hLH%2FP02ckKYNRBWOBBey11vvWwHXTpkOAWGyim%2Bw2PNKvM2u52N5aP5%2Bgx7zgh4LxdBQDQSXEqY%2Bakgpmw&pvid=10_121.0.29.199_322_1460465025379
+ [10]: http://design-patterns.readthedocs.org/zh_CN/latest/creational_patterns/abstract_factory.html#id14
\ No newline at end of file
diff --git a/docs/advance/design-patterns/adapter-pattern.md b/docs/advance/design-patterns/adapter-pattern.md
new file mode 100644
index 00000000..49384606
--- /dev/null
+++ b/docs/advance/design-patterns/adapter-pattern.md
@@ -0,0 +1,266 @@
+
+## 概念
+
+GOF是这样给适配器模式(`Adapter`)定义的：将一个类的接口转化成用户需要的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
+
+GOF中将适配器模式分为类适配器模式和对象适配器模式。区别仅在于适配器角色对于被适配角色的适配是通过继承还是组合来实现的。由于在Java 中不支持多重继承，而且有破坏封装之嫌。而且我们也提倡[多用组合少用继承][2]。所以本文主要介绍对象适配器。
+
+## 用途
+
+相信大家都有这样的生活常识：就是目前我们使用的电子设备充电器的型号是不一样的。现在主流的手机充电器口主要包含Mini Usb、Micro Usb和Lightning三种。其中Mini Usb广泛出现在读卡器、MP3、数码相机以及移动硬盘上。由于Micro Usb比Mini Usb更薄，所有广泛应用于手机上，常见于安卓手机。还有一个比较常见的充电器口就是苹果手机常用的Lightning。
+
+当然，特定型号的手机只能使用特定型号的充电器充电。比如Iphone6手机只能使用Lightning接口的充电器进行充电。但是，如果我们身边只有一条安卓的Micro Usb充电器线的话，我们能不能为苹果手机充电呢？答案是肯定的，只要有一个适配器就可以了。
+
+
+
+适配器，在我们日常生活中随处可见。适配器模式也正是解决了类似的问题。
+
+在程序设计过程中我们可能也遇到类似的场景：
+
+> 1、系统需要使用现有的类，而此类的接口不符合系统的需要。
+>
+> 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。
+>
+> 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
+
+以上场景都适合使用适配器模式。
+
+## 实现方式
+
+适配器模式包含如下角色：
+
+> Target：目标抽象类
+>
+> Adapter：适配器类
+>
+> Adaptee：适配者类
+>
+> Client：客户类
+
+
+
+这里采用文章开头介绍的手机充电口的例子，我们定义一个适配器，该适配器的功能就是使用安卓充电器给苹果设备充电。
+
+先定义接口：
+
+ /**
+ * MicroUsb充电器接口
+ */
+ public interface MicroUsbInterface {
+ public void chargeWithMicroUsb();
+ }
+
+ /**
+ * Lightning充电器接口
+ */
+ public interface LightningInterface {
+ public void chargeWithLightning();
+ }
+
+
+定义具体的实现类
+
+ /**
+ * 安卓设备的充电器
+ */
+ public class AndroidCharger implements MicroUsbInterface {
+ @Override
+ public void chargeWithMicroUsb() {
+ System.out.println("使用MicroUsb型号的充电器充电...");
+ }
+ }
+
+ /**
+ * 苹果设备的充电器
+ */
+ public class AppleCharger implements LightningInterface {
+ @Override
+ public void chargeWithLightning() {
+ System.out.println("使用Lightning型号的充电器充电...");
+ }
+ }
+
+
+> 因为我们要使用适配器模式将MicroUsb转成Lightning，所以这里的AppleCharger是本来不需要定义的。因为我们使用适配器的目的就是代替新建一个他。这里定义出来是为了使例子更加完整。
+
+定义两个手机
+
+ public class Iphone6Plus {
+
+ private LightningInterface lightningInterface;
+
+ public Iphone6Plus() {
+ }
+
+ public Iphone6Plus(LightningInterface lightningInterface) {
+ this.lightningInterface = lightningInterface;
+ }
+
+ public void charge() {
+ System.out.println("开始给我的Iphone6Plus手机充电...");
+ lightningInterface.chargeWithLightning();
+ System.out.println("结束给我的Iphone6Plus手机充电...");
+ }
+
+ public LightningInterface getLightningInterface() {
+ return lightningInterface;
+ }
+
+ public void setLightningInterface(LightningInterface lightningInterface) {
+ this.lightningInterface = lightningInterface;
+ }
+ }
+
+ public class GalaxyS7 {
+
+ private MicroUsbInterface microUsbInterface;
+
+ public GalaxyS7() {
+ }
+
+ public GalaxyS7(MicroUsbInterface microUsbInterface) {
+ this.microUsbInterface = microUsbInterface;
+ }
+
+ public void charge(){
+ System.out.println("开始给我的GalaxyS7手机充电...");
+ microUsbInterface.chargeWithMicroUsb();
+ System.out.println("结束给我的GalaxyS7手机充电...");
+ }
+
+ public MicroUsbInterface getMicroUsbInterface() {
+ return microUsbInterface;
+ }
+
+ public void setMicroUsbInterface(MicroUsbInterface microUsbInterface) {
+ this.microUsbInterface = microUsbInterface;
+ }
+ }
+
+
+这里定义手机的作用是为了更方便的理解适配器模式，在该模式中他不扮演任何角色。
+
+定义适配器
+
+ /**
+ * 适配器,将MicroUsb接口转成Lightning接口
+ */
+ public class Adapter implements LightningInterface {
+ private MicroUsbInterface microUsbInterface;
+
+ public Adapter() {
+ }
+
+ public Adapter(MicroUsbInterface microUsbInterface) {
+ this.microUsbInterface = microUsbInterface;
+ }
+
+ @Override
+ public void chargeWithLightning() {
+ microUsbInterface.chargeWithMicroUsb();
+ }
+
+ public MicroUsbInterface getMicroUsbInterface() {
+ return microUsbInterface;
+ }
+
+ public void setMicroUsbInterface(MicroUsbInterface microUsbInterface) {
+ this.microUsbInterface = microUsbInterface;
+ }
+ }
+
+
+该适配器的功能是把一个MicroUsb转换成Lightning。实现方式是实现目标类的接口（`LightningInterface`），然后使用组合的方式，在该适配器中定义microUsb。然后在重写的`chargeWithLightning（）`方法中，采用microUsb的方法来实现具体细节。
+
+定义客户端
+
+ public class Main {
+
+ public static void main(String[] args) {
+ Iphone6Plus iphone6Plus = new Iphone6Plus(new AppleCharger());
+ iphone6Plus.charge();
+
+ System.out.println("==============================");
+
+ GalaxyS7 galaxyS7 = new GalaxyS7(new AndroidCharger());
+ galaxyS7.charge();
+
+ System.out.println("==============================");
+
+ Adapter adapter = new Adapter(new AndroidCharger());
+ Iphone6Plus newIphone = new Iphone6Plus();
+ newIphone.setLightningInterface(adapter);
+ newIphone.charge();
+ }
+ }
+
+
+输出结果：
+
+ 开始给我的Iphone6Plus手机充电...
+ 使用Lightning型号的充电器充电...
+ 结束给我的Iphone6Plus手机充电...
+ ==============================
+ 开始给我的GalaxyS7手机充电...
+ 使用MicroUsb型号的充电器充电...
+ 结束给我的GalaxyS7手机充电...
+ ==============================
+ 开始给我的Iphone6Plus手机充电...
+ 使用MicroUsb型号的充电器充电...
+ 结束给我的Iphone6Plus手机充电...
+
+
+上面的例子通过适配器，把一个MicroUsb型号的充电器用来给Iphone充电。从代码层面，就是通过适配器复用了MicroUsb接口及其实现类。在很大程度上复用了已有的代码。
+
+## 优缺点
+
+### 优点
+
+将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，而无须修改原有代码。
+
+增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性。
+
+灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。
+
+### 缺点
+
+过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
+
+对于类适配器而言，由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类
+
+## 总结
+
+结构型模式描述如何将类或者对象结合在一起形成更大的结构。
+
+适配器模式用于将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。
+
+适配器模式包含四个角色：
+
+> 目标抽象类定义客户要用的特定领域的接口；
+>
+> 适配器类可以调用另一个接口，作为一个转换器，对适配者和抽象目标类进行适配，它是适配器模式的核心；
+>
+> 适配者类是被适配的角色，它定义了一个已经存在的接口，这个接口需要适配；
+>
+> 在客户类中针对目标抽象类进行编程，调用在目标抽象类中定义的业务方法。
+
+在对象适配器模式中，适配器类继承了目标抽象类(或实现接口)并定义了一个适配者类的对象实例，在所继承的目标抽象类方法中调用适配者类的相应业务方法。
+
+适配器模式的主要优点是将目标类和适配者类解耦，增加了类的透明性和复用性，同时系统的灵活性和扩展性都非常好，更换适配器或者增加新的适配器都非常方便，符合“[开闭原则][3]”；类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类，对象适配器模式的缺点是很难置换适配者类的方法。
+
+适配器模式适用情况包括：系统需要使用现有的类，而这些类的接口不符合系统的需要；想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类一起工作。
+
+## 参考资料
+
+[适配器模式][4]
+
+[适配器模式][5]
+
+文中所有代码见[GitHub][6]
+
+ [1]: http://www.hollischuang.com/archives/category/%E7%BB%BC%E5%90%88%E5%BA%94%E7%94%A8/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F
+ [2]: http://www.hollischuang.com/archives/1319
+ [3]: http://www.hollischuang.com/archives/220
+ [4]: http://www.runoob.com/design-pattern/adapter-pattern.html
+ [5]: http://design-patterns.readthedocs.io/zh_CN/latest/structural_patterns/adapter.html
+ [6]: https://github.com/hollischuang/DesignPattern
\ No newline at end of file
diff --git a/docs/advance/design-patterns/builder-pattern.md b/docs/advance/design-patterns/builder-pattern.md
new file mode 100644
index 00000000..23c891a1
--- /dev/null
+++ b/docs/advance/design-patterns/builder-pattern.md
@@ -0,0 +1,266 @@
+
+## 概念
+
+建造者模式（英：Builder Pattern）是一种创建型设计模式，又名：生成器模式。GOF 给建造者模式的定义为：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。这句话说的比较抽象，其实解释一下就是：将建造复杂对象的过程和组成对象的部件解耦。
+
+## 用途
+
+假设现在我们是一家网游设计公司，现在我们要"抄袭"梦幻西游这款游戏，你是该公司的游戏角色设计人员。你怎么设计出该游戏中的各种角色呢？ 在梦幻西游来中包括人、仙、魔等种族的角色，而每种不同的种族的角色中又包含龙太子、逍遥生等具体的角色。
+
+作为一个出色的开发人员，我们设计的角色生成系统应该包含以下功能和特性：
+
+> 为了保证游戏平衡，所有角色的基本属性应该一致
+>
+> 因为角色的创建过程可能很复杂，所以角色的生成细节不应该对外暴露
+>
+> 随时可以新增角色
+>
+> 对某个具体角色的修改应该不影响其他角色
+
+其实，对于角色的设计，我们可以使用抽象工厂模式，将同一种族的角色看成是一个产品族。但是，这样做可能存在一个问题，那就是我们可能要在每个角色的创建过程中都要从头到尾的构建一遍该角色。比如一个角色包含头部、身体。其中头部又包括脸部、和其他部位。其中脸部又包含眉毛、嘴巴、鼻子等部位。整个角色的创建过程是极其复杂的。很容易遗漏其中的某个步骤。
+
+那么，我们可以将这些具体部位的创建工作和对象的创建进行解耦。这就是建造者模式。
+
+## 实现方式
+
+建造者模式包含如下角色：
+
+> Builder：抽象建造者(`Builder`)
+>
+> ConcreteBuilder：具体建造者(`CommonBuilder`、`SuperBuilder`)
+>
+> Director：指挥者(`Director`)
+>
+> Product：产品角色(`Role`)
+
+[
][2]
+
+这里采用设计角色的例子，为了便于理解，我们只创建两个角色，分别是普通角色和超级角色。他们都有设置头部、脸部、身体、气血值、魔法值、能量值等方法。值得注意的是设置脸部是依赖于设置头部的，要有先后顺序。
+
+产品角色：Role
+
+ public class Role {
+
+ private String head; //头部
+ private String face; //脸部（脸部依赖于头部）
+ private String body; //身体
+ private Double hp; //生命值
+ private Double sp; //能量值
+ private Double mp; //魔法值
+
+ //setter and getter
+ // toString
+ }
+
+
+抽象建造者：Builder
+
+ public abstract class Builder {
+
+ protected Role role = new Role();
+
+ public abstract void buildHead();
+
+ public abstract void buildFace();
+
+ public abstract void buildBody();
+
+ public abstract void buildHp();
+
+ public abstract void buildSp();
+
+ public abstract void buildMp();
+
+ public Role getResult() {
+ return role;
+ }
+ }
+
+
+具体建造者：
+
+ public class CommonRoleBuilder extends Builder {
+
+ private Role role = new Role();
+
+ @Override
+ public void buildHead() {
+ role.setBody("common head");
+ }
+
+ @Override
+ public void buildFace() {
+ role.setFace("common face");
+ }
+
+ @Override
+ public void buildBody() {
+ role.setBody("common body");
+ }
+
+ @Override
+ public void buildHp() {
+ role.setHp(100d);
+ }
+
+ @Override
+ public void buildSp() {
+ role.setSp(100d);
+ }
+
+ @Override
+ public void buildMp() {
+ role.setMp(100d);
+ }
+
+ @Override
+ public Role getResult() {
+ return role;
+ }
+ }
+
+ public class SuperRoleBuilder extends Builder {
+
+ private Role role = new Role();
+
+ @Override
+ public void buildHead() {
+ role.setBody("suoer head");
+ }
+
+ @Override
+ public void buildFace() {
+ role.setFace("super face");
+ }
+
+ @Override
+ public void buildBody() {
+ role.setBody("super body");
+ }
+
+ @Override
+ public void buildHp() {
+ role.setHp(120d);
+ }
+
+ @Override
+ public void buildSp() {
+ role.setSp(120d);
+ }
+
+ @Override
+ public void buildMp() {
+ role.setMp(120d);
+ }
+
+ @Override
+ public Role getResult() {
+ return role;
+ }
+ }
+
+
+指挥者：
+
+ public class Director {
+
+ public void construct(Builder builder){
+ builder.buildBody();
+ builder.buildHead();
+ builder.buildFace();
+ builder.buildHp();
+ builder.buildMp();
+ builder.buildSp();
+ }
+ }
+
+
+测试类：
+
+ public class Main {
+
+ public static void main(String[] args) {
+
+ Director director = new Director();
+ Builder commonBuilder = new CommonRoleBuilder();
+
+ director.construct(commonBuilder);
+ Role commonRole = commonBuilder.getResult();
+ System.out.println(commonRole);
+
+ }
+ }
+
+
+到这里，一个建造者模式已经完成了，是不是很简单？
+
+* * *
+
+再回到之前的需求，看看我们是否都满足？
+
+由于建造角色的过程比较复杂，其中还有相互依赖关系（如脸部依赖于头部），所以我们使用建造者模式将将建造复杂对象的过程和组成对象的部件解耦。这样既保证了基本属性全都一致（这里的一致指的是该包含的应该全都包含）也封装了其中的具体实现细节。
+
+同时，在修改某个具体角色的时候我们只需要修改对应的具体角色就可以了，不会影响到其他角色。
+
+如果需要新增角色，只要再增加一个具体建造者，并在该建造者中写好具体细节的建造部分代码就OK了。
+
+## 建造者模式的优缺点
+
+### 优点
+
+建造者模式的**封装性很好。使用建造者模式可以有效的封装变化**，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。
+
+在建造者模式中，**客户端不必知道产品内部组成的细节**，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
+
+**可以更加精细地控制产品的创建过程** 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
+
+其次，**建造者模式很容易进行扩展**。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。
+
+### 缺点
+
+建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
+
+如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
+
+## 适用环境
+
+在以下情况下可以使用建造者模式：
+
+> 需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
+>
+> 需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
+>
+> 对象的创建过程独立于创建该对象的类。在建造者模式中引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类中。
+>
+> 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。
+
+## 建造者模式与工厂模式的区别
+
+我们可以看到，建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个"指挥者"的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。
+
+与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。
+
+也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。
+
+建造者模式与工厂模式类似，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。哈哈哈。。。
+
+## 总结
+
+建造者模式将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
+
+在建造者模式的结构中引入了一个指挥者类，该类的作用主要有两个：一方面它隔离了客户与生产过程；另一方面它负责控制产品的生成过程。指挥者针对抽象建造者编程，客户端只需要知道具体建造者的类型，即可通过指挥者类调用建造者的相关方法，返回一个完整的产品对象。
+
+## 参考资料
+
+[大话设计模式][3]
+
+[深入浅出设计模式][4]
+
+[建造者模式][5]
+
+
+ [1]: http://www.hollischuang.com/archives/category/%E7%BB%BC%E5%90%88%E5%BA%94%E7%94%A8/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F
+ [2]: http://www.hollischuang.com/wp-content/uploads/2016/05/Builder.jpg
+ [3]: http://s.click.taobao.com/t?e=m=2&s=R5B/xd29JVMcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67jN2wQzI0ZBVHBMajAjK1gBpS4hLH/P02ckKYNRBWOBBey11vvWwHXSniyi5vWXIZkKWZZq7zWpCC8X3k5aQlui0qVGgqDL2o8YMXU3NNCg/&pvid=10_42.120.73.203_224_1460382841310
+ [4]: http://s.click.taobao.com/t?e=m=2&s=Obpq8Qxse2EcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67utJaEGcptl2kfkm8XrrgBtpS4hLH/P02ckKYNRBWOBBey11vvWwHXTpkOAWGyim%2bw2PNKvM2u52N5aP5%2bgx7zgh4LxdBQDQSXEqY%2bakgpmw&pvid=10_121.0.29.199_322_1460465025379
+ [5]: http://design-patterns.readthedocs.io/zh_CN/latest/creational_patterns/builder.html
\ No newline at end of file
diff --git a/docs/advance/design-patterns/factory-method-pattern.md b/docs/advance/design-patterns/factory-method-pattern.md
new file mode 100644
index 00000000..f8c58453
--- /dev/null
+++ b/docs/advance/design-patterns/factory-method-pattern.md
@@ -0,0 +1,157 @@
+## 概念
+
+工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。
+
+工厂方法模式是一种实现了“工厂”概念的面向对象设计模式。就像其他创建型模式一样，它也是处理在不指定对象具体类型的情况下创建对象的问题。
+
+> 工厂方法模式的实质是“定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。工厂方法让类的实例化推迟到子类中进行。”
+
+## 用途
+
+工厂方法模式和[简单工厂模式][2]虽然都是通过工厂来创建对象，他们之间最大的不同是——**工厂方法模式在设计上完全完全符合“[开闭原则][3]”。**
+
+在以下情况下可以使用工厂方法模式：
+
+> 一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
+>
+> 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和[里氏代换原则][3]，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
+>
+> 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。
+
+## 实现方式
+
+工厂方法模式包含如下角色：
+
+> Product：抽象产品（`Operation`）
+>
+> ConcreteProduct：具体产品(`OperationAdd`)
+>
+> Factory：抽象工厂(`IFactory`)
+>
+> ConcreteFactory：具体工厂(`AddFactory`)
+
+[
][4]
+
+这里还用计算器的例子。在保持`Operation`，`OperationAdd`，`OperationDiv`，`OperationSub`，`OperationMul`等几个方法不变的情况下，修改简单工厂模式中的工厂类（`OperationFactory`）。替代原有的那个"万能"的大工厂类，这里使用工厂方法来代替：
+
+ //工厂接口
+ public interface IFactory {
+ Operation CreateOption();
+ }
+
+ //加法类工厂
+ public class AddFactory implements IFactory {
+
+ public Operation CreateOption() {
+ return new OperationAdd();
+ }
+ }
+
+ //除法类工厂
+ public class DivFactory implements IFactory {
+
+ public Operation CreateOption() {
+ return new OperationDiv();
+ }
+ }
+
+ //除法类工厂
+ public class MulFactory implements IFactory {
+
+ public Operation CreateOption() {
+ return new OperationMul();
+ }
+ }
+
+ //减法类工厂
+ public class SubFactory implements IFactory {
+
+ public Operation CreateOption() {
+ return new OperationSub();
+ }
+ }
+
+
+这样，在客户端中想要执行加法运算时，需要以下方式：
+
+ public class Main {
+
+ public static void main(String[] args) {
+ IFactory factory = new AddFactory();
+ Operation operationAdd = factory.CreateOption();
+ operationAdd.setValue1(10);
+ operationAdd.setValue2(5);
+ System.out.println(operationAdd.getResult());
+ }
+ }
+
+
+到这里，一个工厂方法模式就已经写好了。
+
+* * *
+
+从代码量上看，这种工厂方法模式比简单工厂方法模式更加复杂。针对不同的操作（Operation）类都有对应的工厂。很多人会有以下疑问：
+
+> 貌似工厂方法模式比简单工厂模式要复杂的多？
+>
+> 工厂方法模式和我自己创建对象没什么区别？为什么要多搞出一些工厂来？
+
+下面就针对以上两个问题来深入理解一下工厂方法模式。
+
+## 工厂方法模式的利与弊
+
+### 为什么要使用工厂来创建对象？
+
+> 封装对象的创建过程
+
+在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户**隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。**
+
+基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。**它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。**工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
+
+### 为什么每种对象要单独有一个工厂？
+
+> 符合『[开放-封闭原则][5]』
+
+主要目的是为了解耦。在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“[开闭原则][3]”。
+
+以上就是工厂方法模式的优点。但是，工厂模式也有一些不尽如人意的地方：
+
+> 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
+>
+> 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
+
+## 工厂方法与简单工厂的区别
+
+工厂模式克服了简单工厂模式违背[开放-封闭原则][3]的缺点，又保持了封装对象创建过程的优点。
+
+他们都是集中封装了对象的创建，使得要更换对象时，不需要做大的改动就可实现，降低了客户端与产品对象的耦合。
+
+## 总结
+
+工厂方法模式是简单工厂模式的进一步抽象和推广。
+
+由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。
+
+在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。
+
+工厂方法模式的主要优点是增加新的产品类时无须修改现有系统，并封装了产品对象的创建细节，系统具有良好的灵活性和可扩展性；其缺点在于增加新产品的同时需要增加新的工厂，导致系统类的个数成对增加，在一定程度上增加了系统的复杂性。
+
+文中所有代码见[GitHub][6]
+
+## 参考资料
+
+[大话设计模式][7]
+
+[深入浅出设计模式][8]
+
+[工厂方法模式(Factory Method Pattern)][9]
+
+ [1]: http://www.hollischuang.com/archives/category/%E7%BB%BC%E5%90%88%E5%BA%94%E7%94%A8/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F
+ [2]: http://www.hollischuang.com/archives/1391
+ [3]: http://www.hollischuang.com/archives/220
+ [4]: http://www.hollischuang.com/wp-content/uploads/2016/04/QQ20160412-0.png
+ [5]: http://www.hollischuang.com/archives/220http://
+ [6]: https://github.com/hollischuang/DesignPattern
+ [7]: http://s.click.taobao.com/t?e=m=2&s=R5B/xd29JVMcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67jN2wQzI0ZBVHBMajAjK1gBpS4hLH/P02ckKYNRBWOBBey11vvWwHXSniyi5vWXIZkKWZZq7zWpCC8X3k5aQlui0qVGgqDL2o8YMXU3NNCg/&pvid=10_42.120.73.203_224_1460382841310
+ [8]: http://s.click.taobao.com/t?e=m%3D2%26s%3DObpq8Qxse2EcQipKwQzePOeEDrYVVa64K7Vc7tFgwiHjf2vlNIV67utJaEGcptl2kfkm8XrrgBtpS4hLH%2FP02ckKYNRBWOBBey11vvWwHXTpkOAWGyim%2Bw2PNKvM2u52N5aP5%2Bgx7zgh4LxdBQDQSXEqY%2Bakgpmw&pvid=10_121.0.29.199_322_1460465025379
+ [9]: http://design-patterns.readthedocs.org/zh_CN/latest/creational_patterns/factory_method.html#id11
\ No newline at end of file
diff --git a/docs/advance/design-patterns/iterator-pattern.md b/docs/advance/design-patterns/iterator-pattern.md
new file mode 100644
index 00000000..d2f1a904
--- /dev/null
+++ b/docs/advance/design-patterns/iterator-pattern.md
@@ -0,0 +1,168 @@
+
+## 概念
+
+一提到迭代器模式很多人可能感觉很陌生，但是实际上，迭代器模式是所有设计模式中最简单也是最常用的设计模式，正是因为他太常用了，所以很多人忽略了他的存在。
+
+> 迭代器模式提供一种方法访问一个容器中各个元素，而又不需要暴露该对象的内部细节。
+
+那么，这里提到的容器是什么呢？其实就是可以包含一组对象的数据结构，如Java中的`Collection`和`Set`。
+
+## 用途
+
+从迭代器模式的概念中我们也看的出来，迭代器模式的重要用途就是帮助我们遍历容器。拿List来举例。如果我们想要遍历他的话，通常有以下几种方式：
+
+ for (int i = 0; i < list.size(); i++) {
+ System.out.print(list.get(i) + ",");
+ }
+
+ Iterator iterator = list.iterator();
+ while (iterator.hasNext()) {
+ System.out.print(iterator.next() + ",");
+ }
+
+ for (Integer i : list) {
+ System.out.print(i + ",");
+ }
+
+
+其实，第二种和[第三种][2]都是基于迭代器模式实现的。本文重点是介绍迭代器模式，那么先暂不介绍Java中内置的迭代器，我们尝试自己实现一下迭代器模式，这样更有助于我们彻底理解迭代器模式。
+
+## 实现方式
+
+迭代器模式包含如下角色：
+
+> Iterator 抽象迭代器
+>
+> ConcreteIterator 具体迭代器
+>
+> Aggregate 抽象容器
+>
+> Concrete Aggregate 具体容器
+
+[
][3]
+
+这里我们举一个菜单的例子，我们有一个菜单，我们想要展示出菜单中所有菜品的名字和报价信息等。
+
+先定义抽象迭代器：
+
+ public interface Iterator
][4]
+
+### 饿汉式
+
+下面是一个简单的单例的实现：
+
+ //code 1
+ public class Singleton {
+ //在类内部实例化一个实例
+ private static Singleton instance = new Singleton();
+ //私有的构造函数,外部无法访问
+ private Singleton() {
+ }
+ //对外提供获取实例的静态方法
+ public static Singleton getInstance() {
+ return instance;
+ }
+ }
+
+
+使用以下代码测试：
+
+ //code2
+ public class SingletonClient {
+
+ public static void main(String[] args) {
+ SimpleSingleton simpleSingleton1 = SimpleSingleton.getInstance();
+ SimpleSingleton simpleSingleton2 = SimpleSingleton.getInstance();
+ System.out.println(simpleSingleton1==simpleSingleton2);
+ }
+ }
+
+
+输出结果：
+
+ true
+
+
+code 1就是一个简单的单例的实现，这种实现方式我们称之为饿汉式。所谓饿汉。这是个比较形象的比喻。对于一个饿汉来说，他希望他想要用到这个实例的时候就能够立即拿到，而不需要任何等待时间。所以，通过`static`的静态初始化方式，在该类第一次被加载的时候，就有一个`SimpleSingleton`的实例被创建出来了。这样就保证在第一次想要使用该对象时，他已经被初始化好了。
+
+同时，由于该实例在类被加载的时候就创建出来了，所以也避免了线程安全问题。（原因见：[在深度分析Java的ClassLoader机制（源码级别）][5]、[Java类的加载、链接和初始化][6]）
+
+还有一种饿汉模式的变种：
+
+ //code 3
+ public class Singleton2 {
+ //在类内部定义
+ private static Singleton2 instance;
+ static {
+ //实例化该实例
+ instance = new Singleton2();
+ }
+ //私有的构造函数,外部无法访问
+ private Singleton2() {
+ }
+ //对外提供获取实例的静态方法
+ public static Singleton2 getInstance() {
+ return instance;
+ }
+ }
+
+
+code 3和code 1其实是一样的，都是在类被加载的时候实例化一个对象。
+
+**饿汉式单例，在类被加载的时候对象就会实例化。这也许会造成不必要的消耗，因为有可能这个实例根本就不会被用到。而且，如果这个类被多次加载的话也会造成多次实例化。其实解决这个问题的方式有很多，下面提供两种解决方式，第一种是使用静态内部类的形式。第二种是使用懒汉式。**
+
+### 静态内部类式
+
+先来看通过静态内部类的方式解决上面的问题：
+
+ //code 4
+ public class StaticInnerClassSingleton {
+ //在静态内部类中初始化实例对象
+ private static class SingletonHolder {
+ private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
+ }
+ //私有的构造方法
+ private StaticInnerClassSingleton() {
+ }
+ //对外提供获取实例的静态方法
+ public static final StaticInnerClassSingleton getInstance() {
+ return SingletonHolder.INSTANCE;
+ }
+ }
+
+
+这种方式同样利用了classloder的机制来保证初始化`instance`时只有一个线程，它跟饿汉式不同的是（很细微的差别）：饿汉式是只要`Singleton`类被装载了，那么`instance`就会被实例化（没有达到lazy loading效果），而这种方式是`Singleton`类被装载了，`instance`不一定被初始化。因为`SingletonHolder`类没有被主动使用，只有显示通过调用`getInstance`方法时，才会显示装载`SingletonHolder`类，从而实例化`instance`。想象一下，如果实例化`instance`很消耗资源，我想让他延迟加载，另外一方面，我不希望在`Singleton`类加载时就实例化，因为我不能确保`Singleton`类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化`instance`显然是不合适的。这个时候，这种方式相比饿汉式更加合理。
+
+### 懒汉式
+
+下面看另外一种在该对象真正被使用的时候才会实例化的单例模式——懒汉模式。
+
+ //code 5
+ public class Singleton {
+ //定义实例
+ private static Singleton instance;
+ //私有构造方法
+ private Singleton(){}
+ //对外提供获取实例的静态方法
+ public static Singleton getInstance() {
+ //在对象被使用的时候才实例化
+ if (instance == null) {
+ instance = new Singleton();
+ }
+ return instance;
+ }
+ }
+
+
+上面这种单例叫做懒汉式单例。懒汉，就是不会提前把实例创建出来，将类对自己的实例化延迟到第一次被引用的时候。`getInstance`方法的作用是希望该对象在第一次被使用的时候被`new`出来。
+
+有没有发现，其实code 5这种懒汉式单例其实还存在一个问题，那就是线程安全问题。在多线程情况下，有可能两个线程同时进入`if`语句中，这样，在两个线程都从if中退出的时候就创建了两个不一样的对象。（这里就不详细讲解了，不理解的请恶补多线程知识）。
+
+### 线程安全的懒汉式
+
+针对线程不安全的懒汉式的单例，其实解决方式很简单，就是给创建对象的步骤加锁：
+
+ //code 6
+ public class SynchronizedSingleton {
+ //定义实例
+ private static SynchronizedSingleton instance;
+ //私有构造方法
+ private SynchronizedSingleton(){}
+ //对外提供获取实例的静态方法,对该方法加锁
+ public static synchronized SynchronizedSingleton getInstance() {
+ //在对象被使用的时候才实例化
+ if (instance == null) {
+ instance = new SynchronizedSingleton();
+ }
+ return instance;
+ }
+ }
+
+
+这种写法能够在多线程中很好的工作，而且看起来它也具备很好的延迟加载，但是，遗憾的是，他效率很低，因为99%情况下不需要同步。（因为上面的`synchronized`的加锁范围是整个方法，该方法的所有操作都是同步进行的，但是对于非第一次创建对象的情况，也就是没有进入`if`语句中的情况，根本不需要同步操作，可以直接返回`instance`。）
+
+### 双重校验锁
+
+针对上面code 6存在的问题，相信对并发编程了解的同学都知道如何解决。其实上面的代码存在的问题主要是锁的范围太大了。只要缩小锁的范围就可以了。那么如何缩小锁的范围呢？相比于同步方法，同步代码块的加锁范围更小。code 6可以改造成：
+
+ //code 7
+ public class Singleton {
+
+ private static Singleton singleton;
+
+ private Singleton() {
+ }
+
+ public static Singleton getSingleton() {
+ if (singleton == null) {
+ synchronized (Singleton.class) {
+ if (singleton == null) {
+ singleton = new Singleton();
+ }
+ }
+ }
+ return singleton;
+ }
+ }
+
+
+code 7是对于code 6的一种改进写法，通过使用同步代码块的方式减小了锁的范围。这样可以大大提高效率。（对于已经存在`singleton`的情况，无须同步，直接return）。
+
+但是，事情这的有这么容易吗？上面的代码看上去好像是没有任何问题。实现了惰性初始化，解决了同步问题，还减小了锁的范围，提高了效率。但是，该代码还存在隐患。隐患的原因主要和[Java内存模型（JMM][7]）有关。考虑下面的事件序列：
+
+> 线程A发现变量没有被初始化, 然后它获取锁并开始变量的初始化。
+>
+> 由于某些编程语言的语义，编译器生成的代码允许在线程A执行完变量的初始化之前，更新变量并将其指向部分初始化的对象。
+>
+> 线程B发现共享变量已经被初始化，并返回变量。由于线程B确信变量已被初始化，它没有获取锁。如果在A完成初始化之前共享变量对B可见（这是由于A没有完成初始化或者因为一些初始化的值还没有穿过B使用的内存(缓存一致性)），程序很可能会崩溃。
+
+（上面的例子不太能理解的同学，请恶补JAVA内存模型相关知识）
+
+在[J2SE 1.4][8]或更早的版本中使用双重检查锁有潜在的危险，有时会正常工作（区分正确实现和有小问题的实现是很困难的。取决于编译器，线程的调度和其他并发系统活动，不正确的实现双重检查锁导致的异常结果可能会间歇性出现。重现异常是十分困难的。） 在[J2SE 5.0][8]中，这一问题被修正了。[volatile][9]关键字保证多个线程可以正确处理单件实例
+
+所以，针对code 7 ，可以有code 8 和code 9两种替代方案：
+
+使用`volatile`
+
+ //code 8
+ public class VolatileSingleton {
+ private static volatile VolatileSingleton singleton;
+
+ private VolatileSingleton() {
+ }
+
+ public static VolatileSingleton getSingleton() {
+ if (singleton == null) {
+ synchronized (VolatileSingleton.class) {
+ if (singleton == null) {
+ singleton = new VolatileSingleton();
+ }
+ }
+ }
+ return singleton;
+ }
+ }
+
+
+**上面这种双重校验锁的方式用的比较广泛，他解决了前面提到的所有问题。**但是，即使是这种看上去完美无缺的方式也可能存在问题，那就是遇到序列化的时候。详细内容后文介绍。
+
+使用`final`
+
+ //code 9
+ class FinalWrapper
][3] 我们希望用户在付款的时候，只要刷一下书的条形码，会员再刷一下他的会员卡，收银台的工组人员就能直接知道应该向顾客收取多少钱。
+
+在不使用模式的情况下，我们可以在结算的方法中使用`if/else`语句来区别出不同的会员来计算价格。
+
+但是，如果我们有一天想要把初级会员的折扣改成9.8折怎么办？有一天我要推出超级会员怎么办？有一天我要针对中级会员可打折的书的数量做限制怎么办？
+
+使用`if\else`设计出来的系统，所有的算法都写在了一起，只要有改动我就要修改整个类。我们都知道，只要是修改代码就有可能引入问题。为了避免这个问题，我们可以使用策略模式。。。
+
+> 对于收银台系统，计算应收款的时候，一个客户只可能是初级、中级、高级会员中的一种。不同的会员使用不同的算法来计算价格。收银台系统其实不关心具体的会员类型和折扣之间的关系。也不希望会员和折扣之间的任何改动会影响到收银台系统。
+
+在介绍策略模式的具体实现方式之前，再来巩固一下几个面向对象设计原则：`封装变化`、`多用组合，少用继承`、`针对接口编程，不针对实现编程`。想一想如何运用到策略模式中，并且有什么好处。
+
+## 实现方式
+
+策略模式包含如下角色：
+
+> Context: 环境类
+>
+> Strategy: 抽象策略类
+>
+> ConcreteStrategy: 具体策略类
+
+[
][4]
+
+我们运用策略模式来实现一下书店的收银台系统。我们可以把会员抽象成一个策略类，不同的会员类型是具体的策略类。不同策略类里面实现了计算价格这一算法。然后通过组合的方式把会员集成到收银台中。
+
+先定义一个接口，这个接口就是抽象策略类，该接口定义了计算价格方法，具体实现方式由具体的策略类来定义。
+
+ /**
+ * Created by hollis on 16/9/19. 会员接口
+ */
+ public interface Member {
+
+ /**
+ * 计算应付价格
+ * @param bookPrice 书籍原价(针对金额,建议使用BigDecimal,double会损失精度)
+ * @return 应付金额
+ */
+ public double calPrice(double bookPrice);
+ }
+
+
+针对不同的会员，定义三种具体的策略类，每个类中都分别实现计算价格方法。
+
+ /**
+ * Created by hollis on 16/9/19. 初级会员
+ */
+ public class PrimaryMember implements Member {
+
+ @Override
+ public double calPrice(double bookPrice) {
+ System.out.println("对于初级会员的没有折扣");
+ return bookPrice;
+ }
+ }
+
+
+ /**
+ * Created by hollis on 16/9/19. 中级会员,买书打九折
+ */
+ public class IntermediateMember implements Member {
+
+ @Override
+ public double calPrice(double bookPrice) {
+ System.out.println("对于中级会员的折扣为10%");
+ return bookPrice * 0.9;
+ }
+ }
+
+
+ /**
+ * Created by hollis on 16/9/19. 高级会员,买书打八折
+ */
+ public class AdvancedMember implements Member {
+
+ @Override
+ public double calPrice(double bookPrice) {
+ System.out.println("对于高级会员的折扣为20%");
+ return bookPrice * 0.8;
+ }
+ }
+
+
+上面几个类的定义体现了`封装变化`的设计原则，不同会员的具体折扣方式改变不会影响到其他的会员。
+
+定义好了抽象策略类和具体策略类之后，我们再来定义环境类，所谓环境类，就是集成算法的类。这个例子中就是收银台系统。采用组合的方式把会员集成进来。
+
+ /**
+ * Created by hollis on 16/9/19. 书籍价格类
+ */
+ public class Cashier {
+
+ /**
+ * 会员,策略对象
+ */
+ private Member member;
+
+ public Cashier(Member member){
+ this.member = member;
+ }
+
+ /**
+ * 计算应付价格
+ * @param booksPrice
+ * @return
+ */
+ public double quote(double booksPrice) {
+ return this.member.calPrice(booksPrice);
+ }
+ }
+
+
+这个Cashier类就是一个环境类，该类的定义体现了`多用组合，少用继承`、`针对接口编程，不针对实现编程`两个设计原则。由于这里采用了组合+接口的方式，后面我们在推出超级会员的时候无须修改Cashier类。只要再定义一个`SuperMember implements Member` 就可以了。
+
+下面定义一个客户端来测试一下：
+
+ /**
+ * Created by hollis on 16/9/19.
+ */
+ public class BookStore {
+
+ public static void main(String[] args) {
+
+ //选择并创建需要使用的策略对象
+ Member strategy = new AdvancedMember();
+ //创建环境
+ Cashier cashier = new Cashier(strategy);
+ //计算价格
+ double quote = cashier.quote(300);
+ System.out.println("高级会员图书的最终价格为：" + quote);
+
+ strategy = new IntermediateMember();
+ cashier = new Cashier(strategy);
+ quote = cashier.quote(300);
+ System.out.println("中级会员图书的最终价格为：" + quote);
+ }
+ }
+
+ //对于高级会员的折扣为20%
+ //高级会员图书的最终价格为：240.0
+ //对于中级会员的折扣为10%
+ //中级会员图书的最终价格为：270.0
+
+
+从上面的示例可以看出，策略模式仅仅封装算法，提供新的算法插入到已有系统中，策略模式并不决定在何时使用何种算法。在什么情况下使用什么算法是由客户端决定的。
+
+* 策略模式的重心
+
+ * 策略模式的重心不是如何实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活，具有更好的维护性和扩展性。
+
+* 算法的平等性
+
+ * 策略模式一个很大的特点就是各个策略算法的平等性。对于一系列具体的策略算法，大家的地位是完全一样的，正因为这个平等性，才能实现算法之间可以相互替换。所有的策略算法在实现上也是相互独立的，相互之间是没有依赖的。
+
+ * 所以可以这样描述这一系列策略算法：策略算法是相同行为的不同实现。
+
+* 运行时策略的唯一性
+
+ * 运行期间，策略模式在每一个时刻只能使用一个具体的策略实现对象，虽然可以动态地在不同的策略实现中切换，但是同时只能使用一个。
+
+* 公有的行为
+
+ * 经常见到的是，所有的具体策略类都有一些公有的行为。这时候，就应当把这些公有的行为放到共同的抽象策略角色Strategy类里面。当然这时候抽象策略角色必须要用Java抽象类实现，而不能使用接口。（[《JAVA与模式》之策略模式][5]）
+
+## 策略模式的优缺点
+
+### 优点
+
+* 策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
+* 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类里面，从而避免代码重复。
+* 使用策略模式可以避免使用多重条件(if-else)语句。多重条件语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重条件语句里面，比使用继承的办法还要原始和落后。
+
+### 缺点
+
+* 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。
+* 由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观。可以通过使用享元模式在一定程度上减少对象的数量。
+
+文中所有代码见[GitHub][6]
+
+## 参考资料
+
+[《JAVA与模式》之策略模式][5]
+
+ [1]: http://www.hollischuang.com/archives/category/%E7%BB%BC%E5%90%88%E5%BA%94%E7%94%A8/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F
+ [2]: http://s.click.taobao.com/DxA2xSx
+ [3]: http://www.hollischuang.com/wp-content/uploads/2016/09/bookstore.jpg
+ [4]: http://www.hollischuang.com/wp-content/uploads/2016/09/Strategy.jpg
+ [5]: http://www.cnblogs.com/java-my-life/archive/2012/05/10/2491891.html
+ [6]: https://github.com/hollischuang/DesignPattern
\ No newline at end of file
diff --git a/docs/basement/_sidebar.md b/docs/basement/_sidebar.md
deleted file mode 100644
index 130f63c4..00000000
--- a/docs/basement/_sidebar.md
+++ /dev/null
@@ -1,147 +0,0 @@
-* JVM
-
- * JVM内存结构
-
- * 运行时数据区
-
- * 运行时数据区哪些是线程独享
-
- * 堆和栈区别
-
- * 方法区在不同版本JDK中的位置
-
- * 堆外内存
-
- * TLAB
-
- * [Java中的对象一定在堆上分配吗？](/basement/jvm/stack-alloc.md)
-
- * 垃圾回收
-
- * GC算法：标记清除、引用计数、复制、标记压缩、分代回收、增量式回收
-
- * GC参数
-
- * 对象存活的判定
-
- * 垃圾收集器（CMS、G1、ZGC、Epsilon）
-
- * JVM参数及调优
-
- * -Xmx
-
- * -Xmn
-
- * -Xms
-
- * -Xss
-
- * -XX:SurvivorRatio
-
- * -XX:PermSize
-
- * -XX:MaxPermSize
-
- * -XX:MaxTenuringThreshold
-
- * Java对象模型
-
- * oop-klass
-
- * 对象头
-
- * HotSpot
-
- * 即时编译器
-
- * 编译优化
-
- * Java内存模型
-
- * 计算机内存模型
-
- * 缓存一致性
-
- * MESI协议
-
- * 可见性
-
- * 原子性
-
- * 顺序性
-
- * happens-before
-
- * as-if-serial
-
- * 内存屏障
-
- * synchronized
-
- * volatile
-
- * final
-
- * 锁
-
-* 虚拟机性能监控与故障处理工具
-
- * jps
-
- * jstack
-
- * jmap
-
- * jstat
-
- * jconsole
-
- * jinfo
-
- * jhat
-
- * javap
-
- * btrace
-
- * TProfiler
-
- * jlink
-
- * Arthas
-
-* 类加载机制
-
- * classLoader
-
- * 类加载过程是线程安全的吗？
-
- * 类加载过程
-
- * 双亲委派（破坏双亲委派）
-
- * 模块化（jboss modules、osgi、jigsaw）
-
-* 打包工具
-
- * jar
-
- * jlink
-
- * jpackage
-
-* 编译与反编译
-
- * 什么是编译
-
- * 什么是反编译
-
- * 编译工具：javac
-
- * 反编译工具：javap 、jad 、CRF
-
-* JIT
-
- * JIT优化（逃逸分析、栈上分配、标量替换、锁优化）
-
-
\ No newline at end of file
diff --git a/docs/basement/jvm/_sidebar.md b/docs/basement/jvm/_sidebar.md
deleted file mode 100644
index af88b7a3..00000000
--- a/docs/basement/jvm/_sidebar.md
+++ /dev/null
@@ -1,85 +0,0 @@
-* JVM
-
- * JVM内存结构
-
- * 运行时数据区
-
- * 运行时数据区哪些是线程独享
-
- * 堆和栈区别
-
- * 方法区在不同版本JDK中的位置
-
- * 堆外内存
-
- * TLAB
-
- * [Java中的对象一定在堆上分配吗？](/basement/jvm/stack-alloc.md)
-
- * 垃圾回收
-
- * GC算法：标记清除、引用计数、复制、标记压缩、分代回收、增量式回收
-
- * GC参数
-
- * 对象存活的判定
-
- * 垃圾收集器（CMS、G1、ZGC、Epsilon）
-
- * JVM参数及调优
-
- * -Xmx
-
- * -Xmn
-
- * -Xms
-
- * -Xss
-
- * -XX:SurvivorRatio
-
- * -XX:PermSize
-
- * -XX:MaxPermSize
-
- * -XX:MaxTenuringThreshold
-
- * Java对象模型
-
- * oop-klass
-
- * 对象头
-
- * HotSpot
-
- * 即时编译器
-
- * 编译优化
-
- * Java内存模型
-
- * 计算机内存模型
-
- * 缓存一致性
-
- * MESI协议
-
- * 可见性
-
- * 原子性
-
- * 顺序性
-
- * happens-before
-
- * as-if-serial
-
- * 内存屏障
-
- * synchronized
-
- * volatile
-
- * final
-
- * 锁
\ No newline at end of file
diff --git a/docs/basement/jvm/break-parants-delegate.md b/docs/basement/jvm/break-parants-delegate.md
new file mode 100644
index 00000000..4a31d080
--- /dev/null
+++ b/docs/basement/jvm/break-parants-delegate.md
@@ -0,0 +1,3 @@
+知道了双亲委派模型的实现，那么想要破坏双亲委派机制就很简单了。
+
+因为他的双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。
\ No newline at end of file
diff --git a/docs/basement/jvm/define-class-loader.md b/docs/basement/jvm/define-class-loader.md
new file mode 100644
index 00000000..d0133017
--- /dev/null
+++ b/docs/basement/jvm/define-class-loader.md
@@ -0,0 +1,29 @@
+ClassLoader中和类加载有关的方法有很多，前面提到了loadClass，除此之外，还有findClass和defineClass等，那么这几个方法有什么区别呢？
+
+* loadClass()
+ * 就是主要进行类加载的方法，默认的双亲委派机制就实现在这个方法中。
+* findClass()
+ * 根据名称或位置加载.class字节码
+* definclass()
+ * 把字节码转化为Class
+
+这里面需要展开讲一下loadClass和findClass，我们前面说过，当我们想要自定义一个类加载器的时候，并且像破坏双亲委派原则时，我们会重写loadClass方法。
+
+那么，如果我们想定义一个类加载器，但是不想破坏双亲委派模型的时候呢？
+
+这时候，就可以继承ClassLoader，并且重写findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一个方法。
+
+ /**
+ * @since 1.2
+ */
+ protected Class findClass(String name) throws ClassNotFoundException {
+ throw new ClassNotFoundException(name);
+ }
+
+这个方法只抛出了一个异常，没有默认实现。
+
+JDK1.2之后已不再提倡用户直接覆盖loadClass()方法，而是建议把自己的类加载逻辑实现到findClass()方法中。
+
+因为在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载。
+
+所以，如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass中实现你自己的加载逻辑即可。
\ No newline at end of file
diff --git a/docs/basement/jvm/exclusive-in-runtime-area.md b/docs/basement/jvm/exclusive-in-runtime-area.md
new file mode 100644
index 00000000..b0332c5e
--- /dev/null
+++ b/docs/basement/jvm/exclusive-in-runtime-area.md
@@ -0,0 +1,3 @@
+在JVM运行时内存区域中，PC寄存器、虚拟机栈和本地方法栈是线程独享的。
+
+而Java堆、方法区是线程共享的。但是值得注意的是，Java堆其实还未每一个线程单独分配了一块TLAB空间，这部分空间在分配时是线程独享的，在使用时是线程共享的。
\ No newline at end of file
diff --git a/docs/basement/jvm/implements-of-parents-delegate.md b/docs/basement/jvm/implements-of-parents-delegate.md
new file mode 100644
index 00000000..d46750e6
--- /dev/null
+++ b/docs/basement/jvm/implements-of-parents-delegate.md
@@ -0,0 +1,51 @@
+双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现并不复杂。
+
+实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中：
+
+ protected Class loadClass(String name, boolean resolve)
+ throws ClassNotFoundException
+ {
+ synchronized (getClassLoadingLock(name)) {
+ // First, check if the class has already been loaded
+ Class c = findLoadedClass(name);
+ if (c == null) {
+ long t0 = System.nanoTime();
+ try {
+ if (parent != null) {
+ c = parent.loadClass(name, false);
+ } else {
+ c = findBootstrapClassOrNull(name);
+ }
+ } catch (ClassNotFoundException e) {
+ // ClassNotFoundException thrown if class not found
+ // from the non-null parent class loader
+ }
+
+ if (c == null) {
+ // If still not found, then invoke findClass in order
+ // to find the class.
+ long t1 = System.nanoTime();
+ c = findClass(name);
+
+ // this is the defining class loader; record the stats
+ sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
+ sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
+ sun.misc.PerfCounter.getFindClasses().increment();
+ }
+ }
+ if (resolve) {
+ resolveClass(c);
+ }
+ return c;
+ }
+ }
+
+代码不难理解，主要就是以下几个步骤：
+
+1、先检查类是否已经被加载过
+
+2、若没有加载则调用父加载器的loadClass()方法进行加载
+
+3、若父加载器为空则默认使用启动类加载器作为父加载器。
+
+4、如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
\ No newline at end of file
diff --git a/docs/basement/jvm/moduler.md b/docs/basement/jvm/moduler.md
new file mode 100644
index 00000000..11eea7b7
--- /dev/null
+++ b/docs/basement/jvm/moduler.md
@@ -0,0 +1,39 @@
+近几年模块化技术已经很成熟了，在JDK 9中已经应用了模块化的技术。
+
+其实早在JDK 9之前，OSGI这种框架已经是模块化的了，**而OSGI之所以能够实现模块热插拔和模块内部可见性的精准控制都归结于其特殊的类加载机制，加载器之间的关系不再是双亲委派模型的树状结构，而是发展成复杂的网状结构。**
+
+
+
+**在JDK中，双亲委派也不是绝对的了。**
+
+在JDK9之前，JVM的基础类以前都是在rt.jar这个包里，这个包也是JRE运行的基石。
+
+这不仅是违反了单一职责原则，同样程序在编译的时候会将很多无用的类也一并打包，造成臃肿。
+
+**在JDK9中，整个JDK都基于模块化进行构建，以前的rt.jar, tool.jar被拆分成数十个模块，编译的时候只编译实际用到的模块，同时各个类加载器各司其职，只加载自己负责的模块。**
+
+ Class c = findLoadedClass(cn);
+ if (c == null) {
+ // 找到当前类属于哪个模块
+ LoadedModule loadedModule = findLoadedModule(cn);
+ if (loadedModule != null) {
+ //获取当前模块的类加载器
+ BuiltinClassLoader loader = loadedModule.loader();
+ //进行类加载
+ c = findClassInModuleOrNull(loadedModule, cn);
+ } else {
+ // 找不到模块信息才会进行双亲委派
+ if (parent != null) {
+ c = parent.loadClassOrNull(cn);
+ }
+ }
+ }
+
+
+### 总结
+
+以上，从什么是双亲委派，到如何实现与破坏双亲委派，又从破坏双亲委派的示例等多个方面全面介绍了关于双亲委派的知识。
+
+相信通过学习本文，你一定对双亲委派机制有了更加深刻的了解。
+
+阅读过本文之后，反手在简历上写下：熟悉Java的类加载机制，不服来问！
\ No newline at end of file
diff --git a/docs/basement/jvm/parents-delegate.md b/docs/basement/jvm/parents-delegate.md
new file mode 100644
index 00000000..876a66e2
--- /dev/null
+++ b/docs/basement/jvm/parents-delegate.md
@@ -0,0 +1,30 @@
+虚拟机在加载类的过程中需要使用类加载器进行加载，而在Java中，类加载器有很多，那么当JVM想要加载一个.class文件的时候，到底应该由哪个类加载器加载呢？
+
+这就不得不提到”双亲委派机制”。
+
+首先，我们需要知道的是，Java语言系统中支持以下4种类加载器：
+
+
+* Bootstrap ClassLoader 启动类加载器
+* Extention ClassLoader 标准扩展类加载器
+* Application ClassLoader 应用类加载器
+* User ClassLoader 用户自定义类加载器
+
+这四种类加载器之间，是存在着一种层次关系的，如下图
+
+
+
+一般认为上一层加载器是下一层加载器的父加载器，那么，除了BootstrapClassLoader之外，所有的加载器都是有父加载器的。
+
+那么，所谓的双亲委派机制，指的就是：当一个类加载器收到了类加载的请求的时候，他不会直接去加载指定的类，而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候，才会由当前这个加载器来负责类的加载。
+
+那么，什么情况下父加载器会无法加载某一个类呢？
+
+其实，Java中提供的这四种类型的加载器，是有各自的职责的：
+
+* Bootstrap ClassLoader ，主要负责加载Java核心类库，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。
+* Extention ClassLoader，主要负责加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。
+* Application ClassLoader ，主要负责加载当前应用的classpath下的所有类
+* User ClassLoader ， 用户自定义的类加载器,可加载指定路径的class文件
+
+那么也就是说，一个用户自定义的类，如com.hollis.ClassHollis 是无论如何也不会被Bootstrap和Extention加载器加载的。
\ No newline at end of file
diff --git a/docs/basement/jvm/relation-with-parents-delegate.md b/docs/basement/jvm/relation-with-parents-delegate.md
new file mode 100644
index 00000000..dd71242e
--- /dev/null
+++ b/docs/basement/jvm/relation-with-parents-delegate.md
@@ -0,0 +1,12 @@
+很多人看到父加载器、子加载器这样的名字，就会认为Java中的类加载器之间存在着继承关系。
+
+甚至网上很多文章也会有类似的错误观点。
+
+这里需要明确一下，双亲委派模型中，类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码的。
+
+如下为ClassLoader中父加载器的定义：
+
+ public abstract class ClassLoader {
+ // The parent class loader for delegation
+ private final ClassLoader parent;
+ }
\ No newline at end of file
diff --git a/docs/basement/jvm/runtime-area.md b/docs/basement/jvm/runtime-area.md
new file mode 100644
index 00000000..69a2115a
--- /dev/null
+++ b/docs/basement/jvm/runtime-area.md
@@ -0,0 +1,25 @@
+Java虚拟机在执行Java程序的过程中会把他所管理的内存划分为若干个不同的数据区域。《Java虚拟机规范》中规定了JVM所管理的内存需要包括一下几个运行时区域：
+
+
+
+主要包含了PC寄存器（程序计数器）、Java虚拟机栈、本地方法栈、Java堆、方法区以及运行时常量池。
+
+
+
+1、以上是Java虚拟机规范，不同的虚拟机实现会各有不同，但是一般会遵守规范。
+
+2、规范中定义的方法区，只是一种概念上的区域，并说明了其应该具有什么功能。但是并没有规定这个区域到底应该处于何处。所以，对于不同的虚拟机实现来说，是由一定的自由度的。
+
+3、不同版本的方法区所处位置不同，上图中划分的是逻辑区域，并不是绝对意义上的物理区域。因为某些版本的JDK中方法区其实是在堆中实现的。
+
+4、运行时常量池用于存放编译期生成的各种字面量和符号应用。但是，Java语言并不要求常量只有在编译期才能产生。比如在运行期，String.intern也会把新的常量放入池中。
+
+5、除了以上介绍的JVM运行时内存外，还有一块内存区域可供使用，那就是直接内存。Java虚拟机规范并没有定义这块内存区域，所以他并不由JVM管理，是利用本地方法库直接在堆外申请的内存区域。
+
+6、堆和栈的数据划分也不是绝对的，如HotSpot的JIT会针对对象分配做相应的优化。
+
+如上，做个总结，JVM内存结构，由Java虚拟机规范定义。描述的是Java程序执行过程中，由JVM管理的不同数据区域。各个区域有其特定的功能。
+
+
+但是，需要注意的是，上面的区域划分只是逻辑区域，对于有些区域的限制是比较松的，所以不同的虚拟机厂商在实现上，甚至是同一款虚拟机的不同版本也是不尽相同的。
+
diff --git a/docs/basement/jvm/sample-of-break-parents-delegate.md b/docs/basement/jvm/sample-of-break-parents-delegate.md
new file mode 100644
index 00000000..ab9f627d
--- /dev/null
+++ b/docs/basement/jvm/sample-of-break-parents-delegate.md
@@ -0,0 +1,14 @@
+双亲委派机制的破坏不是什么稀奇的事情，很多框架、容器等都会破坏这种机制来实现某些功能。
+
+*第一种被破坏的情况是在双亲委派出现之前。*
+
+由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。
+
+*第二种，是JNDI、JDBC等需要加载SPI接口实现类的情况。*
+
+*第三种是为了实现热插拔热部署工具。*为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。
+
+*第四种时tomcat等web容器的出现。*
+
+*第五种时OSGI、Jigsaw等模块化技术的应用。*
+
diff --git a/docs/basement/jvm/spi-parents-delegate.md b/docs/basement/jvm/spi-parents-delegate.md
new file mode 100644
index 00000000..b620a1f0
--- /dev/null
+++ b/docs/basement/jvm/spi-parents-delegate.md
@@ -0,0 +1,35 @@
+我们日常开发中，大多数时候会通过API的方式调用Java提供的那些基础类，这些基础类时被Bootstrap加载的。
+
+但是，调用方式除了API之外，还有一种SPI的方式。
+
+如典型的JDBC服务，我们通常通过以下方式创建数据库连接：
+
+ Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234");
+
+
+在以上代码执行之前，DriverManager会先被类加载器加载，因为java.sql.DriverManager类是位于rt.jar下面的 ，所以他会被根加载器加载。
+
+类加载时，会执行该类的静态方法。其中有一段关键的代码是：
+
+ ServiceLoader