20240921

Author: CompetitiveLin

_posts/2022-06-21-java.md

@@ -128,14 +128,15 @@ Java的SPI：SPI 的本质是将接口实现类的全限定名配置在文件中
 - 1.7 -> 1.8: 将运行时数据区方法区（永久代）移动到直接内存中，字符串常量池仍然在堆中。
 
 
-对象的创建过程：
+## 对象的创建过程
 1. 类加载检查
 2. 分配内存：指针碰撞或空闲列表
+  - 当多个对象并发争抢空间时，有两种解决办法：CAS 和本地线程分配缓冲（TLAB，默认方式）
 3. 初始化零值
 4. 设置对象头
 5. 执行构造方法
 
-对象的内存布局：
+## 对象的内存布局
 1. 对象头，两部分组成：存储自身运行时数据如哈希码，GC分代年龄；指向类的类型指针
 2. 实例数据，真正存储有效信息的部分
 3. 对齐填充，起占位作用
@@ -152,14 +153,14 @@ JVM触发GC时，首先会让所有的用户线程到达安全点SafePoint时阻
 - 引用计数算法
 - 可达性分析
 
-哪些对象可以作为GC Roots？
+## 哪些对象可以作为GC Roots
 - 虚拟机栈(栈帧中的本地变量表)中引用的对象
 - 本地方法栈(Native 方法)中引用的对象
 - 方法区中类静态属性引用的对象
 - 方法区中常量引用的对象
 - 所有被同步锁持有的对象
 
-内存分配和回收原则：
+## 内存分配和回收原则
 - 对象优先在Eden区分配
 - 大对象直接进入老年代
 - 长期存活的进入老年代
@@ -171,8 +172,15 @@ JVM触发GC时，首先会让所有的用户线程到达安全点SafePoint时阻
   - Mixed GC：整个新生代和部分老年代，只有G1收集器有
 - Full GC：整个Java堆和方法区
 
+### Full GC 触发条件
+1. 老年代空间不足
+  1. 创建大对象，Eden 区域放不下大对象，直接进入老年代
+  2. Minor GC 后，存活对象进入老年代
+2. 调用 system.gc()，系统会建议执行 FGC
+3. 空间分配担保机制失败
+
 ## 空间担保策略
-空间担保策略是 JVM 的一种机制，确保在 Minor GC 时，存活的对象能够成功晋升到老年代。如果老年代没有足够的空间来接收新晋升的对象，JVM 可能会提前触发 Full GC 来释放空间，或者调整内存分配策略避免此类情况的发生。
+空间担保策略是 JVM 的一种机制，发生 Minor GC 之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
 
 ## 垃圾收集算法
 - 标记——清除算法：顾名思义，标记可回收的对象并清除。
@@ -282,7 +290,10 @@ Java NIO:
 
 ### synchronized
 
-底层是通过对象监听器实现的，再底层是操作系统的互斥量（mutex）实现的
+1. 修饰普通方法/静态方法：通过 monitorenter 和 monitorexit 指令实现同步
+2. 修饰代码块：通过 ACC_SYNCHRONIZED 标记符实现同步
+
+底层都是通过对象头里 Mark Word 指向的对象监听器（Monitor）实现的，再底层是操作系统的互斥量（mutex）实现的
 
 同一时刻只能有一个线程运行 synchronized(lock) 内的代码块，其他线程会否则**阻塞**。PS：获取锁（运行代码块），释放锁（阻塞代码块）
 
@@ -597,3 +608,11 @@ java中静态属性和静态方法可以被继承，但是不能被重写，因
 - List[]、List[] 擦除后的类型为 List[]；
 - List<? extends E>、List<? super E> 擦除后的类型为 List；
 - List<T extends Serialzable & Cloneable> 擦除后类型为 List。
+
+# [JDK 设计模式](https://www.cnblogs.com/vipstone/p/18361126)
+1. 单例模式：Runtime 类使用饿汉式创建单例
+2. 工厂模式：线程池中所有线程，通过工厂模式创建
+3. 代理模式：`java.lang.reflect.Proxy` 中的动态代理
+4. 迭代器模式：`java.util.Iterator` 使用迭代器遍历集合容器
+5. 模板方法：AQS 中的 `acquire` 和 `release` 方法被独占式和共享式所重写
+

_posts/2022-06-22-mysql.md

@@ -280,9 +280,9 @@ Binlog 的持久化：
 
 刷盘时机：事务进行中
 
-1. 当innodb_flush_log_at_trx_commit=0时，InnoDB会每秒钟将log buffer中的数据更新到磁盘中。因为DDL变更或其他InnoDB内部原因会导致更新磁盘的操作独立于innodb_flush_log_at_trx_commit参数设置，并不能完全保证每秒将数据更新到磁盘一次。因此，在实例崩溃恢复场景中，可能会出现丢失1秒钟的事务。
+1. 当innodb_flush_log_at_trx_commit=0时，InnoDB会每秒钟将log buffer中的数据更新到磁盘中。但并不能完全保证每秒将数据更新到磁盘一次。因此，在实例崩溃恢复场景中，可能会出现丢失1秒钟的事务。
 2. 当innodb_flush_log_at_trx_commit=1时，InnoDB将在每次事务提交时将log buffer的数据更新到文件系统os buffer中，并调用文件系统的flush操作将数据缓存更新至磁盘中。此种方式下，数据库完全遵守ACID特性，安全性较高。
-3. 当innodb_flush_log_at_trx_commit=2时，InnoDB将在每次事务提交时将log buffer中的数据更新到文件系统缓存中，每秒钟将文件系统缓存中的数据更新到磁盘一次，该操作由操作系统调度。因为DDL变更或其他InnoDB内部原因会导致更新磁盘的操作独立于innodb_flush_log_at_trx_commit参数设置，不能完全保证每秒更新磁盘一次，没有被更新到磁盘中的事务可能会因宕机而丢失。
+3. 当innodb_flush_log_at_trx_commit=2时，InnoDB将在每次事务提交时将log buffer中的数据更新到文件系统缓存中，每秒钟将文件系统缓存中的数据更新到磁盘一次，该操作由操作系统调度。不能完全保证每秒更新磁盘一次，没有被更新到磁盘中的事务可能会因宕机而丢失。
 
 
 

_posts/2023-07-06-redis.md

@@ -113,8 +113,10 @@ Redis 7之后使用 Listpack(紧凑列表) 数据结构代替 Ziplist。
 ## Hash 数据结构下的 [rehash 过程](https://cloud.tencent.com/developer/article/1873205)：
 1. 为 ht[1] 分配空间，作为 rehash 后的哈希表。
 2. 构造一个索引技术器变量 rehashidx 并初始化为零，表示 rehash 正在执行，否则 rehashidx 为 -1 表示没在进行。
-3. 将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1]，并且 rehashidx 自增。
-4. 在 rehash 期间，增删改查操作的 index 如果大于 rehashidx，则访问 ht[0]，否则访问 ht[1]。
+3. 在 rehash 期间，**删改查**操作都是先在旧表上操作，并把旧表的数据迁移到新表；新增的操作直接在新表上新增，并且 rehashidx 自增。
+4. 除此之外，没有增删改查的操作时，还会有一个定时任务周期性（每100ms触发一次）的迁移数据
+
+好处：将一次性的大批量拷贝分摊到多个请求中。
 
 
 

_posts/2023-08-11-springboot.md

@@ -148,7 +148,7 @@ PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的区别：
 2. transactional修饰的方法内报错就一定会回滚。
 
 # Spring 用到了哪些设计模式
-1. 普通工厂模式：通过 BeanFactory 和 ApplicationContext 容器创建 Bean 对象
+1. 工厂模式：通过 BeanFactory 和 ApplicationContext 容器创建 Bean 对象
 2. 代理模式：AOP 的实现
 3. 单例模式：Bean 默认是单例
 4. 模板方法：jdbcTemplate 等用到了模板方法

_posts/2023-09-07-note-from-work.md

@@ -112,9 +112,7 @@ master 机器突然脱离网络，使得 sentinel 集群无法感知到 master 
 
 - zookeeper脑裂
 
-脑裂可能出现平票的情况，从而无法选举出 leader。
-
-zk 中建议节点数是奇数。
+脑裂可能出现平票的情况，从而无法选举出 leader。因此，zk 中建议节点数是奇数。
 
 # K8s
 
@@ -191,7 +189,7 @@ public class Singleton {
     1. 模板方法模式（Template Method），它在基类中定义了一个算法的框架，允许子类在不修改结构的情况下重写算法的特定步骤。
     2. 责任链模式（Chain of Responsibility），它让多个处理器（对象节点）按顺序处理该请求，直到其中某个处理成功为止，例如检查商品模块，需要先检查商品合法性，再检查商品可见性等等。
     3. 命令模式（Command）
-    4. 迭代器模式（Iterator）
+    4. 迭代器模式（Iterator），能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。
     5. 中介者模式（Mediator）
     6. 备忘录模式（Memeoto）
     7. 观察者模式（Observer）
@@ -303,6 +301,31 @@ TLS 的 rsa 握手过程，存在什么安全隐患，怎么解决的？
 
 SSL 加密是绝对安全的，但是 HTTPS 并不是绝对安全的，可以通过**中间人攻击**的方式，即所有请求先发送给第三方（中间人），返回中间人的证书，后续的请求/响应都通过中间人进行转发。
 
+## HTTP版本的演变
+
+### HTTP/1.0
+
+- 无状态：服务器不追踪不记录请求过的状态
+- 无连接：每次请求要建立连接，无法复用连接；在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞，后面的请求也被阻塞
+
+### HTTP/1.1
+
+- 长连接：默认保持长连接，数据传输完成后只要不断开连接，就可以继续传输数据
+- 管道化：基于上面长连接的基础，可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回
+- 缓存处理：新增字段cache-control
+- 断点传输：在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载
+
+### HTTP/2
+
+- 二进制分帧传输：更方便头部，只传输差异部分
+- 多路复用：同一服务下只需要用一个连接，节省了连接
+- 头部压缩：合并同时发出请求的相同部分
+- 服务器推送：一次客户端请求服务端可以多次响应
+
+### HTTP/3
+
+基于谷歌的QUIC，底层使用udp代码tcp协议，解决了队头阻塞问题，同样无需握手，性能大大地提升，默认使用tls加密。
+
 ## 进程和线程
 
 区别：
@@ -364,6 +387,8 @@ SSL 加密是绝对安全的，但是 HTTPS 并不是绝对安全的，可以通
 
 Paxos 和 Raft 算法都属于一致性算法，所以是保证 CP
 
+实际上，作为一个注册中心来说，保证 AP 更加重要，即可用性。
+
 ### 两种模式
 1. 客户端发现模式，首先要进行的是到服务注册中心获取服务列表，然后再根据调用端本地的负载均衡策略，进行服务调用。
 2. 服务端发现模式，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息。
@@ -485,4 +510,8 @@ DNS 在进行区域传输的时候使用 TCP，其他情况使用 UDP。
 
 
 ## 虚拟内存
-虚拟内存是一种计算机技术，它允许系统将一部分硬盘空间当作RAM（随机存取存储器）使用。当物理内存不足以支持正在运行的应用程序时，系统会将不常用的数据移动至磁盘中。虚拟内存为每个进程提供了一个一致的、私有的地址空间
+虚拟内存是一种计算机技术，它允许系统将一部分硬盘空间当作RAM（随机存取存储器）使用。当物理内存不足以支持正在运行的应用程序时，系统会将不常用的数据移动至磁盘中。虚拟内存为每个进程提供了一个一致的、私有的地址空间
+
+## 32位/64位操作系统的区别
+
+32位/64位表示CPU可以处理最大位数，一次性的运算量不一样，寻址能力也不同。

_posts/2024-08-11-zookeeper.md

@@ -73,4 +73,20 @@ ZooKeeper 的观察机制允许用户在指定节点上针对感兴趣的事件
 
 ![](https://img-blog.csdnimg.cn/20190110111903120.jpg)
 
-client与ZooKeeper集群中的某一台server保持连接，发送读/写请求，读请求直接由当前连接的server处理，写请求由于是事务请求，由当前server转发给leader进行处理。同时，client还能接收来自server端的watcher通知。所有的这些交互，都是基于client和ZooKeeper的server之间的TCP长连接，也称之为Session会话。有了会话之后，后续的请求发送，回应，心跳检测等机制都是基于会话来实现的。
+client与ZooKeeper集群中的某一台server保持连接，发送读/写请求，读请求直接由当前连接的server处理，写请求由于是事务请求，由当前server转发给leader进行处理。同时，client还能接收来自server端的watcher通知。所有的这些交互，都是基于client和ZooKeeper的server之间的TCP长连接，也称之为Session会话。有了会话之后，后续的请求发送，回应，心跳检测等机制都是基于会话来实现的。
+
+
+# ZAB 算法与 Raft 算法的选举过程
+
+## ZAB 算法
+
+1. 所有节点第一票先选举自己当leader，将投票信息广播出去；
+2. 按照规则（epoch 是否比自己的 epoch 大，以及 counter 是否比自己的 counter 大，总之选择zxid最大的投票信息，说明该节点的数据最全）判断是否需要更改投票信息，将更改后的投票信息再次广播出去；
+3. 判断是否有超过一半的投票选举同一个节点，如果是选举结束根据投票结果设置自己的服务状态，选举结束，否则继续进入投票流程。
+
+![](https://img2020.cnblogs.com/blog/1182288/202112/1182288-20211222233718927-1836593403.png)
+
+
+## Raft
+
+每个节点都有一个定时器，最先结束倒计时的节点最先发送选举的信号（基本也会是被选举为 leader）