更新了面经的笔记

算法/多线程/三个线程打印ABC.md

@@ -0,0 +1,52 @@
+```java
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; i++) {
+        synchronized (obj) {
+            while (state % 3 != target) {
+                try {
+                    obj.wait();
+                } catch (InterruptedException e) {
+                    e.printStackTrace();
+                }
+            }
+            state++;
+            System.out.print(str);
+            obj.notifyAll();
+        }
+    }
+}
+
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; ) {
+        synchronized (obj) {
+            while (state % 3 != target) {
+                obj.wait();
+            }
+            state++;
+            i++;
+            System.out.print(str);
+            obj.notifyAll();
+        }
+    }
+}
+```
+
+```java
+public void print(String str, int target) throws InterruptedException {
+    for (int i = 0; i < n; ) {
+        try {
+            lock.lock();
+            while (state % 3 == target) {
+                System.out.print(str);
+                state++;
+                i++;
+            }
+        } finally {
+            lock.unlock();
+        }
+    }
+}
+```
+
+
+

面经/问答/计网.md

@@ -102,12 +102,20 @@ TCP 是**面向连接的、可靠的、基于字节流**的传输层通信协议
 
 ## TCP三次握手
 
-这个问题可以理解为为什么TCP不是两次握手，因为主要原因是两次握手只能确定一方的状态
+### 为什么需要三次握手
 
 - 三次握手才可以阻止重复历史连接的初始化（主要原因）
+
+**在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费**。
+
 - 三次握手才可以同步双方的初始序列号
+
+TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素。**一来一回，才能确保双方的初始序列号能被可靠的同步。**
+
 - 三次握手才可以避免资源浪费
 
+如果客户端发送的 `SYN` 报文在网络中阻塞了，重复发送多次 `SYN` 报文，那么服务端在收到请求后就会**建立多个冗余的无效链接，造成不必要的资源浪费。**
+
 需要注意的是**第三次握手是可以携带数据的，前两次握手是不可以携带数据的**
 
 ![image-20230509151944605](assets/image-20230509151944605.png)
@@ -245,3 +253,14 @@ TCP 的 Keepalive 这东西其实就是 **TCP 的保活机制**
 - 固定长度的消息：这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息。
 - 特殊字符作为边界：我们可以在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。
 - 自定义消息结构：我们可以自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。
+
+## 从输入 URL 到页面展示到底发生了什么？（非常重要）
+
+总体来说分为以下几个过程:
+
+1. DNS解析
+2. TCP连接
+3. 发送HTTP请求
+4. 服务器处理请求并返回HTTP报文
+5. 浏览器解析渲染页面
+6. 连接结束

面经/项目/中煤项目.md

@@ -4,7 +4,7 @@
 
 该模块主要采集传感器生成的实时数据，为了保证数据的有序，所以要保证数据的顺序消费，因为采集的数据将按照时间顺序存入到hbase中。在生产者那一端可以从mysql或者kafka管道中收集数据实时数据，为了保证顺序消费，综合考虑将重试次数设置为0，因为这个系统更多的是在意吞吐量，对于消息是否丢失不是很在意。在消费者那一端则采用线程池对消费的数据进行多线程处理，主要采取策略模式，按照选择的不同策略进行计算，例如区间或者压强的简单计算，或者是数值替换，也支持三方jar包，然后通过futuer收集数据。最后存储到hbase中。为了保证消息的等幂性，消费者端我们采取redis进行缓存分区偏移量，缓存超时时间默认为3分钟，手动提交ACK。等方式保证消息顺序消费。
 
-我完成的第二个模块就是kafka监控模块，主要监控kafka集群的状态，与kafka-egale类似。主要操作就是调用kafka提供的kafka-admin-client接口和JMX进行操作，这里进行了相应的优化，主要包括复用同一个连接，使用工厂模式，生产一个admin-client，这里主要加了饿汉式单例来保证线程安全，利用redis缓存topic的速率。最后对于该模块，采用热启动的方式优化，例如自动建表，提前获取相关admin-client链接等
+我完成的第二个模块就是kafka监控模块，主要监控kafka集群的状态，与kafka-egale类似。主要操作就是调用kafka提供的kafka-admin-client接口和JMX进行操作，这里进行了相应的优化，主要包括复用同一个连接，使用工厂模式，生产一个admin-client，这里主要加了懒汉式单例来保证线程安全，利用redis缓存topic的速率。最后对于该模块，采用热启动的方式优化，例如自动建表，提前获取相关admin-client链接等
 
 ```java
 import redis.clients.jedis.Jedis;