20241202

Author: CompetitiveLin

_posts/2022-06-21-java.md

@@ -649,5 +649,7 @@ java中静态属性和静态方法可以被继承，但是不能被重写，因
 2. 工厂模式：`java.util.concurrent` ThreadFactory 接口使用工厂模式创建线程
 3. 代理模式：`java.lang.reflect` Proxy 类使用动态代理
 4. 迭代器模式：`java.util` Iterator 接口使用迭代器遍历集合容器
-5. 模板方法：`java.util.concurrent.locks` AQS 中的 `tryAcquire`, `tryRelease`, `tryAcquireShared`, `tryReleaseShared` 方法被公平锁和非公平锁重写
-
+5. 模板方法模式：`java.util.concurrent.locks` AQS 中的 `tryAcquire`, `tryRelease`, `tryAcquireShared`, `tryReleaseShared` 方法被公平锁和非公平锁重写
+6. 装饰器模式 + 适配器模式
+    1. 装饰器模式：通过组合替代继承的方式在不改变原始类的情况下**添加增强功能**，例如 `FilterInputStream` 和 `FilterOutputStream` 用于增强 `InputStream` 和 `OutputStream` 的功能。
+    2. 适配器模式：字符流对象和字节流对象的**相互适配**

_posts/2022-06-22-mysql.md

@@ -325,7 +325,7 @@ Binlog 的持久化：
 3. MySQL 认为空闲时，后台线程会定期将适量的脏页刷入到磁盘；
 4. MySQL 正常关闭之前，会把所有的脏页刷入到磁盘；
 
-### Crash-Safe 能力，两阶段提交
+### Crash-Safe 能力，两阶段提交（崩溃恢复）
 前提：innodb_flush_log_at_trx_commit 设置为1，sync_binlog 设置大于0
 
 1. 先将数据修改**写入redo log**，并将其标记为 prepare 状态
@@ -337,11 +337,6 @@ Binlog 的持久化：
 2. 如果是 prepare 状态，检查 binlog 记录的对应事务操作（redo log 与 binlog 记录的事务操作有一个共同字段 XID，redo log 就是通过这个字段找到 binlog 中对应的事务的）是否完整（这点在前面 binlog 三种格式分析过，每种格式记录的事务结尾都有特定的标识），如果完整就将 redo log 设为 commit 状态，然后结束；不完整就回滚 redo log 的事务，结束。
 
 
-为什么需要两阶段提交？
-
-- 以基本的事务为单位，redo log 在事务执行过程中可以不断写入，而 binlog 只有在提交事务时才写入，所以redo log 与 binlog 的写入时机不一样。为了解决两份日志之间的逻辑一致问题，将redo log的写入拆成了两个步骤 prepare 和 commit，即两阶段提交。如果只有 redo log 或者只有 binlog，那么事务就不需要两阶段提交。
-
-
 ## 执行顺序
 
 1. from

_posts/2023-08-11-springboot.md

@@ -86,7 +86,7 @@ Prototype（原型）对象和单例对象的区别：
 
 ### 不同点
 1. 过滤器基于函数回调，拦截器基于 Java 的反射机制
-2. 过滤器依赖于 tomcat 容器，拦截器是 spring 组件，并不依赖于 tomcat，因此先执行过滤器，再执行拦截器
+2. 过滤器依赖于 servlet 容器，拦截器是 spring 组件，并不依赖于 servlet，因此先执行过滤器，再执行拦截器
 3. 过滤器几乎可以对所有进行容器的请求起作用，拦截器只会对 controller 中的请求起作用
 
 ### 使用场景