图片在Typora里面无法查看，修改图片的相对路径

Author: zhujinming

docs/Dubbo/SPI/Dubbo与Java的SPI机制.md

@@ -11,7 +11,7 @@ dubbo自己实现了一套SPI机制，并对 JDK的SPI进行了改进。
 
 下面我们看一下Dubbo 的 SPI扩展机制实现的结构目录。
 
-![avatar](/images/Dubbo/SPI组件目录结构.png)
+![avatar](../../../images/Dubbo/SPI组件目录结构.png)
 
 ### SPI 注解
 首先看一下 SPI注解。在某个接口上加上 @SPI 注解后，表明该接口为可扩展接口。比如，协议扩展接口Protocol，如果使用者在 <dubbo:protocol />、<dubbo:service />、<dubbo:reference /> 都没有指定 protocol属性 的话，那么就默认使用 DubboProtocol 作为接口Protocol的实现，因为在 Protocol 上有 @SPI("dubbo")注解。而这个 protocol属性值 或者默认值会被当作该接口的实现类中的一个key，dubbo 会去 META-INF.dubbo.internal下的com.alibaba.dubbo.rpc.Protocol文件中找该key对应的value，源码如下。

docs/Dubbo/architectureDesign/Dubbo整体架构.md

@@ -1,7 +1,7 @@
 ## 项目结构
 首先从GitHub 上 down下来Dubbo项目，我们根据里面的目录名 也能大概猜出来各个模块的作用。
 
-![avatar](/images/Dubbo/dubbo项目结构.png)
+![avatar](../../../images/Dubbo/dubbo项目结构.png)
 
 ### dubbo-­common
 公共逻辑模块，定义了各模块中 通用的 组件 和 工具类，如：IO、日志、配置处理等。
@@ -34,7 +34,7 @@ dubbo配置模块，该模块通过 配置信息，将dubbo组件的各个模块
 
 其运行原理如下图所示。
 
-![avatar](/Dubbo工作原理图.png)
+![avatar](../../../images/Dubbo/Dubbo工作原理图.png)
 
 ### 工作原理
 最后总结下其工作原理。

docs/Dubbo/cluster/Dubbo集群模块简析.md

@@ -13,12 +13,12 @@
 
 下面我们来看一下 集群模块的项目结构图，结合上文的描述，可以对其有更加深刻的理解。
 
-![avatar](/images/Dubbo/dubbo-cluster模块工程结构.png)
+![avatar](../../../images/Dubbo/dubbo-cluster模块工程结构.png)
 
 ### 集群模块核心API 源码解析
 从上图应该也能看出其核心API在哪个包里。
 
-![avatar](/images/Dubbo/com.alibaba.dubbo.rpc.cluster包目录.png)
+![avatar](../../../images/Dubbo/com.alibaba.dubbo.rpc.cluster包目录.png)
 
 各核心接口的源码如下。
 ```java

docs/Dubbo/registry/Dubbo注册中心模块简析.md

@@ -1,21 +1,21 @@
 ## 注册中心在Dubbo中的作用
 服务治理框架可以大致分为 服务通信 和 服务管理 两部分，服务管理可以分为服务注册、服务订阅以及服务发现，服务提供者Provider 会往注册中心注册服务，而消费者Consumer 会从注册中心中订阅自己关注的服务，并在关注的服务发生变更时 得到注册中心的通知。Provider、Consumer以及Registry之间的依赖关系 如下图所示。
 
-![avatar](/images/Dubbo/Dubbo工作原理图.png)
+![avatar](../../../images/Dubbo/Dubbo工作原理图.png)
 
 ## dubbo-registry 模块 结构分析
 dubbo的注册中心有多种实现方案，如：zookeeper、redis、multicast等，本章先看一下 dubbo-registry 模块的核心部分 dubbo-registry-api，具体实现部分放到下章来讲。dubbo-registry模块 的结构如下图所示。
 
-![avatar](/images/Dubbo/dubbo-registry模块结构图.png)
+![avatar](../../../images/Dubbo/dubbo-registry模块结构图.png)
 
 ### Registry 核心组件类图
 典型的 接口 -> 抽象类 -> 实现类 的结构设计，如下图所示。
 
-![avatar](/images/Dubbo/Registry组件类图.png)
+![avatar](../../../images/Dubbo/Registry组件类图.png)
 
 既然有Registry组件，那么按照很多框架的套路，肯定也有一个用于获取 Registry实例的RegistryFactory，其中用到了工厂方法模式，不同的工厂类用于获取不同类型的实例。其类图结构如下。
 
-![avatar](/images/Dubbo/RegistryFactory组件类图.png)
+![avatar](../../../images/Dubbo/RegistryFactory组件类图.png)
 
 ## 源码详解
 根据上面的类图，我们开始从上往下 详解dubbo中对于注册中心的设计以及实现。

docs/Dubbo/registry/注册中心的Zookeeper实现.md

@@ -2,15 +2,15 @@ Dubbo的注册中心 虽然提供了多种实现，但生产上的事实标准
 
 由于 Dubbo 是一个分布式RPC开源框架，各服务之间单独部署，往往会出现资源之间数据不一致的问题，比如：某一个服务增加或减少了几台机器，某个服务提供者变更了服务地址，那么服务消费者是很难感知到这种变化的。而 Zookeeper 本身就有保证分布式数据一致性的特性。那么 Dubbo服务是如何被 Zookeeper的数据结构存储管理的呢，zookeeper采用的是树形结构来组织数据节点，它类似于一个标准的文件系统，如下图所示。
 
-![avatar](/images/Dubbo/dubbo注册中心在zookeeper中的结构.png)
+![avatar](../../../images/Dubbo/dubbo注册中心在zookeeper中的结构.png)
 
 该图展示了dubbo在zookeeper中存储的形式以及节点层级。dubbo的Root层是根目录，通过<dubbo:registry group="dubbo" />的“group”来设置zookeeper的根节点，缺省值是“dubbo”。Service层是服务接口的全名。Type层是分类，一共有四种分类，分别是providers 服务提供者列表、consumers 服务消费者列表、routes 路由规则列表、configurations 配置规则列表。URL层 根据不同的Type目录：可以有服务提供者 URL 、服务消费者 URL 、路由规则 URL 、配置规则 URL 。不同的Type关注的URL不同。
 
 zookeeper以斜杠来分割每一层的znode节点，比如第一层根节点dubbo就是“/dubbo”，而第二层的Service层就是/dubbo/com.foo.Barservice，zookeeper的每个节点通过路径来表示以及访问，例如服务提供者启动时，向/dubbo/com.foo.Barservice/providers目录下写入自己的URL地址。
 
 dubbo-registry-zookeeper 模块的工程结构如下图所示，里面就俩类，非常简单。
 
-![avatar](/images/Dubbo/dubbo-registry-zookeeper模块工程结构图.png)
+![avatar](../../../images/Dubbo/dubbo-registry-zookeeper模块工程结构图.png)
 
 ### ZookeeperRegistry
 该类继承了FailbackRegistry抽象类，针对注册中心核心的 服务注册、服务订阅、取消注册、取消订阅，查询注册列表进行展开，这里用到了 模板方法设计模式，FailbackRegistry中定义了register()、subscribe()等模板方法和 doRegister()、doSubscribe()抽象方法，ZookeeperRegistry基于zookeeper对这些抽象方法进行了实现。其实你会发现zookeeper虽然是最被推荐的，反而它的实现逻辑相对简单，因为调用了zookeeper服务组件，很多的逻辑不需要在dubbo中自己去实现。

docs/JDK/Executor线程池组件.md

@@ -1,7 +1,7 @@
 ## 线程池核心组件图解
 看源码之前，先了解一下该组件 最主要的几个 接口、抽象类和实现类的结构关系。
 
-![avatar](/images/JDK1.8/线程池组件类图.png)
+![avatar](../../images/JDK1.8/线程池组件类图.png)
 
 该组件中，Executor 和 ExecutorService接口 定义了线程池最核心的几个方法，提交任务submit
 ()、关闭线程池shutdown()。抽象类 AbstractExecutorService 主要对公共行为 submit()系列方法进行了实现，这些 submit()方法 的实现使用了 模板方法模式，其中调用的 execute()方法 是未实现的 来自 Executor接口 的方法。实现类 ThreadPoolExecutor 则对线程池进行了具体而复杂的实现。
@@ -211,7 +211,7 @@ public class ThreadPoolExecutor extends AbstractExecutorService {
 ```
 ThreadPoolExecutor 中的 execute()方法 执行 Runnable任务 的流程逻辑可以用下图表示。
 
-![avatar](/images/ConcurrentProgramming/线程池流程.png)
+![avatar](../../../images/ConcurrentProgramming/线程池流程.png)
 
 ### 工具类 Executors
 看类名也知道，它最主要的作用就是提供 static 的工具方法，为开发者提供各种封装好的 具有各自特性的线程池。

docs/JDK/Lock锁组件.md

@@ -1,11 +1,11 @@
 ## 类图结构
 J.U.C 的锁组件中 类相对较少，从JDK相应的包中也能看出来，下图标记了其中最主要的几个接口和类，也是本文要分析的重点。
 
-![avatar](/images/JDK1.8/JUC的locks包.png)
+![avatar](../../images/JDK1.8/JUC的locks包.png)
 
 下图 将这几个接口和类 以类图的方式展现出来，其中包含了它们所声明的主要方法。
 
-![avatar](/images/JDK1.8/JUC锁组件类图.png)
+![avatar](../../images/JDK1.8/JUC锁组件类图.png)
 
 ## Lock 组件
 Lock 组件的结构很简单，只有一个接口和一个实现类，源码如下。

docs/JDK/Thread.md

@@ -317,4 +317,4 @@ public class Thread implements Runnable {
 ```
 之前一直对线程状态 及 状态切换的概念模糊不清，现在通过源码中对线程状态的定义，我们可以画张图来重新回顾一下，以使我们对其有更加深刻的理解。
 
-![avatar](/images/JDK1.8/ThreadStatusChange.png)
+![avatar](../../images/JDK1.8/ThreadStatusChange.png)

docs/JDK/ThreadLocal.md

@@ -256,7 +256,7 @@ public class ThreadLocal<T> {
 ```
 简单画个图总结一下 ThreadLocal 的原理，如下。
 
-![avatar](/images/JDK1.8/ThreadLocal原理.png)
+![avatar](../../images/JDK1.8/ThreadLocal原理.png)
 
 最后强调一下 ThreadLocal的使用注意事项：
 

docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(创建型).md

@@ -28,6 +28,7 @@ public class Singleton3 {
      * 使用volatile修饰instance变量 可以 避免上述的指令重排
      * tips：不太理解的是 第一个线程在执行第2步之前就已经释放了锁吗？导致其它线程进入synchronized代码块
      *      执行 instance == null 的判断？
+     *  回答：第一个线程在执行第2步之前就已经释放了锁吗？（没有）。如果不使用volatile修饰instance变量，那么其他线程进来的时候，看到的instance就有可能不是null的，因为已经执行了第3步，那么此时这个线程（执行 return instance;）使用的instance是一个没有初始化的instance，就会有问题。
      */
     private volatile static Singleton3 instance;
 
@@ -485,7 +486,7 @@ public class SmartTransformerFactoryImpl extends SAXTransformerFactory {
 ### 个人理解
 该模式主要用于将复杂对象的构建过程分解成一个个简单的步骤，或者分摊到多个类中进行构建，保证构建过程层次清晰，代码不会过分臃肿，屏蔽掉了复杂对象内部的具体构建细节，其类图结构如下所示。
 
-![avatar](/images/DesignPattern/建造者模式类图.png)
+![avatar](../../../images/DesignPattern/建造者模式类图.png)
 
 该模式的主要角色如下：