docs: prettify code

luchao0111 · Oct 20, 2020 · f1bab50 · f1bab50
1 parent e909ca2
commit f1bab50
Show file tree

Hide file tree

Showing 66 changed files with 288 additions and 856 deletions.
diff --git a/docs/Dubbo/RPC/Dubbo协议.md b/docs/Dubbo/RPC/Dubbo协议.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/RPC/Hessian协议.md b/docs/Dubbo/RPC/Hessian协议.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/RPC/Protocol组件.md b/docs/Dubbo/RPC/Protocol组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/RPC/Proxy组件.md b/docs/Dubbo/RPC/Proxy组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/RPC/RPC模块简析.md b/docs/Dubbo/RPC/RPC模块简析.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/cluster/mock与服务降级.md b/docs/Dubbo/cluster/mock与服务降级.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/cluster/集群容错.md b/docs/Dubbo/cluster/集群容错.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/remote/Buffer组件.md b/docs/Dubbo/remote/Buffer组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/remote/Exchange组件.md b/docs/Dubbo/remote/Exchange组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/remote/Transport组件.md b/docs/Dubbo/remote/Transport组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/remote/基于HTTP实现远程通信.md b/docs/Dubbo/remote/基于HTTP实现远程通信.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Dubbo/remote/基于Netty实现远程通信.md b/docs/Dubbo/remote/基于Netty实现远程通信.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/JDK/collection/ArrayList.md b/docs/JDK/collection/ArrayList.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/JDK/collection/LinkedList.md b/docs/JDK/collection/LinkedList.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/JDK/collection/TreeSet.md b/docs/JDK/collection/TreeSet.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/JDK/concurrentCoding/CountdownLatch.md b/docs/JDK/concurrentCoding/CountdownLatch.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/JDK/concurrentCoding/CyclicBarrier.md b/docs/JDK/concurrentCoding/CyclicBarrier.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/LearningExperience/DesignPattern/从框架源码中学习设计模式的感悟.md b/docs/LearningExperience/DesignPattern/从框架源码中学习设计模式的感悟.md
@@ -1,6 +1 @@
 努力编写中...
-
-
-
-
-
diff --git a/docs/Mybatis/核心处理层/2、SqlNode和SqlSource.md b/docs/Mybatis/核心处理层/2、SqlNode和SqlSource.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Mybatis/核心处理层/3、ResultSetHandler.md b/docs/Mybatis/核心处理层/3、ResultSetHandler.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Mybatis/核心处理层/Mybats-GenericTokenParser.md b/docs/Mybatis/核心处理层/Mybats-GenericTokenParser.md
@@ -1,4 +1,5 @@
 # GenericTokenParser
+
 - Author: [HuiFer](https://github.com/huifer)
 - 源码阅读工程: [SourceHot-Mybatis](https://github.com/SourceHot/mybatis-read.git)
 
@@ -120,9 +121,9 @@ public class GenericTokenParser {
 
 ```
 
-
 - 一个具体的例子`org.apache.ibatis.builder.SqlSourceBuilder.ParameterMappingTokenHandler`
-    - 具体类`org.apache.ibatis.builder.SqlSourceBuilder`
+  - 具体类`org.apache.ibatis.builder.SqlSourceBuilder`
+
 ```java
         /**
          * ? 的来源
@@ -137,6 +138,7 @@ public class GenericTokenParser {
         }
 
 ```
+
 ```java
     /**
      * sql 参数类型 ， 返回值
@@ -173,4 +175,4 @@ public class GenericTokenParser {
 
 ```
 
-![image-20191219100446796](../../../images/mybatis/image-20191219100446796.png)
+![image-20191219100446796](../../../images/mybatis/image-20191219100446796.png)
diff --git a/docs/Netty/AdvancedFeaturesOfNetty/Netty高可靠性设计.md b/docs/Netty/AdvancedFeaturesOfNetty/Netty高可靠性设计.md
@@ -1 +1 @@
-努力编写中......
+努力编写中......
diff --git a/docs/Netty/IOTechnologyBase/详解selector、poll和epoll.md b/docs/Netty/IOTechnologyBase/详解selector、poll和epoll.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Netty/Netty主要组件源码分析/ByteBuf组件.md b/docs/Netty/Netty主要组件源码分析/ByteBuf组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Netty/Netty主要组件源码分析/EventLoop组件.md b/docs/Netty/Netty主要组件源码分析/EventLoop组件.md
@@ -1,33 +1,38 @@
-
 ## Netty 的线程模型
-Netty线程模型 的设计，也是基于 Reactor模型，尽管不同的 NIO框架 对于 Reactor模式 的实现存在差异，但本质上还是遵循了 Reactor 的基础线程模型。
 
+Netty 线程模型 的设计，也是基于 Reactor 模型，尽管不同的 NIO 框架 对于 Reactor 模式 的实现存在差异，但本质上还是遵循了 Reactor 的基础线程模型。
 
 #### Reactor 单线程模型
-Reactor单线程模型，是指所有的 I/O操作 都在同一个 NIO线程 上完成。NIO线程 的职责如下。
-1. 作为 NIO服务端，接收客户端的 TCP连接；
-2. 作为 NIO客户端，向服务端发起 TCP连接；
+
+Reactor 单线程模型，是指所有的 I/O 操作 都在同一个 NIO 线程 上完成。NIO 线程 的职责如下。
+
+1. 作为 NIO 服务端，接收客户端的 TCP 连接；
+2. 作为 NIO 客户端，向服务端发起 TCP 连接；
 3. 读取通信对端的请求或者应答消息；
 4. 向通信对端发送消息请求或者应答消息。
 
-理论上一个 NIO线程 可以独立处理所有 I/O操作。例如，通过 Acceptor类 接收客户端的 TCP连接，链路建立成功后，通过 Dispatch 轮询事件就绪的 Channel，将事件分发到指定的 Handler 上进行事件处理。小容量应用场景下，可以使用单线程模型。但对于高负载、大并发的应用场景并不合用。
+理论上一个 NIO 线程 可以独立处理所有 I/O 操作。例如，通过 Acceptor 类 接收客户端的 TCP 连接，链路建立成功后，通过 Dispatch 轮询事件就绪的 Channel，将事件分发到指定的 Handler 上进行事件处理。小容量应用场景下，可以使用单线程模型。但对于高负载、大并发的应用场景并不合用。
 
 #### Reactor 多线程模型
-Rector多线程模型 与 单线程模型 最大的区别就是有一组 NIO线程 来处理 I/O操作，Reactor多线程模型 的特点如下。
-1. 有专门一个 NIO线程 (Acceptor线程) 用于监听服务端，接收客户端的 TCP连接请求。
-2. 网络IO操作 由一个 NIO线程池 负责，由这些 NIO线程 负责消息的 读取、解码、编码、发送。
-3. 一个 NIO线程 可以同时处理 N条链路，但是一个链路只对应一个 NIO线程，防止发生并发操作问题。
 
-Reactor多线程模型 可以满足大部分场景的需求。但对于 百万级超高并发 或 服务端需要对客户端进行安全认证，但认证非常消耗资源。在这类场景下，单独一个 Acceptor线程 可能会处理不过来，成为系统的性能瓶颈。
+Rector 多线程模型 与 单线程模型 最大的区别就是有一组 NIO 线程 来处理 I/O 操作，Reactor 多线程模型 的特点如下。
+
+1. 有专门一个 NIO 线程 (Acceptor 线程) 用于监听服务端，接收客户端的 TCP 连接请求。
+2. 网络 IO 操作 由一个 NIO 线程池 负责，由这些 NIO 线程 负责消息的 读取、解码、编码、发送。
+3. 一个 NIO 线程 可以同时处理 N 条链路，但是一个链路只对应一个 NIO 线程，防止发生并发操作问题。
+
+Reactor 多线程模型 可以满足大部分场景的需求。但对于 百万级超高并发 或 服务端需要对客户端进行安全认证，但认证非常消耗资源。在这类场景下，单独一个 Acceptor 线程 可能会处理不过来，成为系统的性能瓶颈。
 
 #### Reactor 主从多线程模型
-主从Reactor多线程模型的特点是，服务端用于接收客户端连接的是一个独立的 NIO线程池。**Acceptor线程 与客户端建立 TCP连接 后，将新的 SocketChannel 注册到 NIO线程池 的某个 NIO线程 上，由该 NIO线程 负责轮询 SocketChannel 上的 IO事件，并进行事件处理**。
+
+主从 Reactor 多线程模型的特点是，服务端用于接收客户端连接的是一个独立的 NIO 线程池。**Acceptor 线程 与客户端建立 TCP 连接 后，将新的 SocketChannel 注册到 NIO 线程池 的某个 NIO 线程 上，由该 NIO 线程 负责轮询 SocketChannel 上的 IO 事件，并进行事件处理**。
 
 利用 主从多线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。在 Netty 的官方 Demo 中，也是推荐使用该线程模型。
 
 #### Netty 多线程编程最佳实践
-1. **如果业务逻辑比较简单，并且没有 数据库操作、线程阻塞的磁盘操作、网路操作等，可以直接在 NIO线程 上完成业务逻辑编排，不需要切换到用户线程；**
-2. **如果业务逻辑比较复杂，不要在 NIO线程 上完成，建议将解码后的 POJO消息 封装成 Task，分发到 业务线程池 中由业务线程执行，以保证 NIO线程 尽快被释放，处理其他的I/O操作。**
+
+1. **如果业务逻辑比较简单，并且没有 数据库操作、线程阻塞的磁盘操作、网路操作等，可以直接在 NIO 线程 上完成业务逻辑编排，不需要切换到用户线程；**
+2. **如果业务逻辑比较复杂，不要在 NIO 线程 上完成，建议将解码后的 POJO 消息 封装成 Task，分发到 业务线程池 中由业务线程执行，以保证 NIO 线程 尽快被释放，处理其他的 I/O 操作。**
 3. **由于用户场景不同，对于一些复杂系统，很难根据 理论公式 计算出最优线程配置，只能是 结合公式给出一个相对合理的范围，然后对范围内的数据进行性能测试，选择相对最优配置。**
 
 ## NioEventLoop 源码解析
@@ -94,7 +99,7 @@ public final class NioEventLoop extends SingleThreadEventLoop {
             }
         }
     }
-	
+
 	/**
 	 * 轮询 事件就绪的channel，进行 IO事件处理
 	 */
@@ -153,4 +158,4 @@ public final class NioEventLoop extends SingleThreadEventLoop {
         }
     }
 }
-```
+```
diff --git a/docs/Netty/Netty主要组件源码分析/Future和Promise组件.md b/docs/Netty/Netty主要组件源码分析/Future和Promise组件.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Netty/Netty多协议开发/基于HTTP协议的Netty开发.md b/docs/Netty/Netty多协议开发/基于HTTP协议的Netty开发.md
@@ -1 +1 @@
-努力编写中......
+努力编写中......
diff --git a/docs/Netty/Netty多协议开发/基于WebSocket协议的Netty开发.md b/docs/Netty/Netty多协议开发/基于WebSocket协议的Netty开发.md
@@ -1 +1 @@
-努力编写中......
+努力编写中......
diff --git a/docs/Netty/Netty多协议开发/基于自定义协议的Netty开发.md b/docs/Netty/Netty多协议开发/基于自定义协议的Netty开发.md
@@ -1 +1 @@
-努力编写中......
+努力编写中......
diff --git a/docs/Netty/Netty技术细节源码分析/HashedWheelTimer时间轮原理分析.md b/docs/Netty/Netty技术细节源码分析/HashedWheelTimer时间轮原理分析.md
@@ -147,4 +147,3 @@ for (int i = 0; i < 100000; i++) {
 这便是**一次完整的定时任务加入到时间轮具体位置的计算**。
 
 在 worker 线程的最后，就需要来具体执行定时任务了，首先通过当前循环轮数与时间轮数组长度-1 相与的结果定位具体触发时间轮数组上哪个位置上的链表，再通过 `expireTimeouts()`方法依次对链表上的定时任务进行触发执行。这里的流程就相对很简单，链表上的节点如果 remainingRounds 小于等于 0，那么就可以直接执行这个定时任务，如果 remainingRounds 大于 0，那么显然还没有到达触发的时间点，则将其-1 等待下一轮的调度之后再进行执行。在继续回到上面的例子，当 14 点来临之时，此时工作线程将进行第 2 轮的调度，将会把 2 与 8-1 进行相与得到结果 2，那么当前工作线程就会选择时间轮数组下标为 2 的链表依次判断是否需要触发，如果 remainingRounds 为 0 将会直接触发，否则将会将 remainingRounds-1 等待下一轮的执行。
-
diff --git a/docs/Netty/Netty技术细节源码分析/内存池之PoolChunk设计与实现.md b/docs/Netty/Netty技术细节源码分析/内存池之PoolChunk设计与实现.md
@@ -8,7 +8,7 @@
 - chunk: 一个 chunk 是一组 page 的集合
 - 在 PoolChunk 中，chunkSize 的大小是 `2^maxOrder * pageSize`，其中 2^maxOrder 是 PoolChunk 中的完全二叉树叶子结点的数量，pageSize 则是单个 page 的大小。
 
-综合如上所述，举一个数字上的例子，默认情况下，单个 Page 的大小为 8192，也就是 8kb，maxOrder 默认情况下是 11，因此在这个情况下 PoolChunk 中的二叉树的叶子节点数量是 2048，chunkSize 的大小则是 2048*8kb 为 16M。
+综合如上所述，举一个数字上的例子，默认情况下，单个 Page 的大小为 8192，也就是 8kb，maxOrder 默认情况下是 11，因此在这个情况下 PoolChunk 中的二叉树的叶子节点数量是 2048，chunkSize 的大小则是 2048\*8kb 为 16M。
 
 ## PoolChunk 的内部完全二叉树结构
 

diff --git a/docs/Redis/Redis.md b/docs/Redis/Redis.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Spring/SpringMVC/温习一下servlet.md b/docs/Spring/SpringMVC/温习一下servlet.md
@@ -1 +1 @@
-努力编写中...
+努力编写中...
diff --git a/docs/Spring/clazz/PlaceholderResolver/Spring-PlaceholderResolver.md b/docs/Spring/clazz/PlaceholderResolver/Spring-PlaceholderResolver.md
@@ -1,9 +1,10 @@
 # Spring PlaceholderResolver
+
 - 类全路径: `org.springframework.util.PropertyPlaceholderHelper.PlaceholderResolver`
 
 - 类作用将占位符中的内容替换成属性值.
-    - 假设现有属性表: user.dir = c:\home
-      传入参数 user.dir 会获得 c:\home 
+  - 假设现有属性表: user.dir = c:\home
+    传入参数 user.dir 会获得 c:\home
 
 ```java
 

diff --git a/...pring/clazz/PlaceholderResolver/Spring-PropertyPlaceholderConfigurerResolver.md b/...pring/clazz/PlaceholderResolver/Spring-PropertyPlaceholderConfigurerResolver.md
@@ -2,7 +2,6 @@
 
 - 类全路径: `org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.PropertyPlaceholderConfigurerResolver`
 
-
 - 这个类是从 Properties 中获取属性
 
 ```java
@@ -45,15 +44,13 @@
 
 ```
 
-
 ```java
 	@Nullable
 	protected String resolvePlaceholder(String placeholder, Properties props) {
 		return props.getProperty(placeholder);
 	}
 ```
 
-
 ```java
 	@Nullable
 	protected String resolveSystemProperty(String key) {
@@ -72,4 +69,4 @@
 		}
 	}
 
-```
+```
diff --git a/docs/Spring/clazz/PlaceholderResolver/Spring-ServletContextPlaceholderResolver.md b/docs/Spring/clazz/PlaceholderResolver/Spring-ServletContextPlaceholderResolver.md
@@ -1,6 +1,5 @@
 # Spring ServletContextPlaceholderResolver
 
-
 - 类全路径: `org.springframework.web.util.ServletContextPropertyUtils.ServletContextPlaceholderResolver`
 
 ```java
@@ -40,4 +39,4 @@
 		}
 	}
 
-```
+```
diff --git a/docs/Spring/clazz/PlaceholderResolver/Spring-SystemPropertyPlaceholderResolver.md b/docs/Spring/clazz/PlaceholderResolver/Spring-SystemPropertyPlaceholderResolver.md
@@ -1,8 +1,7 @@
-# Spring SystemPropertyPlaceholderResolver 
+# Spring SystemPropertyPlaceholderResolver
 
 - 类全路径: `org.springframework.util.SystemPropertyUtils.SystemPropertyPlaceholderResolver`
 
-
 ```java
 	private static class SystemPropertyPlaceholderResolver implements PropertyPlaceholderHelper.PlaceholderResolver {
 
@@ -32,4 +31,4 @@
 		}
 	}
 
-```
+```
diff --git a/docs/Spring/clazz/PropertySource/Spring-CommandLinePropertySource.md b/docs/Spring/clazz/PropertySource/Spring-CommandLinePropertySource.md
@@ -3,14 +3,9 @@
 - Author: [HuiFer](https://github.com/huifer)
 - 源码阅读仓库: [SourceHot-spring](https://github.com/SourceHot/spring-framework-read)
 
-
 - 类全路径: `org.springframework.core.env.CommandLinePropertySource`
 - 作用: 用来存储命令行参数
 
-
-
-
-
 ```java
 public abstract class CommandLinePropertySource<T> extends EnumerablePropertySource<T> {
 
@@ -93,10 +88,6 @@ public abstract class CommandLinePropertySource<T> extends EnumerablePropertySou
 }
 ```
 
-
-
-
-
 ## getOptionValues
 
 ```java
@@ -120,8 +111,6 @@ public abstract class CommandLinePropertySource<T> extends EnumerablePropertySou
 protected abstract List<String> getOptionValues(String name);
 ```
 
+阅读注释可以知道该方法可以获取命令行参数的列表.
 
-
-阅读注释可以知道该方法可以获取命令行参数的列表. 
-
-- 如 `--foo`作为开头当输入命令行为 `--foo=bar --foo=baz` 在输入参数名称 `foo` 会得到数据`bar,baz` 
+- 如 `--foo`作为开头当输入命令行为 `--foo=bar --foo=baz` 在输入参数名称 `foo` 会得到数据`bar,baz`
diff --git a/docs/Spring/clazz/PropertySource/Spring-ComparisonPropertySource.md b/docs/Spring/clazz/PropertySource/Spring-ComparisonPropertySource.md
@@ -3,12 +3,11 @@
 - Author: [HuiFer](https://github.com/huifer)
 - 源码阅读仓库: [SourceHot-spring](https://github.com/SourceHot/spring-framework-read)
 
-
 - 整体代码如下.
-    - 下面几个调用方法会直接抛出异常
-        1. getSource
-        1. containsProperty
-        1. getProperty
+  - 下面几个调用方法会直接抛出异常
+    1. getSource
+    1. containsProperty
+    1. getProperty
 
 ```java
 	static class ComparisonPropertySource extends StubPropertySource {
@@ -41,4 +40,4 @@
 		}
 	}
 
-```
+```
diff --git a/docs/Spring/clazz/PropertySource/Spring-CompositePropertySource.md b/docs/Spring/clazz/PropertySource/Spring-CompositePropertySource.md
@@ -1,11 +1,12 @@
 # Spring CompositePropertySource
+
 - Author: [HuiFer](https://github.com/huifer)
 - 源码阅读仓库: [SourceHot-spring](https://github.com/SourceHot/spring-framework-read)
 
-
 - 全路径: `org.springframework.core.env.CompositePropertySource`
 
 - 整体代码如下
+
 ```java
 public class CompositePropertySource extends EnumerablePropertySource<Object> {
 
@@ -102,4 +103,4 @@ public class CompositePropertySource extends EnumerablePropertySource<Object> {
 	}
 
 }
-```
+```
Original file line number	Diff line number	Diff line change
Expand Up		@@ -147,4 +147,3 @@ for (int i = 0; i < 100000; i++) {
		这便是一次完整的定时任务加入到时间轮具体位置的计算。

		在 worker 线程的最后，就需要来具体执行定时任务了，首先通过当前循环轮数与时间轮数组长度-1 相与的结果定位具体触发时间轮数组上哪个位置上的链表，再通过 `expireTimeouts()`方法依次对链表上的定时任务进行触发执行。这里的流程就相对很简单，链表上的节点如果 remainingRounds 小于等于 0，那么就可以直接执行这个定时任务，如果 remainingRounds 大于 0，那么显然还没有到达触发的时间点，则将其-1 等待下一轮的调度之后再进行执行。在继续回到上面的例子，当 14 点来临之时，此时工作线程将进行第 2 轮的调度，将会把 2 与 8-1 进行相与得到结果 2，那么当前工作线程就会选择时间轮数组下标为 2 的链表依次判断是否需要触发，如果 remainingRounds 为 0 将会直接触发，否则将会将 remainingRounds-1 等待下一轮的执行。