Merge branch 'master' of https://github.com/Snailclimb/JavaGuide

Author: Snailclimb

docs/data/java-recommended-books.md

@@ -82,8 +82,9 @@
 
 ### 设计模式
 
-- [《设计模式 : 可复用面向对象软件的基础》 ](https://book.douban.com/subject/1052241/) （推荐，豆瓣评分 9.1）：设计模式的经典！
+- [《设计模式 : 可复用面向对象软件的基础》](https://book.douban.com/subject/1052241/) （推荐，豆瓣评分 9.1）：设计模式的经典！
 - [《Head First 设计模式（中文版）》](https://book.douban.com/subject/2243615/) （推荐，豆瓣评分 9.2）：相当赞的一本设计模式入门书籍。用实际的编程案例讲解算法设计中会遇到的各种问题和需求变更（对的，连需求变更都考虑到了！），并以此逐步推导出良好的设计模式解决办法。
+- [《大话设计模式》](https://book.douban.com/subject/2334288/) （推荐，豆瓣评分 8.3）：本书通篇都是以情景对话的形式，用多个小故事或编程示例来组织讲解GOF(即《设计模式 : 可复用面向对象软件的基础》这本书))，但是不像《设计模式 : 可复用面向对象软件的基础》难懂。但是设计模式只看书是不够的，还是需要在实际项目中运用，结合[设计模式](docs/system-design/设计模式.md)更佳！
 
 ### 常用框架
 

docs/essential-content-for-interview/PreparingForInterview/美团面试常见问题总结.md

@@ -450,7 +450,7 @@ TransactionDefinition 接口中定义了五个表示隔离级别的常量：
 ### 1.3 介绍一下你知道哪几种消息队列,该如何选择呢?
 
 
-| 特性                    |                                                     ActiveMQ |                                                     RabbitMQ |                                                     RocketMQ |                                                       Kafaka |
+| 特性                    |                                                     ActiveMQ |                                                     RabbitMQ |                                                     RocketMQ |                                                       Kafka |
 | :---------------------- | -----------------------------------------------------------: | -----------------------------------------------------------: | -----------------------------------------------------------: | -----------------------------------------------------------: |
 | 单机吞吐量              |                万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |                万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |                   10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
 | topic数量对吞吐量的影响 |                                                              |                                                              | topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 |

docs/java/Multithread/JavaConcurrencyAdvancedCommonInterviewQuestions.md

@@ -54,7 +54,7 @@ synchronized关键字解决的是多个线程之间访问资源的同步性，sy
 **synchronized关键字最主要的三种使用方式：**
 
 - **修饰实例方法:** 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
-- **修饰静态方法:** :也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，**因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁**。
+- **修饰静态方法:** 也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，**因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁**。
 - **修饰代码块:** 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。
 
 **总结：** synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。synchronized 关键字加到实例方法上是给对象实例上锁。尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓存功能！
@@ -95,7 +95,7 @@ uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueIns
 2. 初始化 uniqueInstance
 3. 将 uniqueInstance 指向分配的内存地址
 
-但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
+但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
 
 使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。
 
@@ -176,7 +176,7 @@ synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团
 ### 2.1. 讲一下Java内存模型
 
 
-在 JDK1.2 之前，Java的内存模型实现总是从**主存**（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存**本地内存**比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成**数据的不一致**。
+在 JDK1.2 之前，Java的内存模型实现总是从**主存**（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存**本地内存**（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成**数据的不一致**。
 
 ![数据不一致](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/数据不一致.png)
 
@@ -331,7 +331,7 @@ ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
 
 ### 3.4. ThreadLocal 内存泄露问题
 
-`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用,而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候会 key 会被清理掉，而 value 不会被清理掉。这样一来，`ThreadLocalMap` 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法
+`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用,而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，`ThreadLocalMap` 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法
 
 ```java
       static class Entry extends WeakReference<ThreadLocal<?>> {
@@ -622,4 +622,4 @@ tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true
 
 **Java工程师必备学习资源:** 一些Java工程师常用学习资源公众号后台回复关键字 **“1”** 即可免费无套路获取。 
 
-![我的公众号](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/167598cd2e17b8ec.png)
+![我的公众号](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/167598cd2e17b8ec.png)

docs/system-design/data-communication/Kafka入门看这一篇就够了.md

@@ -28,7 +28,7 @@
 
 ### 概念一：生产者与消费者
 
-![生产者与消费者](./../../../media/pictures/kafaka/生产者和消费者.png)
+![生产者与消费者](./../../../media/pictures/kafka/生产者和消费者.png)
 
 对于 Kafka 来说客户端有两种基本类型：
 
@@ -41,7 +41,7 @@
 
 ### 概念二：主题（Topic）与分区（Partition）
 
-![主题（Topic）与分区（Partition）](./../../../media/pictures/kafaka/主题与分区.png)
+![主题（Topic）与分区（Partition）](./../../../media/pictures/kafka/主题与分区.png)
 
 在 Kafka 中，消息以**主题（Topic）**来分类，每一个主题都对应一个 **「消息队列」**，这有点儿类似于数据库中的表。但是如果我们把所有同类的消息都塞入到一个“中心”队列中，势必缺少可伸缩性，无论是生产者/消费者数目的增加，还是消息数量的增加，都可能耗尽系统的性能或存储。
 
@@ -53,7 +53,7 @@
 
 若干个 Broker 组成一个集群（Cluster），其中集群内某个 Broker 会成为集群控制器（Cluster Controller），它负责管理集群，包括分配分区到 Broker、监控 Broker 故障等。在集群内，一个分区由一个 Broker 负责，这个 Broker 也称为这个分区的 Leader；当然一个分区可以被复制到多个 Broker 上来实现冗余，这样当存在 Broker 故障时可以将其分区重新分配到其他 Broker 来负责。下图是一个样例：
 
-![Broker和集群](./../../../media/pictures/kafaka/Broker和集群.png)
+![Broker和集群](./../../../media/pictures/kafka/Broker和集群.png)
 
 Kafka 的一个关键性质是日志保留（retention），我们可以配置主题的消息保留策略，譬如只保留一段时间的日志或者只保留特定大小的日志。当超过这些限制时，老的消息会被删除。我们也可以针对某个主题单独设置消息过期策略，这样对于不同应用可以实现个性化。
 
@@ -84,7 +84,7 @@ Kafka 的一个关键性质是日志保留（retention），我们可以配置
 
 **上述的 Topic 其实是逻辑上的概念，面相消费者和生产者，物理上存储的其实是 Partition**，每一个 Partition 最终对应一个目录，里面存储所有的消息和索引文件。默认情况下，每一个 Topic 在创建时如果不指定 Partition 数量时只会创建 1 个 Partition。比如，我创建了一个 Topic 名字为 test ，没有指定 Partition 的数量，那么会默认创建一个 test-0 的文件夹，这里的命名规则是：`<topic_name>-<partition_id>`。
 
-![主题（Topic）与分区（Partition）](./../../../media/pictures/kafaka/kafka存在文件系统上.png)
+![主题（Topic）与分区（Partition）](./../../../media/pictures/kafka/kafka存在文件系统上.png)
 
 任何发布到 Partition 的消息都会被追加到 Partition 数据文件的尾部，这样的顺序写磁盘操作让 Kafka 的效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是 Kafka 高吞吐率的一个很重要的保证）。
 
@@ -122,7 +122,7 @@ Kafka 的一个关键性质是日志保留（retention），我们可以配置
 
 以上面的一对 Segment File 为例，说明一下索引文件和数据文件对应关系：
 
-![索引文件和数据文件](./../../../media/pictures/kafaka/segment是kafka文件存储的最小单位.png)
+![索引文件和数据文件](./../../../media/pictures/kafka/segment是kafka文件存储的最小单位.png)
 
 
 
@@ -150,7 +150,7 @@ Kafka 的一个关键性质是日志保留（retention），我们可以配置
 
 不同的业务需要使用不同的写入方式和配置。具体的方式我们在这里不做讨论，现在先看下生产者写消息的基本流程：
 
-![生产者设计概要](./../../../media/pictures/kafaka/生产者设计概要.png)
+![生产者设计概要](./../../../media/pictures/kafka/生产者设计概要.png)
 
 图片来源：[http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/12/kafka-producer.html](http://www.dengshenyu.com/分布式系统/2017/11/12/kafka-producer.html)
 
@@ -173,24 +173,24 @@ Kafka 的一个关键性质是日志保留（retention），我们可以配置
 
 Kafka消费者是**消费组**的一部分，当多个消费者形成一个消费组来消费主题时，每个消费者会收到不同分区的消息。假设有一个T1主题，该主题有4个分区；同时我们有一个消费组G1，这个消费组只有一个消费者C1。那么消费者C1将会收到这4个分区的消息，如下所示：
 
-![生产者设计概要](./../../../media/pictures/kafaka/消费者设计概要1.png)
+![生产者设计概要](./../../../media/pictures/kafka/消费者设计概要1.png)
 如果我们增加新的消费者C2到消费组G1，那么每个消费者将会分别收到两个分区的消息，如下所示：
 
-![生产者设计概要](./../../../media/pictures/kafaka/消费者设计概要2.png)
+![生产者设计概要](./../../../media/pictures/kafka/消费者设计概要2.png)
 
 如果增加到4个消费者，那么每个消费者将会分别收到一个分区的消息，如下所示：
 
-![生产者设计概要](./../../../media/pictures/kafaka/消费者设计概要3.png)
+![生产者设计概要](./../../../media/pictures/kafka/消费者设计概要3.png)
 
 但如果我们继续增加消费者到这个消费组，剩余的消费者将会空闲，不会收到任何消息：
 
-![生产者设计概要](./../../../media/pictures/kafaka/消费者设计概要4.png)
+![生产者设计概要](./../../../media/pictures/kafka/消费者设计概要4.png)
 
 总而言之，我们可以通过增加消费组的消费者来进行水平扩展提升消费能力。这也是为什么建议创建主题时使用比较多的分区数，这样可以在消费负载高的情况下增加消费者来提升性能。另外，消费者的数量不应该比分区数多，因为多出来的消费者是空闲的，没有任何帮助。
 
 **Kafka一个很重要的特性就是，只需写入一次消息，可以支持任意多的应用读取这个消息。**换句话说，每个应用都可以读到全量的消息。为了使得每个应用都能读到全量消息，应用需要有不同的消费组。对于上面的例子，假如我们新增了一个新的消费组G2，而这个消费组有两个消费者，那么会是这样的：
 
-![生产者设计概要](./../../../media/pictures/kafaka/消费者设计概要5.png)
+![生产者设计概要](./../../../media/pictures/kafka/消费者设计概要5.png)
 
 在这个场景中，消费组G1和消费组G2都能收到T1主题的全量消息，在逻辑意义上来说它们属于不同的应用。
 
@@ -216,7 +216,7 @@ Kafka消费者是**消费组**的一部分，当多个消费者形成一个消
 
 无论消息是否被消费，除非消息到期 Partition 从不删除消息。例如设置保留时间为 2 天，则消息发布 2 天内任何 Group 都可以消费，2 天后，消息自动被删除。
 Partition 会为每个 Consumer Group 保存一个偏移量，记录 Group 消费到的位置。 如下图：
-![生产者设计概要](./../../../media/pictures/kafaka/Partition与消费模型.png)
+![生产者设计概要](./../../../media/pictures/kafka/Partition与消费模型.png)
 
 
 
@@ -269,7 +269,7 @@ vi /usr/local/etc/kafka/server.properties
 
 然后修改成下图的样子：
 
-![启动服务](./../../../media/pictures/kafaka/启动服务.png)
+![启动服务](./../../../media/pictures/kafka/启动服务.png)
 依次启动 Zookeeper 和 Kafka：
 
 ```shell
@@ -305,7 +305,7 @@ kafka-console-producer --broker-list localhost:9092 --topic test
 
 能通过消费者窗口观察到正确的消息：
 
-![发送消息](./../../../media/pictures/kafaka/发送消息.png)
+![发送消息](./../../../media/pictures/kafka/发送消息.png)
 
 # 参考资料